cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12495
Views
5
Helpful
10
Replies

CUCM 10.5 Host Name and DNS Change

cragcisco
Level 1
Level 1

Hi Friends,

I am tasked to change Hostname and DNS Setting (Primary DNS IP, Secondary DNS IP and DNS Domainname).

My Voice setup contains:

CUCM (5 Nodes) Ver 10.5.2

CUC (2 Nodes)

IM&P (1 Node)

Questions:

Is there a sequence on which Role should go first (like CUCM First, CUC Second, IM&P Third)

Is there a sequence on Which Node to go first (like Pub First followed by Subscribers)

Is there a sequence on Which setting need to go first (Hostname First & DNS Setting Second).

Do i need to stop Replication before performing this change.

I went through the below document on DNS Change and Licensing Re hosting procedure

https://supportforums.cisco.com/document/12413781/how-change-dnss-ip-address-publisher-call-manager-105

Any other Additional Inputs or surprises anyone has come across with respect to 10.5.2

Thanks

10 Replies 10

Hi,

Please use below link.

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_011.html

If you have Prime Collaboration, this will be very straight forward

Hi Mohammed,

I am following the link you sent - strictly. I have not explored much on Prime Collaboration - will give a try on that too.

Thanks.

Wilson Samuel
Level 7
Level 7

Hi,

No 1 thing is that you MUST take a complete DRS backup and as well as the VMWare snapshot, so that just in case something goes unplanned, you can restore the things back.

Secondly, I wanted to know if you have any Public CA signed Certificates anywhere in the system if yes, then you MUST get a new certificate from the Public CA (this is the case even if you have a Private CA, but Private CAs are far less expensive than the Public ones, hence easier to do it)

Q. Is there a sequence on which Role should go first (like CUCM First, CUC Second, IM&P Third)

    I would start with the CUCM, and then IMP. CUC can be done independently, means it doesn't matter when you are really doing the CUC (it may be the first or the last)

Is there a sequence on Which Node to go first (like Pub First followed by Subscribers)

Publisher is always the first one to make the changes.

Is there a sequence on Which setting need to go first (Hostname First & DNS Setting Second).

Are you changing the DNS Server IP Addresses or DNS Domain Name or just the hostnames?

If it is DNS Servers only, then make sure all the info has been created in the new DNS Server

If DNS Domain change, then make sure all the information (Forward and Reverse Lookup Zones along with A Records, SRV Records and the PTR records have been created and tested 100% before you make the changes!!)

Do i need to stop Replication before performing this change.

No, I have never done that. 

HTH

Regards

Hi Wilson,

Thanks for your inputs and answers to your queries below:

Certificates: We are using self-singed CA.

Network Identifier Changes: We are changing all the four settings - Primary DNS IP, Secondary DNS IP Address, DNS Domain Name and Host Name. What is the sequence here - which setting needs to go first.

Thanks.

Hi,

If would have started in the following steps after taking DRS backups and vSphere, also run the RTMT and check all the CTI Ports, CTI RPs and device counts that are registered are counted for.

More over, I assume there is NO UCCX involvement in this.

1. New DNS Server Configuration 

a. Forward Lookup Zone (create if not already existing)

b. Create the Domain Name in the Zone

c. Create all the A and CNAME (if needed) entries in the new domain

d. Create all the SRV records for the IMP Servers

2. Test the new DNS Server Configuration using nslookup command. == VERY VERY Important step!!!

3. Change the Hostname and the IP Address on the CCM Pub, follow the same on the CCM Subs

4. Restart the cluster

5. Change the IP Address, Hostname and the DNS configuration on the IMP Pub Server and then Sub Server (if any)

6. Restart the cluster.

Wait for all the servers to come back up, run the RTMT and make sure all the devices are showing up as Registered

Once verified then, proceed to Step 7.

7. Change all the Voice Gateway references (dial-peer addresses and the Trunks / MGCP IP Addresses and MGCP Domain info is updated)

By this time all should be good with the CCM, try making calls EXCEPT the voicemails everything should be good.

CUC:

===

1. Change the IP Address, Hostname and the DNS Server settings on the Primaryr first, restart the Primary and follow the same on the Sec

2. Restart the cluster

3. VERIFY that DNS configuration is 100% accurate using nslookup command

4. Change the references for the CUCM in the Telephony configuration for the CUC

5. Restart the cluster

6. Verify there are no err messages in RTMT

At this point all should be good between the CCM and CUC

IMP

====

1. Change the IP Address, Hostname and the DNS Server on the Pub, restart the server, follow the same on the Sub

2. Verify the configuration using nslookup command (VERY IMP)

3. Restart the cluster 

4. Verify in the Presence Admin page that all services have come back ok

5. Restart the cluster

6. Regenerate the CSR all the CA Signed Certificates that are being used and re-apply to the IMP, CCM and UC hosts

Run the tests

HTH

 

Hi Wilson,

The change is only for Hostname of cucm (NOT the IP address of cucm) and to DNS entries. From your comments i understand that i have to change Hostname first and then change the DNS related configuration.

Thanks.

I am assigned to change Hostname,IP Address  and moving the servers to a different Host,where the DNS server is also different.

