We have several call centers that I manage and the agents move alot. We do not move the move the phones with the agents, and we have several default queues built in the switch. When I move an agent to a new phone and he/she changes queues within the PBX, then I am forced to bounce the TServer.
Is there a way to OUT and rebuild a phone in the PBX and acquire it with the TServer without having to bounce the TServer?
Usually, you would not have to restart your TServer if you move an agent from one place to another.
Before I can answer it correctly, I need to know:
1.Bounce restart?
2.Why in the world are you doing it?
3.Do you need to move phones with agents?
4.Are you using IR/URS?
5.What PBX? Meridian with MLink or Symposium? And what version of TServer?
If its a Meridian, sounds like the turrets may be retaining default queues from the previous agent login. Do your agents login at the turret or via a softphone? If no explicit queue login is giving and you are running routing from Genesys then it could be that this is your problem.
Try tetsing to see if the turret is in the default queue from the previous agent. If this is the problem then either put a queue into the login routine of the softphone or get the agent to login to a default queue on the turret manually.
When your agents change their seat, they should first login using a hardphone, because otherwise they would still be stuck in an old ACD queue if they login with softphone after they have moved.
We have a similar problem.
When the phone is configured, a default queue is established. If the agent changes call teams, they are physically moved with their phone, and their default queue needs to change.
Before we attempt to do anything, we remove the Extension and related Position ID COMPLETELY from CME , but the set is still showing as acquired in the PBX. The only way we can get the set to be deacquired is to shut down TServer completely (a switchover will not work).
Tech support has said that we should remove from CME, then the tech should be able to OUT the set, but he is extremely reluctant, so as to avoid corruption.
What in the world does “bounce” the T server mean?
Kevin,
why do all that work if you can just have agents login manually via a phoneset the first time after they move? That should fix it.
We’ve got the same issue here (Meridian\Symposium). There is a specific fix for this problem in TS 6.5. Beancurd
Bounce reset, take down and bring back up, reboot, etc.
Like, when a ball bounces, it goes down, then comes back up. (unless, of course, you are throwing the ball against the wall, which sometimes we feel like doing to some systems… 
Do the release notes for TServer 6.5 say anything specifically about the deaquire issue with Gensys+Nortel? I guess what I am asking, not too well, is this a forsure or “I heard it was fixed.”
The agent logging in manually on the physical set rather than the softphone business sounds like a lot of messing around that might lead to Genesys loosing track of the status of the set initially. If the softphone is reconfigured with the correct queue, if you reconnect the softphone that should put the agent where they belong.
From what I am seeing, it sounds like the Config db server isn’t updating the application (in this case TServer) dynamically (that is, in real time) when the agent is removed via the CME. The way I understand it to work would be that agent would log out so one can do whatever needs to be done to the phone. Go into CME and remove him. When you do that the config db is changed and config_db Server sees it and updates its cache and (is supposed to) pushes the change out to TServer.
If you remove the phone from CME first it will deaqquire. But if the phone is broken it won’t deaqquire. But this has been fixed in tserver 6.5