The Cisco Smart Software Manager On-Prem Server Stopped Registering

[PETER NEBLETT]

All of a sudden our Cisco Smart Software Manager On-Prem server just stopped registering and/or stopped updating already registration information with all of our Unified Communication clusters. A TAC engineers told us to remove the port number from the URL, which was in place for several years, but did not changed the results. I'm now waiting for the engineer to call me back - Does anyone have any other suggestions ? 

[Roger Kallberg · Accepted solution]

Have you tried to deregister and then add the system back again? Sometimes I've seen this needed to kick then whole process into gear again.

[PETER NEBLETT]

A little history – Our Smart Software Manager (on-Prem) license server has been working in production for about 5 years and never had any major issues. Most of all the configuration never changed – not even after multiple upgrades which the last was successfully completed on February 1st, 2023.

We noticed this week the Cisco Unified application servers (all) stopped registering with the SSM server. The settings for the [Transport Gateway] parameter was configured the same for all the Communications Manager, Unity Connection, and Unified Contact Center Express clusters.

• {IP-Address}/Transportgateway/services/DeviceRequestHandler

Keep in mind – we’re already familiar with the process of deregistering and adding the server back but the process was not working this time around - we’ve tried multiple times.

After requeuing a TAC case with a second engineer - It seems now, possibly since we upgraded the SSM server to version 8.202212 – back in February, the transport gateway parameter now requires the fully qualified name of the SSM server without the use of the port number.

• {IP-Address.domain.org}/Transportgateway/services/DeviceRequestHandler

The resolution for the registration off all the Communication Manager clusters was to use the fully qualified domain name and eliminating the port number.

Note: We’re still trying to resolve the registration of Unity Connection and Contact Center Express... and we don’t have much time.

[Roger Kallberg]

I believe that use of FQDN has been best practice for quite some time. We have actually used that ever since we started use on-prem SSM, primarily as we have CA signed certificate deployed in the SSM and then use of IP address is not a really good idea as it's noyt in the SAN of the certificate.

[PETER NEBLETT]

Latest Update: YES !!

Re-registering Unity Connection to the CSSM server required the deletion of the server name from the [Product Instances] tab - which was recreated during the registration process. Unity Connection is now registered.

[Roger Kallberg]

Just an FYI on a recent issue we had with CCX and the same version of on-prem SSM that you use. It all of a sudden it stopped communicating with the SSM and we got this recommendation from TAC and it solved the issue we had.

"De-register the license> wait for 15 minutes > Perform a clean reboot of the UCCX servers and once both servers are up and running > re-register the license again"

[b.winter]

Are you sure, that the problem is on CUCM and not on the CSSM on-prem?
Have you checked the connectivity / registration there?