Reading Time: 4 minutes
The other week I ran into an instance where a group of customers were unable to access Cisco Unified Intelligence Center. Upon further investigation I was unable to get to admin pages of much of the collaboration suite and call control systems from these users computers either. The suite was on various versions of 9.0.X and 9.1.X due to restraints with many third party integration’s. This issue will occur on anything using the cipher suite mentioned below and is not limited to these versions or applications. This is ultimately where the problem stems from but I’ll take you down the path.
To start I’m going to list the fixes in case you don’t want to read my troubleshooting methodology. Then I will walk you through my discovery and detail the fixes. Remember, which fix is correct for your situation will vary based on use case, security policies, etc.
Fix 1: Uninstall Microsoft Updates causing issue
Fix 2: Re-issue certificate (if possible) using strong ciphers (may require upgrading applications)
Fix 3: Use a different web browser
Fix 4: Re-order ciphers via Group Policy
Permanent link to this article: https://www.packetpilot.com/ms-kb-31616393161608-break-cucm-uccx-web-access/
Reading Time: 2 minutes
This post is primarily for archived documentation for myself in the event of possible future need. However, I was having a hard time finding any configuration examples for this task. The steps below are those I used to connect a 70inch Infocus Mondopad to our CUCM environment to be able to make video calls including sharing the Mondopads screen over the called Cisco phone.
Permanent link to this article: https://www.packetpilot.com/infocus-mondopad-registered-with-cucm-sip/
Reading Time: 5 minutes
The Scenario goes like this: A Synapps – SA Announce paging and messaging server integrated with Cisco’s CUCM hosting around 30 phone to phone paging groups. The paging had been working fine for months and out of no where one of thirty particular groups was putting in multiple trouble tickets over multiple days that the paging isn’t working.
So begins the troubleshooting and diagnosis. My first action was to monitor the paging server as it has a real time display of who is calling a paging group and which group they are calling at in given time. When I was monitoring this I could see multiple people calling multiple groups including the one in question. So this brings up one of those “what gives” questions. Are they just doing something wrong up in the area. Time to take a trip and raise that pedometer count.
I arrive in the area and try and locate and area where I can visually see and hear multiple phones. Easier said than done but in this case I was the only one available to work on the issue and knowing that the paging server will activate the speakerphone and mute lights when a group the phone is a member of is called this was my best bet and understanding what was going on. After making my first test page I can see that lights on the phones I can see are immediately lighting up, however I can’t hear audio. As I stand there dumbfounded with the phone still off hook all of a sudden the audio starts picking up the background noise. However, paging shouldn’t have a 6 second delay before you can start talking. Six seconds is a long time to wait after hitting page to start talking. So whats going on? It’s only one group experiencing this. What is different about their group? Time for a deep dive in the diagnostics world. Enter Wireshark.
Permanent link to this article: https://www.packetpilot.com/it-was-broke-but-the-sharks-got-to-it/