MRA: Unable to communicate with ‘servername’. UcxnError: ‘HTTPError:403’.

Have you seen this one on your MRA (Expressway): “Failed: Unable to communicate with <server name>. UcxnError: ‘HTTPError:403‘”?  It happens when you try to add or re-add the Unity Connection node on Expressway under Configuration -> Unified Communications -> Unity Connection servers:

UcxnError HTTPError 403

Check if the password that is being used for the connection has expired. The solution is to tick the “Does Not Expire” check box for the user account that is used for the integration:

UnityConnection Web Application account password

It’s a simple thing to miss when you implement MRA for Ucxn nodes. Hope this saves somebody some time.

OpenSSL January 2016 Vulnerability

Cisco has released a patch for OpenSSL January 2016 vulnerability that is described in CVE-2016-0701 and also on Cisco’s Bug Tracker: CSCuy07473. The patch ciscocm.ciscossl_11.0.1-v5_4_3.k3.cop.sgn comes in a form of a COP file can be downloaded off CCO for version 11.0(1) or 10.5(2). No reboot is required after applying the patch, but installation after business hours is recommended. For more information, please consult the published Release Notes for version 11.0(1) or 10.5(2) for this update.

CUP Publisher Installation Stalls/Fails

It looks like I’m hitting another Cisco bug, this time at the installation of CUP Publisher node for a recently recovered CUCM cluster of two nodes. The installation from a bootable ISO goes smooth for the most part of the process, but then stalls with no error right after completing Security Configuration (which is a step right after Call Manager Connectivity Validation):

CUP_Error

This bug is described in CSCuv74715. First, CUP installer will try to buy some time:

CUP_Time

Then, after you you click “More Time” it will run the validation tests for about 20 minutes, ultimately resulting in the blank Error page as seen above.

Problem is, there is no version 10.5(2.230000.1) of CUCM or CUP available on CCO.  So the solution is to obtain the latest available build of the CUP for the same version (10.5.2 in this case) from Cisco TAC (or create your own bootable iso from non-bootable ISO that can be downloaded from CCO) and retry the installation process.

UPDATE: I will save you some time: you do not need to download a new ISO if the only installer you have available is 10.5.2.20000-1. The error message that should have appeared as the 10.5.2.20000-1 installer stalls is as follows:

CUP_NTP

In my case, the NTP synchronization on CUCM Publisher had status of “unsynchronised, time server re-starting”. In this particular environment, the NTP reference servers were Domain Controllers (so Windows-based). Cisco UC VMs are quite finicky when it comes to synchronizing time with Windows-based NTP servers; the solution is to point the CUCM Publisher to a Linux-based NTP server.

In order to change the NTP server references for CUCM Pub, SSH to it and first confirm that NTP is operational by issuing “utils ntp status” command (just like it says in the error message). If the status is anything other than “synchronised to NTP server (xxx.xxx.xxx.xxx) at stratum x”, try to restart the NTP by issuing “utils ntp restart” command and checking the status again. If you do have a Linux-based NTP server, you can change the NTP server reference for Pub by doing the following:

  1. Add the new NTP server by issuing “utils ntp server add xxx.xxx.xxx.xxx” command
  2. Remove old NTP server(s) by issuing “utils ntp server detele” command and selecting the old NTP server(s) at the prompt.
  3. Confirm the NTP service restart when prompted.
  4. Check the NTP status again by issuing “utils ntp status” command.

Once the NTP status shows synchronized, proceed with CUP server installation.

Hope this helps someone.

Jabber and Surface Pro 4

Those of you who have customers with Microsoft Surface Pro 4 tablet (or who are users of Pro 4 him/herself), please note that there is a known defect with Cisco Jabber for Windows and Cisco Jabber for TelePresence (formerly Movi) that affects video quality. The video from camera in both Jabber clients produces a green tint and as of this writing (Feb 17th, 2016), no fix is available from Cisco. This defect is documented under CSCuy18230, so you may want to track it on Cisco’s Bug Search tool. I promise to post an update when I hear about any progress from Cisco Jabber’s dev team.

CWMS 2.5 MR6 is here

This Maintenance Release, which was made available for download on CCO today, fixes quite a number issues, so an update is recommended. One of the fixes is a minor (perceived to be almost cosmetic) change to the order of dial-in numbers for audio: since November’s MR1 the order of the dial-in numbers has been changed to alphabetical. Prior to MR1, the order of dial-in numbers were as configured/shown in CWMS Admin interface (see CSCuu97168).

Please review the Release Notes for more information.

Unable to Share Screen in CWMS

Another day, another bug: there have been reports from WebEx users that they are no longer able to share their screen or individual applications in WebEx meetings. There are no errors, no pop-ups – no indication whatsoever – when you click on the Share button, nothing happens. This is a bug identified in Bug Tracker as CSCuv36151 and affects CWMS 2.5 releases up to and including MR5.

To confirm if the workstation is affected, launch the command prompt to quickly find out whether Microsoft update KB3069392 is installed by typing in the following command:

wmic qfe | find “3069392”

If you have it installed, the output would indicate the installation date of the update and you can quickly find it under the “Installed Updates” to uninstall it.

