Systems Engineering and RDBMS

  • Click Here for Decipher's Homepage

  • Categories

  • Questions?

    Please send your wish list of things that you would like us to write about or if you have suggestions to help improve this blog site. You can send all questions/suggestions to: Blog Support
  • Archives

  • Blog Stats


Changing the IP Subnet of a Microsoft Cluster

Posted by decipherinfosys on February 9, 2007

This entry collates with another entry:

The cluster that was the basis for these blogs was both migrated to a new domain and IP subnet all at the same time. The other entry discusses how to resolve the domain migration issues within Microsoft Cluster Services (MSCS), and this entry will deal with the topic of the new IP subnet.

New IP Addresses – Now What Do I Do?

Prior to moving cluster nodes and their corresponding SAN to a new IP subnet, there is some preliminary configuration that can be done. The IP addresses of the SAN’s Storage Processors (SPs) can be changed through the SAN administration console, like Navishpere for example, but the exact process varies slightly depending on the manufacturer.

Note: Please make sure to always review your product’s operations manuals prior to making any changes.

Once the SP addresses have changed, you will lose connectivity to them until the SAN network cables have been physically moved to the new subnet. Once everything has been re-cabled, boot the cluster’s nodes back up and change the IP addresses of their LAN network cards to the new subnet. Once this has been completed connectivity to the SAN administration console will be restored. The LAN network cards on each node should be the only ones whose IP addresses need to be changed – all cluster heartbeat IP address configureations can remain unchanged.

Network Path Could Not Be Found

Once the Cluster service is once again running on the nodes, opening Cluster Administrator will result in the following error: “The cluster service on node ‘ cannot be started. The network path was not found.” Error ID 53. What this error means in this case is that there are still some references to the old IP subnet lingering in the cluster’s configuration, even though the storage processor IP addresses have been changed, the virtual IP (VIP) address information is still configured for the old subnet. Now, many of you would assume that something has gone horribly wrong, and that the cluster will have to be destroyed and completely rebuilt. Not so! Time to go into our old friend the registry.

Regedit – An Administrator’s Best Friend

There section within the registry where IP address changes need to made are all under HKEY_LOCAL_MACHINE -> Cluster -> Resources. The sub-entries are cryptic numbers, so some digging will be required to find the IP addresses. – there will be about a dozen or so entries that you will need to look through. There are two or three resources whose IP addresses need to be changed, depending on your configuration:

  • Virtual IP address
  • Cluster IP address
  • MSDTC IP address

The root of each entry will have a Name key that tells you what each resource is. For example the following screen-shot shows you what the root of the cluster IP address looks like. Notice the Name key (Cluster IP Address in this case ) second from the bottom:

Cluster IP Address Resource Screenshot

Drilling one level down will take you to the Parameters directory, this is where the IP address itself resides as shown here:

Cluster IP Address Resource Screenshot

Double-click on the Address key and change the IP address to what is appropriate for the new subnet. Remember to also change the subnet mask if applicable. Repeat these steps for the Virtual IP and MSDTC IP addresses, and keep in mind the registry changes need to be performed on all nodes of the cluster.

Note: Always make a backup of your current registry settings prior to making any changes.

Once the registry changes have been completed you should be able to successfully reconnect to your existing cluster via Cluster Administrator. There may be some additional tweaks and modifications necessary to get your cluster back to 100% status, but resolving the issues related to the domain and IP address migrations will have you well on your way towards getting your MSCS cluster back to normal.

Sorry, the comment form is closed at this time.

%d bloggers like this: