OAM Service Shutting Down

[Draxis]

We have a SCCS 4.2 server along with an Opt61C release 25.40. Over the last month, we have had three instances where our OAM service randomly shuts down. The only symptom that seems to come up is that when we login to the client, we can't do any user management. As soon as we click on any user in the user list, the client applicatino locks up. Fortunately, this doesn't seem to affect call routing at all, so all we do is wait till after business hours, reboot the server, and it's all working again. For a week or so anyways.

I haven't been able to pinpoint any type of scenario that causes this to shutdown. It appears to be completely random.

Any ideas on what could be causing this? If so, any other ideas on how to fix it?

 

[Supernn]

Which PEP is installed, 4.2 has SU10 available now.

 

[Draxis]

My current SCCS software version is 04.02.06SU04S. I'm assuming that means my latest PE is SU04. Where can I get the latest PEP?

 

[Supernn]

I'm having the same issue with a SCCS 4.0 with NS040107SU1010S installed here, also randomly the possibility to login is denied until the OAM service is restarted.
Most of the times this is caused by a network problem of one of the clients (I guess a network problem while collecting data from the server) or when deleting an old user.....(haven't found a fix or solution yet)

 

[Draxis]

Just this last week I've begun to notice that our problem seems be network related as well. I'm working with our network manager to try and pinpoint what could be causing our problem. Hopefully we come up with a solution soon.

Does anyone know where I can get the latest PEP??? Besides calling my vendor.

 

[sandyml]

A couple of thoughts:

1. Do you have a Symposium Web Client server on your network?
2. If so, does it have more than 1 NIC card?
3. Do you run scheduled reports?
4. If so, do you have any error messages where a scheduled report tried to run but could not find the client who scheduled it (e.g., their pc was turned off)?
5. Check your DNS server -- if you have entries in it for both the CLAN address and the ELAN address, delete the ELAN address.
6. Check the binding order of your NIC cards on the Symposium -- CLAN should be first.

 

[Draxis]

We do have a Symposium Wed Client, but we don't use it. I recently installed it and am testing it to see how it works. It only has one NIC in it, on the CLAN. I wouldn't know about any error messages since we don't use it for reports yet. I think the only entry in our DNS server is the CLAN, but I'll have our network admin check. I can check the binding order of the NICs when I get back into the office tomorrow.

 

[sandyml]

You might find that you can recreate the problem by scheduling reports via the classic client and then disconnecting the classic client from the network before the report runs. I found that this causes an error the first time, a temporary freeze/slowdown on the second occurrence, and then a freeze-up as you describe by the third time, when there is a Web Client server on the network as well. Something to look at.

 

[Draxis]

Let me make sure I understand what you're saying. If we have a supervisor that has an Agent Performance Report scheduled to run after-hours, and they sometimes shut their computer down when they leave, (whether it's on accident or some other reason) by the third time that happens our OAM service will stop responding?

 

[sandyml]

If you have a Symposium Web Client server also on your network, yes, that can happen. Even without a Web Client server, that will cause a "major" error to be reported in the Symposium event viewer. I have seen some environments where this did not occur, and some where it did. So, I think there is probably something else working in conjunction with this -- perhaps DNS config, with/without WINS, etc. If you aren't using your Web Client, try disconnecting it from the network for a while and see if the problem goes away.

 

[Draxis]

Thanks for the help. I'll give that a try.

 

[jockeyman]

Did this problem ever get resolved? I have the exact same issue and we've covered just about everything in the previous posts. I'm getting ready to shut down my web server but really hate to do that. If there was ever a solution identified I appreciate hearing about it.

 

[Draxis]

Yes it did. I turned off our test Web Client Server and the problem went away. Apparently you can't run both the fat client and the web client in tandem if you have scheduled reports running on the fat client.

 

[linken]

So you have been running your scheduled reports from the Web Client then with No issues ?

 

[jockeyman]

Thanks draxis - I plan on pursuing this further with NOrtel and if I come up with a solution that allows both the web and classic client to co-exist I'm post it here.

 

[Draxis]

Linken: No, I was just running a test Web Client Server to see how to set it up and to check it out to see if we should migrate to it. Once I was aware of the problem, the Web Server was shutdown and never turned back on. We're looking to migrate to it by the end of the year though and phase out the fat client for everyone but the admins.

 

[rob71ert]

This is a known problem update your patch for SWC (web) Client.

 

[Draxis]

what needs to be patched? the web client server, or the SCCS server?

 

[jockeyman]

The PEP is against the Web Server. We patched the Web server and OAM stopped failing. This didn't solve all our problems however. Even with our web server powered off we would have instances where we would lose the ability to do user management. When you brought up a user the only tab available was the general tab. What we found was that because of obsolete configurations and other errors coming from 3rd party apps there were a lot of registration requests going across the link to Symposium repeatedly. By capturing that traffic via MLSM traces and working with Nortel we cleaned all that stuff up and the problem seems to have gone away.

 

[Draxis]

that happened to me as well, but SU13 for SCCS 4.2 fixed that.