Ways Contact Center Makes Me Cry, Chapter 3

Today’s troubleshooting episode is once again sponsored by UCCX and its numerous ways to bring grown engineers to their knees in despair.  That might be a slight overstatement, but only by a smidge.

Quick summary of the scenario: an established agent needs to move to a new desk and take calls from the new location temporarily.  I know what you are thinking, easy cheesy – IT unplugs her phone, totes it over to the new location, installs CAD on the new workstation, plugs everything in correctly, and leaves. User just shows up, logs in, and everything *works* – mission accomplished. IT is *that* good.

Yeah, that’s not what happened.

What if, for whatever perfectly legitimate reason that completely boggles the mind of any sane administrator, the user needs to have a brand new extension and a brand new phone added to this process.  Still pretty easy, right?  Well, kind of.

Being the diligent engineer you are, you remember to disassociate the user with her old phone, associate her with her new phone and extension- also selecting her new directory number for her UCCX extension in User Management. You even remember to add the new phone to the rmuser Application User to avoid those pesky JTAPI errors. Then you go ahead and reset the new phone a couple of times just for good measure.

You check resources in UCCX and you see the fruits of your awesome work reflected in the updated extension now showing for said user. You call the user and have her log in, expecting accolades and words of supreme gratitude and instead you are confronted with this beautiful piece of snark, beginning with the phrase The specified extension is not associated with the ID:

You promptly check with your system administrator as instructed and report back to yourself that you did follow the procedure for configuring an agent’s phone and UCCX can bite it.

Once out of tantrum state, here’s a more constructive approach to resolving this particular issue which I have seen more than a few times now:

Go ahead and check one more time, confirm that you really are seeing the updated extension in UCCX.  I know, I know, of course you did this right, but the first time you don’t check, it’ll be something that simple that gets you.

Then, in Cisco Desktop Administrator, run a resync of users.  Instructions vary on this one depending on the version. I can tell you that for the version in this little story, 7.0(1)Build168, the instructions are this:

1.       RDP/VNC to the UCCX server
2.       Go to Start> Programs> Cisco> Desktop> Admin
3.       Click on “Call Center1”
4.       Then go to Setup> “Synchronize Directory services”

You can perform these steps during production hours, but as always, proceed with caution if you have a lot of users or a server that is already overtaxed.  Please don’t tell TAC that Amy said it was okay to do this and she crashed your server, I doubt they will be sympathetic.  And they have my email address.

If you are reading this and trying to fix this issue at the same time, hopefully you won’t have to read any further.  But if you have my kind of luck, here’s the next step you can try:

1. Stop and Restart the Desktop Sync service:

I have stopped and started this service during production hours several times, but once again, please see the above disclaimer.  It’s *your* box, not mine…

And last, but not least, if you are still reading this for a solution, for one last hoorah, try this – NOT DURING PRODUCTION:

1. Stop and restart the UCCX node service.  For the version mentioned here, see below, for later versions look to Cisco UCCX Serviceability for the Node Manager service:

This typically resolves the issue, much in the way that applying a hammer to make a very fine adjustment often does. Stopping and restarting this service will take your call center down, so submit your request for a maintenance window with a smile.  Or be prepared to ask for forgiveness if you choose to just go for it.  Again, I wouldn’t lead with the phrase, but Amy said…

Published: 06/25/2012