RSS

Monthly Archives: January 2012

Ways Contact Center Makes Me Cry – Chapter 2

A useful skill set to have as an engineer is to recognize when communication between devices has broken down.  Sometimes voice servers in particular need a kindly admin to step in and smooth over their cluster relationships; unfortunately, however, you’ll find they are just too ashamed to ask for help.

So here is a list of signs to help you tell when your UCCX servers have gone from perfectly compatible to particularly petty, but haven’t bothered to tell you about the upset.

Supervisors cannot listen to recordings.
In Cisco Agent Desktop an agent no longer see his/her call stats in the call log.
Historical reports gives an error message that no data exists for valid date ranges.
Historical reports tells you how exceptional you are with an Exceptional Error.*

If you see one or more of these symptoms, it’s likely one of your uppity UCCX servers has told the other he was taking his toys and going home. You can confirm this in one of several ways:

On versions below 8.x, check out the Data Control Center – both the Historical and Agent will likely display this gem of an error message: Error occurred while performing the operation. The cluster information and subscriber configuration does not match. The subscriber might be dropped (Please check SQL server log for more details).

On versions 8.x and above, you have a couple of options:

Go to UCCX Serviceability -> Tools -> Control Center – Network Services-> and see if the Cisco Unified CCX Database is showing as Out Of Service for either node.

OR

Navigate to Tools -> Database Control Center -> Replication Servers and you will likely be greeted with this happy little declaration (in case you can’t read the message below, it starts with the phrase Publisher is DOWN, happy indeed):

So what do you do if your UCCX servers are indeed giving each other the silent treatment?  Well, unfortunately, I’ve found that nothing short of rebooting cures this particular ailment.  Sure you can click that “Reset Replication” button (after hours, of course) but it’s about as effective as hitting the elevator button over and over hoping that’ll make it come faster – really people, it doesn’t help!  So just go ahead and plan that maintenance window to reboot the primary, followed by a reboot of the secondary.

But wait, there’s more!

If you noticed this issue because you are exceptional and your Historical Reports makes wild unsubstantiated claims that no data exists, just check out the solution under No Data Available in the Historical Reports in this link because there are a few more hoops to jump through:

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_tech_note09186a0080b42524.shtml

Yep, you get to uncheck boxes and recheck boxes, and THEN reboot!  The fun just keeps on coming!

So once your surly servers get an attitude adjustment in the form of a reboot, you’ll find that they have an amazing ability to forgive each other and everyone can now rejoice in cluster harmony.

*On one of my encounters with this issue I was lucky enough to generate not just an error, but an Exceptional Error.  Still makes me laugh.  Yep, still easily amused.

Published: 01/30/2012

 

Tags: , , ,

When license files meet Macs…

I don’t know about other voice engineers, but my Twitter stream sees a lot of activity around licensing and the fact that Dante himself might have trouble conceiving of a darker hell.  Thinking the entire process could not possibly get more difficult- I proved myself wrong with this particular adventure.

After having completed the ever-so-fun PAK registration process, I take my shiny emailed-to-me license file and attempt to load it to the server.  Right away the server flatly rejects my humble offering – using insulting phrases like “invalid” and “get a life”. (I *might* be exaggerating on that last one…)

What, pray tell, did the server dislike about my generous gift of a license key?  Honestly, no clue at the time. Most commonly the server’s adamant objection centers around the mac address of the server being incorrect in the license file.  So I performed a triple check on the mac, confirmed the correct part number ordered, and promptly pressed the TAC speed dial button on my phone.  (Indeed, I do have TAC on speed dial, a hazard of being a voice engineer…)

After several hrs of checking and rechecking the license file with one TAC engineer, then finally bringing in a fresh set of TAC engineer eyes, the source of the issue was discovered.  My problem was I had a Mac.  Of course, I never feel having a Mac is a problem, but in this case it was working against me.

You see, I was trying to upload the .lic file emailed to me – only it wasn’t exactly the file that had been sent. Outlook for Mac had “helped” me out and converted my license file to Classic Mac format.  Guess who doesn’t truly appreciate license files in anything other than Unix UTF-8 format?  Yep, pretty much any Cisco Unified voice server.

The solution was simple enough – open each .lic file and change the format from “Unicode (UTF-8), with BOM” and “Classic Mac” to “Unicode (UTF-8)” and “Unix (LF)” then re-attempt license upload. Then pour yourself a celebratory shot.

Here’s what you are looking for if doing this in TextWrangler, note this will be at the bottom of the text window:

This is what it looks like when Outlook for Mac has gotten a hold of your .lic file:

This is what it should look like when you’ve set the universe right:

For the record, there is a bug id for this issue, CSCte58452. Specifically it refers to Entourage and Unity Connection 7.1.3 – but my experience proves it’s reach extends to later versions of Outlook for Mac and of Unity Connection.

Here’s a link if you are so inclined, CCO account required: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCte58452

Publish date: 01/08/2012

 

Tags: , ,

 
Follow

Get every new post delivered to your Inbox.

Join 232 other followers