CSCuv36151

You can also try to uninstall the update from the elevated command prompt.

First, find the package name:

DISM.exe /online /get-packages /format:table

Second, remove the package:

DISM.exe /Online /Remove-Package /PackageName:Package_for_KB3069392~31bf3856ad364e35~amd64~~6.3.1.1 /quiet /norestart

Cisco has released a patch for its MR5 on July 19th, 2015, which is available on CCO for download. Refer to the readme notes for this patch to ensure that it is installed properly (you must upgrade to MR5 prior to appying the MR5 Patch 1).

Good luck!

J4W 11.0 + CWMS 2.5 = CSCuu81060

Since Jabber 11.0 has been officially released and posted on CCO, we have done a company-wide upgrade from 10.6 to 11.0. Shortly after, our end users started complaining about inability to start or join WebEx meetings. The error (in a form of pop-up) reads as follows: “Setup was unsuccessful. Please try again. Error [110] GpcUrlRoot“:

CWMS: Setup was unsuccessful

All affected users had IE as their default browser – that was clue #1. All affected users had Jabber 11.0 installed on their workstations – clue #2. Surely, prior to this massive deployment, IT has extensively tested this and all prior (beta) Jabber 11 releases under EAP, but no one in IT had IE set as default browser (can’t blame them). Hence, this defect has not been detected.

We’ve opened a case with Cisco TAC to troubleshoot the issue further. After playing with Trusted Sites list and zone security settings, it seemed that we had found the workaround. However, the TAC engineer who was assigned to our case just advised us of the defect CSCuu81060 which reads as follows:

Symptom:
When running Jabber 11 and 2.5 MR5+, Jabber 11 changes the GPC patch to C:\Program Files (x86)\Cisco Systems\Cisco Jabber\MeetingSDK\JabberMeeting\NewDS\MyWebex\ieatgpc.dll

This is not compatible with CWMS and causes WebEx meetings to be unable to start from IE/Productivity tools due to being unable to match the activex control used by CWMS when launching a meeting from IE/PT

Conditions:

Workaround:
Use a tested compatible version of Jabber as per documentation: http://www.cisco.com/c/en/us/td/docs/collaboration/CWMS/2_5/Planning_Guide/Planning_Guide/Planning_Guide_chapter_01100.html#reference_71EE5F550E5D4E89B982F64F16DCD0C2

Verified-release 11.0(1) 10.6(6)

So far, adding the FQDN of the CWMS to the Trusted Sites list seem to have done the trick for some users (you may need to tweak the Trusted Sites security zone to achieve the right effect). Another workaround is to set Chrome or Firefox as your default browser or use those browsers exclusively to launch WebEx meetings until a fix is released. Also waiting for some feedback from Cisco Jabber/CWMS Product Teams so hopefully will have an update for you soon.

Cisco Unity Connection: “Failed to Send Message”

I took a long break from blogging, not because there’s nothing to blog about, but because I’ve been tremendously busy at work. Since my last post, I have moved the blog to another hosting provider (which by the way wasn’t a big deal: getting a new account, spinning a new WordPress instance and restoring posts and media from backups is super-easy these days), attended a Cisco Live! conference in San Diego (awesome experience), and migrated about half a dozen of telephony systems to Cisco Unified Communications Manager clusters (with voicemail, Jabber and all nine yards). Oh, and I have replaced my daily workhorse (a Dell Latitude for, well, another Dell Latitude).

Returning back to the topic of this post, I got frustrated trying to upload a WAV file with a greeting to a system call handler in Unity Connection, as Java was giving me the ambiguous “Failed to Send Message” error. The frustrating part was that I have already dealt with the issue a while ago, but the problem resurfaced with the new laptop of mine and I couldn’t remember what the fix was. You can obviously Google the error message and get a couple of links to posts on Cisco.com, but some of the info was not applicable for Unity Connection 10.5 that I was using. So for anyone out there who is looking for a definite solution, here it is.

To start, the issue is definitely JRE-related. After clicking about half a dozen of “Accept” Java security prompts and finally managing to launch the embedded Java applet in the Unity Connection greeting administration page, the “Failed to Send Message” appears after uploading WAV file and hitting the “Save” button.

First, figure out which JRE version is being used in the web page. To do that, open the task manager as you have the Greeting page with a Java applet opened. In the list of running processes locate the JRE process, right-click on it and select “Open File Location”:

jre_process

Next, launch the notepad as Administrator and open the java.policy file located under ..\lib\security\ folder and append the following lines anywhere between the “grant {” and “};” to add the required permissions:

permission java.net.SocketPermission "10.10.10.10:443", "connect,resolve";
// where 10.10.10.10 is the IP Address of your Cisco Unity Connection server
// and 443 is the default HTTPS port (for BE6K you would want to use 8443 instead).
// If you have multiple nodes, add each one in the same list
// It may also help to add the FQDN or the hostname of your Unity Connection, if you open the admin page by using either of the two:
permission java.net.SocketPermission "cuc-01.mydomain.com:443", "connect,resolve";
// where cuc-01.mydomain.com is the FQDN of your Cisco Unity Connection server

Close the file, saving changes, re-launch the web browser and try again. It should work this time.