My Voice setup contains:

CUCM (3 Nodes) Ver 10.5.2  (1 Pub & Sub 1 in DC 1)only Publisher is moving one subscriber will stay in the same DC 

CUC (2 Nodes)  None of them are moving

CUEAC(Standalone) 10.5 moving  along with Publisher to different DC where CUCM SUB02 is residing.

AQM(Recording server) along with Publisher is moving.

Vsphere client 5.0.0 I can see all these device which i need to move on the same Host.

Need your input to do the same.

 

Pay attention to certificates. If your CallManager certificates currently have IP addresses in them, they will need to be regenerated with FQDNs. You need to do this one server at a time and reset all phones after each server, then verify that they are getting the updated certificates. If you change all of your servers at once and the phones don't have at least one trusted CallManager certificate, they will cease to accept configuration changes from CUCM. You can avoid this hassle if you are using CTLs, or if you put the cluster into rollback mode which blanks the ITL files.

If you plan on getting multi-SAN certificates, take this time to lowercase all of your server hostnames and domains.


Check your cluster health by running a Database Status report in Unified Reporting before you make any changes. Run a DRS backup.

If you opted for rollback mode to avoid certificate issues, do this now.

Make sure you have DNS A and PTR records configured before you do this. If the DNS records are not present then you will break replication.

Make sure you have the DNS client enabled on the servers and the domain set correctly. Run "show network eth0" from CLI to verify that the domain name and both DNS servers are set. If you do not have this set in OS/CLI then you will break replication.

Make sure that all of your Unified CM groups have 2 or more servers assigned.

Start with the publisher, change the IP address to the FQDN.

If you did NOT do rollback mode: Regenerate the CallManager certificate then reset a phone and check that it gets the new ITL with the FQDN instead of the IP address. If it does then reset all of your phones.

Repeat the last 2 steps for each subscriber.

Disable rollback mode then reset phones.

Update all of your MGCP gateways with the FQDNs.

Pre-change tasks and system health checks
DNS change
Before the configuration it is highly recommended to ensure that the prerequisites are met.
Step 1. Check DNS configuration.
Run these commands from CUCM CLI to ensure that DNS service is configured and FQDN entries for node names can be resolved both locally and externally.
admin:show network eth0

admin:utils network host cucm105pub.mydomain.com

Local Resolution:
External Resolution:
Step 2. Network diagnostic test.
Ensure that network diagnostic test is passed by running this CLI command.
admin:utils diagnose module validate_network
Step 3. DHCP configuration for endpoints.
Ensure that necessary Dynamic Host Configuration Protocol (DHCP) configuration is added for the registered phones to be able to do DNS resolution.
Step 4. Database replication.
Ensure that CUCM database replication is working. Cluster replication state must be 2 for all nodes.
admin:utils dbreplication runtimestate
Step 5. Backup.
Run Cisco Disaster Recovery System (DRS) backup of the current setup.
Hostname can be obtained from show status and the domain can be obtained from show network eth0 command output.
Change IP address (or hostname) from IP address to FQDN format for all CUCM servers listed.
In order to update configuration files, restart Cisco TFTP service on all CUCM nodes.
In order to push updated configuration files to the registered devides, restart Cisco Callmanager service on all CUCM nodes.
The main catch is that your MGCP gateways and all your phones will need to be able to resolve those names via DNS to register. You'll want to make sure your DNS is redundant and distributed geographically on all the phone DHCP pools.


Certificate back up
Step 1 On the Destination Cluster Publisher, navigate to Cisco Unified Operating System Administration and choose Security > Bulk Certificate Management.
Step 2 Define the Central SFTP server IP address, port, user, password, and directory.
Step 3 Use the Export button to export all TFTP certificates from the destination cluster to the central SFTP server.
Change the TFTP Ip address on the DHCP (Voice gateway or Switch) and reset the phones from current CUCM and hoping it will register to the new named CUCM.
If your cluster is using CA-signed certificates, you will need to have them re-signed.
Run the CTL Client to update the CTL file if you used that process to put your cluster into mixed mode. If you used the tokenless CTL feature, then run the CLI command utils ctl update CTLFile
UAT:
1. Ensure that all the endpoints successfully registered back with CUCM nodes.
This can be achieved with Real-Time Monitoring Tool (RTMT)
In case there is an integration with other servers via SIP, SCCP, MGCP protocols - some configuration might be required on the 3rd party servers.
2. Ensure that the change is propagated successfully to all the nodes in the CUCM cluster and the output is the same across all nodes.
Execute this command on all the nodes:- Admin: run sql select name,nodeid from processnode



Check the latest back up for all the below server and as mentioned by the customers, the latest back up is avaialable


the reachability of the new NTP server

Made the changes of NTP server reference in the following servers as Primary NTP server with IP address:
1. Cisco unified communication manager Publisher server
2. Cisco unified communication manager Subscriber server
3. Cisco IM & Prescence server
4. Cisco Unity connection server

Restarted the NTP Services in all the above mentioned servers
Current NTP stratum value as 4 with new server
Test Performed

Taken one Ip phone as reference and Restarted the IP phones, Check the NTP refrence