Virtual MS Cluster Node “Invalid Network Format” Error

I came across an interesting scenario recently where a node that is part of a Windows Cluster (hosting a SQL Cluster) on Windows Server 2012 R2 suddenly started reporting errors.

The node is part of a 2-node cluster with a 3rd VM acting as a file share witness for the cluster, and had just been moved between vApps in an IaaS / cloud environment to account for a DR provision (where DR is based on vApp membership, not at individual VM level).

Once rebooted, the cluster was showing some strange errors, and the cluster name had changed in the Failover Cluster Manager from ‘MSCLUSTER.DOMAIN.LOCAL’ to ‘MSCLUSTER.MSCLUSTER’. On renaming the cluster manually, the ever helpful Microsoft error message (seen in the image attached to this post) was:

An error occured whilst renaming cluster MSCLUSTER.MSCLUSTER. Error code 0x800704BE – The format of the specified network is invalid.mscluster

Troubleshooting this error was relatively simple in the end. The first range of tests was to do nslookups against the domain controllers. The full names were resolving, but short names were not. Pinging was the same.

Checking the domain properties of the VMs, I noticed that whilst they were still domain joined, their primary DNS suffix was missing, and this setting was applied in the Advanced properties of the Ethernet adapter. With this missing, short names would not be able to resolve, but FQDNs would fine.

The solution was simply to re-add the primary domain suffix into the Domain settings of each VM, and then reboot each VM. Once this was done, re-checking the Failover Cluster Manager showed that the cluster name had reverted back to the correct name ‘MSCLUSTER.DOMAIN.LOCAL’, and all the nodes were functioning correctly in the cluster.

The cause was identified as when moving the VM between vApps, the template from the IaaS provider made provision for forcing guest customization on next boot when moving between vApps. Not only did this remove the domain suffix, but it also reverted the domain DNS settings back to the IaaS provider instead of the local DCs, and also reset the IP stack to use DHCP. Once all these were reset, all was well with the world again.

Jeremy loves all things technology! Has been in IT for years, loves Macs (but doesn't preach to others about their virtues), loves virtualization (and does shout about it's virtues), and sometimes skis, bikes and directs amateur plays!


Leave a Reply

Your email address will not be published. Required fields are marked *