Windows Server 2008 Failover Clusters: Networking (Part 4)

The Windows Server 2008 Failover Clustering: Networking  three-part blog series has been out for a little while now.  Hopefully, it has been helpful.  Little did I know there would be an opportunity to write another part.  This segment will be short as it covers a very specific scenario.  One that we rarely see, but we have encountered it enough that I felt it might be worth writing about it. 

There are applications written to access resources that are being hosted in Microsoft clusters running on Windows Server 2008 (RTM + R2).  The resource could be a File Server, could be a SQL database, or whatever.  The point is that the required resource is being hosted in a Failover Cluster.  It is hoped that applications that need to function in this manner are written properly to locate the required resource being hosted in a cluster.  By that I mean I would expect an application to be written in a manner where it would first query a name server (DNS server) and then use the information obtained to make a proper connection to the required cluster resource.  In a Failover Cluster, that connection point is known as a Client Access Point (CAP).  A CAP consists of a Network Name (NetBIOS) resource and one or more IP Address resources.  The default behavior in a Windows Server 2008 cluster is to dynamically register CAP information in a DNS server provided it is configured to support Dynamic Updates.  This occurs when the CAP is brought Online in the cluster. There are applications that are not written in this manner.  There are some application that are written in such a way that they will make a local connection on a cluster node by binding to the first network adapter and then use the IP address configured for that adapter.  The end result is in a cluster, the first connection listed in the binding order by default is the Microsoft Failover Cluster Virtual Adapter.   This adapter uses an IP address that is drawn from the APIPA (Automatic Private IP Addressing) address range which is non-routable and not registered in DNS.

To assist with helping make these types of applications work better, we can use a utility that has been released for public download on the Microsoft MSDN site.  The utility is called ‘nvspbind.’  So, the first step is to download and install the utility on each cluster node.   The options we will be using are shown in Figure 1.


Figure 1:  Options for nvspbind

First we need to identify the adapter that is the Microsoft Failover Cluster Virtual Adapter by using the nvspbind /n command (Figure 2).  The adapter is ‘Local area connection* 9’. 


Figure 2:  Identify the Microsoft Failover Cluster Virtual Adapter

Next, we use the ‘nvspbind /o ms_tcpip’ to determine the binding order for IPv4 (Figure 3).


Figure 3: Listing the bindings for IPv4

We can see here, that the adapter is listed at the top of the binding order for IPv4 which is causing the problem for some applications.  We need to move the adapter down in the binding order so we will use the following command to accomplish that –

C:\nvspbind /- “local area connection* 9” ms_tcpip (Figure 4).


Figure 4:  Moving the adapter down in the binding order for IPv4

Note:  The adapter can be moved further down by using /– if desire.

Once the adapter has been positioned correctly in the binding order, the application can be tested to see if it now works as desired.

To further highlight the effect of this utility, we can inspect the registry.  First, we need to locate some information for the Microsoft Failover Cluster Virtual Adapter.  Navigating to the following registry key (Figure 5), and locate the adapter –



Figure 5:  Microsoft Failover Cluster Virtual Adapter NetCfgInstanceId

The same information shown in Figure 5 is also displayed in Figure 2.

With the information in hand, navigate to the following registry key (Figure 6) to verify the adapter is no longer listed at the top of the binding order.


Figure 6: HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Linkage

That’s about it.  Thanks for your time and, as always, we hope the information here has been useful to you.

Chuck Timon
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support