The latest hurdle I’ve seen involves moving existing clusters to FQDN instead of IP. This usually involves making sure all endpoints registering to CUCM have DNS servers and a search suffix provided by DHCP.
Every installation I’ve done has been based on server name and DNS. One client had to change an installation back to IP in the server field because of their DNS domain hierarchy. Heading into DNS usually involves triple checking the DNS/DHCP side of the world before changing a cluster. For a long time Cisco TAC even advocated that cluster server names are set to the IP address. I’ve always had interesting conversations when I would open a TAC case on of my installations.
With the introduction of Jabber, certificates (and multi-SAN in 10.5), and IPv6 we finally have come full circle to needing the server set to FQDN. Since you cannot apply an invalid TLD or IP address into the subject or SAN field names you’ll need to get certificates based on an actual public FQDN. If you want full BYOD interoperability the certificates you get should come from a 3rd party valid certificate authority. (I like Digicert)
Long story short – your “CUCM > System > Server” should be set to hostname.domain.com
Foggy Bytes 
I’m in the same boat now since I just need to change from IP to FQDN, do you have any Cisco doc that explains how to do this on both CUCM and IMP servers. Customer is running version 10.5.1. Found a Cisco doc to change the IP and hostname but not for changing IP to FQDN. I don’t think we can use that Cisco doc if you have any other doc that you can forward that would be great. Thanks for your help in advance.
I can’t think of a specific document but changing this field doesn’t actually change the IP address or hostname of the server. All you’re really changing is the server to server cluster connectivity and what is put in the phone configuration files for connectivity. Of course there are a few other things but the primary concern is phone to server connectivity. You’ll need to make sure ALL endpoints, phones included, can resolve the FQDN of the servers. I usually recommend restarting the servers after this change to ensure it is working properly.
Thank you so much for your response. Yes, I have told that to customer already, they are verifying that in all DHCP pool for phones. I figured but just want to be cautious since the serves are in production already. Couple more concerns and want to be clear if customer is using 3rd party certificates do we have to regenerate certificates? Do we need to stop any service on IMP before we change that host name? Also there is IP address configured under IMP-Presence topology not sure how to change that since “Cluster Topology” option is missing in IMP version 10.x. I really appreciate again for your help. If you want me to contact Cisco for all this let me know I understand. Thanks again.
If the certificates are already in place there is no need to regenerate. Since you’re using 3rd party that are probably only signed 12 months be sure to set up the certificate monitor to notify someone before they expire. You don’t need to stop any service before changing the name on IMP. The IMP is now defined from the CUCM administration page as another cluster node so you’ll see it on CUCM “System > Server”. If it is a cluster change one node at at time and monitor DB replication. I recommend scheduling this change along with a reboot to ensure all services are restarted with the update. Take a look at the section “Node Name Change” in this document http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/10_0_1/ipchange/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100_chapter_0100.html
Thanks you so much that clears up all my questions. I really appreciate your help on this.
Hi Josh,
IP addresses can actually be included in the SSL Cer SAN (Ref. RFC 3280 https://tools.ietf.org/html/rfc3280#page-33), so there is no need to define the servers with FQDN just for Jabber.
BTW. Making CUCM to depend on DNS for all internal communications (and particularly endpoint registrations!) does introduce a non-trivial amount of risk (and personally not something normally I recommend for large enterprise deployments). But it’s good to know there are some brave souls out there moving past IP addressing 😉
Hi Jamie! Thanks for coming by and checking out this post. I guess one thing I should’ve noted in this post are the SSL issuance changes that have been around and are now upon us. Here is a link to the full summary from my friends at DigiCert. https://www.digicert.com/internal-names.htm
“CAs should not issue a certificate with an expiration date later than November 1, 2015 with a SAN or Subject Common Name field containing a reserved IP address or internal server Name ”
In short – FQDN is here to stay along with properly signed certificates. Cisco recently backed out a CUCM secure CTI connection requirement because it is taking a fair amount of customer education that secure first and properly signed certificates are needed.