SCCS 5.0 ASM & TFE services hang after reboot

[picklemogg]

Hey all- SCCS 5.0 with latest SU/PEPS installed. Sometimes after a reboot, the ASM and TFE services remain in a starting state. I've read a post on here that the PBX host name and switch ID as configured in SCCS should be identical. In my case here, they do not match. Could this be my problem?

If this were my problem, would these services ever start? Is it an all or nothing deal? Last night after rebooting, these services were hung in the starting state for like 45 minutes. After 45 minutes of doing absolutely nothing, the services eventually came up. Could there me some kind of name resolution thing going on here and eventually conencts?

All thoughts are greatly appreciated as always. Thanks.

PMoggs

 

[sandyml]

Are you saying that the Switch Name (as defined in the Server Setup Configuration and the Feature Report, both on the SCCS) and the PBX host name (as defined in LD 117 on the PBX) are not identical?

If that is the case then yes, that is a problem. Schedule a maintenance window and correct this in Server Setup Configuration (reboot required).

 

[picklemogg]

Sandyml- Thanks for the quick response. That is exactly what I am saying. Since they are different, does it make sense that the services would eventually start after 45 minutes?

In talking with our vendor, I was told that Nortel recommends the names being identical, but is not required. Not sure if I'm buying that one.

Thanks.

PMoggs

 

[pakya123]

Nortel does recommend that the switch name and PBX host name should be identical (They had done so when they made an audit on one of my sites last time.) , but it is nowhere mentioned in the Install and Maint documents. And I dont think it matters that much for at most of my sites the setup is working absolutely fine even though the switch name and host name are not the same.


Have you checked for any possible network issues?

 

[picklemogg]

Nortel verified that the switch ID as configured in SCCS matching PBX host name was only required prior to 4.2. In SCCS 5.0 it is merely a label and only uses the IP defined.

We have verified network setup, bindings order, etc. and came up empty.

Vendor is in now trying to figure out what is going on. Weird issue. I hate the ones where there is no apparent answer. I'll see what they say.....

 

[sandyml]

Interesting, picklemogg. Let us know.

 

[Triton101]

Used to be a binding order issue on 4x like that. Check if you have something else showing up under network adapters... (other than the Elan and Clan nics)

 

[picklemogg]

After 3 weeks still no answers with vendor- maybe escalating to Nortel shortly. Vendor suspects it maybe phantom TN related or scipting syntax causing an error. Scripting is same at that location as 5 of our other sites. I think it has something to do with integartion to web client and/or call pilot since we use both give ivr and access ports. Like a needle in a haystack.....

 

[Milesprower]

There was a bulletin out for this issue. I think it may be related to HP servers, but I don't remember. This should not be a scripting or TN issue, it is definitely something between the server, OS and Nortel application. I've seen TFE run fine with terrible scripts and (occasionally) hang up with perfect scripts.

 

[captaingadget]

Do you by any chance have "queue to agent" commands in any of you scripts? A serious problem such as this occurs when an agent is deleted from the system but not from the script. If the SCCS is re-started the system validates all scripts and fails because an agent referenced in a script no longer exists. TFE hangs at this point.

 

[picklemogg]

Thanks for the responses. If it is related to HP servers, we definitely fall into that category. I need to try to find that bulletin....

We do have a couple of locations that we do use "queue to agent" commands, but not at this particular location. I did double check all scripts, including some test appls just in case I forgot about something. Also ran some skillset reports to confirm. I was hoping we did....

Thanks again.