Hi Cadavre
3 above: What I meant by that is to check that all the ACD-DN's referenced on your agent phone's KEY 0 still exist. Print all agent sets, you will see KEY 0 nnnn 0 mmmm (n = ACD-DN / m = Position ID). Then print out all those ACD-DN's (in LD 23). Even though with Symposium call routing does no longer consider the ACD-DN, it must exist if an agent phone references it on KEY 0. In theory you should not be able to OUT an ACD-DN that is referenced on a KEY 0, or you should not be able to configure KEY 0 with an ACD-DN that does not exist, but stranger things have happend.
4 above: Items I would check first are that ALL application that are in use and referenced by either the master script on other scripts are in fact ACTIVE. Start by viewing the master script, then work your way through the rest. Also make sure that the skill sets that are assigned to agent ID's are still in tact.
9 above: the prompt for this is set in LD 23, ACD-DN:
ALOG (NO) YES Provide Automatic Log In for agents on this DN.
Set to YES for Meridian Mail applications. ALOG applies
only to Command and Status Link (CMS) and Data
Service Access Codes (DSAC).
Prompted if IMS or ISAP = YES
If for some reason this was previously set to YES, and has now been set to NO, agents who are unaware that they have to follow a different log in proceedure may just enter their agent ID and then wait for the log in to complete. Again, strictly speaking Symposium over rides this, but won't hurt to check it out. And as the administration guide suggests, this is not used for people agent log in. It's supposed to log in "agents" for MMail or Call Pilot ACD-DNs and so on, at least that is how I interpret it.
You should have an M1 Administration guide. Even though by using Symposium your ACD-DN config is not critical, the more you know about it, the better. Remember, if your Symposium server fails for what ever reason, all phone sets and CDN's are automatically de-acquired by the PBX, and you're suddenly using BASIC ACD routing. I've always tried to match up call centers as close as possible on the BASIC ACD side as it was set up on Symposium, for redundency purpose. Every critical skill set on SCCS also had a corresponding ACD-DN, playing the same RAN messages with the same timers, and all the CDN's had the DFDN matched up to be the ACD-DN that on SCCS side was the skill set. Hopefully it never happens, but when it does, you will be very happy to tell the call center to log out, and just log in, each agent to a relevant ACD-DN that matches their skill set. For one customer we had to routinely test that scenario. All supervisors had a skill set to ACD table. At random times we came in, shut down the services on SCCS and sent a message to the call center that ther server had failed. Any way, that has nothing to do with your problem..
In the absence of error messages - and you should check both sides: PBX and Symposium, I would be VERY concerned. When the error occurs, you should see errors on either the PBX and/or Symposium (log on as administrator and view the error logs). If there are none, sound the general alarm bell.
Here is what gets my attention: you mention above that your Symposium server has just been updated. Do you mean that patches were installed for Sympoium, or Windows? Assuming the first one, did the error occur before the patches were installed, or only after?
If I was you, I would fast track this problem and get your vendor to come in ASAP. Let them do a full back up of your Symposium data bases during a quiet time, and start with a proper shut down procedure and reboot the server. If the problem continues, get lot's of coffee and potato chips, because then you will spend many hours trouble shooting hardware, network and software. Reason I would get the vendor involved is that if you have corruption some where, your Symposium may not come up properly, and by then it's too late to call in the troops.
There is of course one other thing to check: you must confirm that your LICENSED positions match up with actual configured positions, again both sides: PBX and Symposium. Look for agent licenses, which refers to the POSITION ID on phone sets, and not the actual number of agent ID's. I've seen this happen before, it causes all sorts of weird and wonderful errors and problems. I always wondered how people managed to confiugre more positions than they have licenses, but that is a topic for another discussion
