Changing DAG & DAG members IP addresses

This article describes the steps needed in order to change Database Availability Group (DAG) and DAG's members IP addresses.

The core steps for the IP addresses changes are based on KB230356 which explains how to change the Windows cluster’s IP addresses.

In addition to the steps taken to change the IP addresses of the cluster’s members, we should take into consideration the Exchange system the runs on the cluster’s infrastructure. Therefore, additional steps regarding to the Exchange 2010 system were added to this document.

The environment:

The existing Exchange environment contains 3 Exchange 2010 Mailbox servers in the DAG, one of the servers is also CAS & HUB.

Before making the IP changes:

- Before changing the IP addresses of the servers involved in the Exchange environment, write down as in the next table, the current and the new IP addresses:

- In this case, the current and the new IP addresses are in same subnet (255.255.248.0). This means that no subnet changes needs to take place.

- Update all the other messaging related consumers that this change might prevent them from getting the messaging service during the IP changes period.

- The IP addresses change is reversible. In case that something gets wrong because of network or other issues, you can revert back to the previous IP addresses configuration.

- It is recommended to suspend the databases replication and dismount the databases before making the IP changes.

Steps taken to change the IP addresses:

* In case you are moving the DAG / Nodes to different subnets, add the new IP that will represent the DAG as a mandatory step by running the next command (although you can do it via the EMC) before starting the next steps:

Set-DatabaseAvailabilityGroup –identity DAG -DatabaseAvailabilityGroupIPAddress 100.100.100.234,100.100.97.234

1. Verify that the cluster’s resources (IP & Name) are owned by one of the other cluster’s nodes and not on the node you are going to run the IP changes. In this case, the first IP change is going to take place on EX141. In order to check which node is owned the cluster’s resources, we should run the next command:

Cluster group “cluster group” /state

In case EX141 is owned the cluster’s resources, use the next command to move the resources to other node in the cluster (EX142):

Cluster group “cluster group” /moveto:EX142

2. Stop all Exchange’s services on the Exchange server which it’s IP is going to be changed first.

In order to stop all the Exchange services quickly, stop the “Microsoft Exchange Active Directory Topology” service (MSExchangeADTopology). Stopping this service will stop all other Exchange services in case you choose “YES” in the next screenshot:

3. Verify that all the Exchange’s services are in “Stopped” state and that no monitoring or other system started them up again.

4. Check the hosts file on all Exchange servers in the environment and verify that it doesn’t contains the DAG / DAG members IP address. The hosts file is located at the next path:

C:\Windows\System32\drivers\etc

In case that the hosts file contains IP addresses relevant to the DAG or DAG members, change those IP addresses to the new IP addresses.

5. Change the IP address of the network adapter on node EX141 to the new IP address. This requires the computer to be rebooted.

6. After the server is up and running again, verify that the node EX141 was registered in the DNS with A & PTR records.

7. Verify that the node EX141 can ping the domain controllers and that other servers can ping the servers. In addition, check the communication between the server and the HUB & CAS servers.

8. Before changing EX142 IP address, fail the cluster’s resources (IP & Name) over to the functional node EX141. In order to failover to EX141 node, run the next command:

Cluster group “cluster group” /moveto:EX141

 9. Change the IP addresses for the network adapters in node EX142 and reboot the server.

10. Verify that node EX142 can ping the domain controllers and that other servers can ping EX142. In addition, check the communication between the server and the HUB & CAS servers.

11. Before changing EX143 IP address, fail ail the cluster’s resources (IP & Name) over to one of the cluster’s nodes you have already changed the IP address (EX141 node, in this example). run the next command:

Cluster group “cluster group” /moveto:EX141

12. Change the IP addresses for the network adapters in node EX143 and reboot the server.

13. Verify that node EX143 can ping the domain controllers and that other servers can ping EX143. In addition, check the communication between the server and the HUB & CAS servers.

14. Verify that the cluster service is up and that all nodes are online:

15. Now change the DAG IP address to the new IP address (same as cluster). In order to change it, run the next command:

Set-DatabaseAvailabilityGroup –identity DAG -DatabaseAvailabilityGroupIPAddress 100.100.97.234

This command will remove the old IP address of the DAG and leave it with the new the new IP address only.

16. In case that you have changed the subnet mask as well, run the “DiscoverNetworks” option, in order to force rediscovery of all DAG networks:

Set-DatabaseAvailabilityGroup –identity DAG -DiscoverNetworks

17. Verify that the in “Failover Cluster Manager” that the cluster resources are up with the new IP address:

18. Verify that all the Exchange services on all nodes are up

19. In order to verify that the DAG’s IP address was changed, run the next command:

Get- DatabaseAvailabilityGroup dag –Status | fl DatabaseAvailabilityGroupIp*

20. At the Failover cluster manager, double-click the IP Address resource to open its properties.

21. On the Parameters tab in the IP Address resource properties, make sure that the Network to Use box contains the new network as the network to use:

22. Verify that the “Application” and “System” doesn’t contain any errors related the cluster or exchange.

23. Verify that the Cluster’s IP address is registered with the new IP address at the DNS.

24.Now check that the cluster is working by moving the resources to one of the other cluster’s members:

Cluster group “cluster group” /move

25. After all the infrastructure (Windows servers, cluster) was configured and working, verify that all the databases are at Mounted state.

26. Now move / activate one of the mounted databases to one of the other DAG members and verify that the activation is working as expected.

Comments

• Anonymous
  August 13, 2013
  Is this process the same for Exchange 2013?

• Anonymous
  November 24, 2013
  is there any procedures for Exchange Server 2007 CCR node ?

• Anonymous
  November 19, 2014
  Is needed to set firstly to set the node in maintenace mode before stopping the replication and dismounting the database?
  
  Additionaly, there is any document related on how troubleshooting in case there is an issue with the cluster?

• Anonymous
  March 08, 2015
  Great article, thanks for taking the time to write it!

• Anonymous
  March 20, 2015
  The steps outlined here work really well for Exchange 2013. With one minor chage that I needed to do which was to run Set-DatabaseAvailabilityGroup DAG –DiscoverNetworks as I noticed the MAPI Replication was "Misconfigured". Running the command above solved the issue.
  
  Great Article, and Kudos!

• Anonymous
  June 13, 2015
  Great Article - Worked very well in my Exchange 2010 SP3 environment

• Anonymous
  July 16, 2015
  I have a 3 node dag and i'm attempting to change the two IP addresses (one for each site) that the DAG is using. If I change an IP for the site with a single node, or vica versa, the cluster name stays offline despite one of the IP addresses still being active. If I revert to the old IP, it brings the cluster name back online. Any ideas?

• Anonymous
  August 05, 2015
  A couple of months ago I had a request from a customer to change the ip addresses of all their Exchange

• Anonymous
  December 29, 2015
  To Echo James - as long as the DiscoverNetworks option is configured in Exchange 2013 it simplifies the process significantly. I was changing 1 node on a 4 node DAG today and all I needed to do was using the Suspend and Resume steps listed in the Technet article here
  https://technet.microsoft.com/en-us/library/dd298159(v=exchg.150).aspx