Configure Network Binding Order for a Windows Server 2016 Failover Cluster

By:   |   Comments (5)   |   Related: > Clustering


A recommended best practice in previous versions of Windows Server operating system for failover clusters is to configure the binding order of the network adapters for all the nodes. In fact, if not properly configured, this appears as a Warning during the installation of a SQL Server failover clustered instance. However, I don’t see an option on how to do this in Windows Server 2016. How do I configure network binding order for the nodes in a Windows Server 2016 failover cluster?


In a previous tip on Installation and Configuration Outline, steps were outlined to configure network binding order for nodes in a Windows Server 2003 failover cluster. The process remained the same up until Windows Server 2012 R2. Unfortunately, the Adapters and Bindings tab for configuring Advanced Settings on the available network adapters is no longer available on Windows Server 2016.

advanced settings

Advanced Settings dialog box for Windows Server 2012 R2 (similar for earlier versions of Windows Server)

network providers

Advanced Settings dialog box for Windows Server 2016

This makes configuring the network binding order even more challenging. But before we go ahead and configure the network binding order for all of the network adapters of the nodes in a Windows Server 2016 failover cluster, we need to understand why we need to do it in the first place.

Network Binding Rule when Installing SQL Server Failover Clustered Instances

In the past, it is recommended to have multiple network adapters for a Windows Server Failover Cluster – one for production workloads and access to the Active Directory domain, another one for internal/private cluster communication (commonly known as heartbeat) and several others depending on how the failover cluster is configured. Windows Server 2008 allowed administrators to build a failover cluster even with a single network adapter. This assumes that you have multiple network adapters configured with NIC Teaming. When multiple network adapters are configured for NIC Teaming, it appears as a single network adapter from the point-of-view of the Windows Server operating system.

I’m not a big fan of having a single logical network adapter for a failover cluster, regardless of whether or not NIC Teaming was configured, particularly for physical server implementations (guest failover clusters on hypervisors don’t really need multiple network adapters as this should be handled by the physical server they run on top of). It creates the impression that only the network adapters should be considered for high availability and resiliency. I mentioned this on the previous tip on SQL Server 2012 Multi-Subnet Cluster Part 1. I still recommend having multiple network adapters in failover clusters to meet high availability, resiliency and quality of service (QoS) requirements.

The network binding rule when installing SQL Server failover clustered instances serves to verify that the network adapter configured to access the Active Directory domain network is at the top of the network binding order. If it isn’t, performance and availability problems might occur as the network stack will try to access the Active Directory domain for authentication. If, for example, the internal/private cluster communication network is at the top of the network binding order, the applications accessing Active Directory can time out because there is no path on the network to go thru Active Directory thru this network adapter.  By default, network binding order is configured in the sequence of how the network adapters were installed and added to the server.

If the Windows Server 2016 failover cluster is still joined to an Active Directory domain, it makes sense to properly configure the network binding order as how it has been done in the past.  Active Directory domain-independent failover clusters – briefly mentioned in this tip – do not need the network binding order configured as in the past.

Adapters and Bindings: Deprecated in Windows Server 2016

In Windows Server 2016 (as well as Windows 10), there are no components that still use the network binding order. Hence, Microsoft decided to remove it. By default, Windows uses the Interface Metric property of a network adapter to determine which route has the highest priority. The lower the Interface Metric property value, the higher the priority.

Also, the value of the Interface Metric property for a network adapter is automatically assigned, by default, and is based on the link speed. This is described in this Microsoft KB article: An explanation of the Automatic Metric feature for IPv4 routes.

Configuring Network Binding Order in Windows Server 2016

Letting Windows decide on how to prioritize the routing of traffic based link speed is fine assuming that you have configured your production network faster than your internal/private cluster communication network. In reality, they will both have the same speed because hardware is purchased in bulks instead of individually to lower procurement costs. Which is why you need to manually configure the prioritization or routing traffic thru the different network adapters in your Windows Server 2016 failover cluster nodes.

Using the GUI

You can use the Properties dialog box of the network adapter to manually assign the appropriate Interface Metric value. Start by doing this on the network adapter connected to the Active Directory network. Assuming that you are configuring a network adapter that has an IPv4 address assigned, select Internet Protocol Version 4 (TCP/IPv4) and click Properties.

lan properties

In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, click the Advanced button.

internet protocol version

In the Advanced TCP/IP Settings dialog box, in the IP Settings tab, uncheck the Automatic metric checkbox and type a low value in the Interface metric: text box. In the example provided, a value of 1 is assigned. A low value indicates a higher priority.

advanced tcp/ip setting

Click OK on all of the dialog boxes to save the settings.

Repeat the steps outlined above to assign an Interface Metric value for the internal/private cluster communication network adapter. Assign a value higher than the one for the network adapter connected to the Active Directory network.

automatic metric

For simplicity, assign the same values for all of the network adapters in the nodes of the Windows Server 2016 failover cluster.

Using Windows PowerShell

Another way of setting the Interface Metric value for a network adapter is to use the Set-NetIPInterface PowerShell cmdlet. Before setting the Interface Metric value, you need to know which network adapter you are working with. This is where the Get-NetIPInterface PowerShell cmdlet comes in. As mentioned in this previous tip, it is recommended to properly name all of the objects – disks, network adapters, etc. – in the failover cluster to easily identify them during administration.

The example command below displays the properties of a specific network interface, only referring to the IPv4 address.

Get-NetIPInterface -AddressFamily IPv4 -InterfaceAlias "<name of network adapter>"

In the screenshot below, notice how Windows automatically assigned the Interface Metric value to both internal/private cluster communication network adapter (Heartbeat) and the network adapter connected to the Active Directory network (LAN). Based on this Microsoft KB article, for the assigned Interface Metric values, the link  speed for both network adapters is between 10 Gb and 40 Gb.

windows powershell

Following the previous example and using the Set-NetIPInterface PowerShell cmdlet to assign the Interface Metric property value,

Set-NetIPInterface -InterfaceAlias "LAN" -InterfaceMetric 1  
Set-NetIPInterface -InterfaceAlias "Heartbeat" -InterfaceMetric 2

Again, you need to do this on all of the nodes in your Windows Server 2016 failover cluster.

Next Steps

sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip

About the author
MSSQLTips author Edwin Sarmiento Edwin M Sarmiento is a Microsoft SQL Server MVP and Microsoft Certified Master from Ottawa, Canada specializing in high availability, disaster recovery and system infrastructures.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips

Comments For This Article

Saturday, April 20, 2019 - 9:44:43 AM - bass_player Back To Top (79607)


You don't need to change the Interface Metric property value at all if it is not affecting your SQL Server. It is a common best practice to do this in previous versions of Windows Server due to different network speeds assigned per network adapter (or sometimes configuration of different network Quality of Service). The article was written with the assumption that you need to make modifications to Interface Metric property value on a Windows Server 2016 and higher.

Also, the number doesn't matter so long as the low value indicates a higher priority.

Sunday, April 14, 2019 - 6:36:55 PM - Rohan Back To Top (79556)

 Great description Edwin,

I am still in doubt, so should we be changing the metric or not? I undertsand when you say both are of same speed and hence there should be an order. But before explaining this to my sysadmins which as per default looks fine, how can i get this changed if this is really going to impact my critical sql server application hosted on the cluster. Also why the number was given 1 or 2? Can it be like 15 or 16, sorry just curious if that sounds weird :). Thanks

Monday, October 8, 2018 - 3:24:38 PM - Devon Back To Top (77896)

 Thanks for a great article.  It saved me a lot of time!! 

Wednesday, May 16, 2018 - 3:06:50 PM - bass_player Back To Top (75960)


For iSCSI traffic, you configure the network adapter with no cluster communication (Do not allow cluster communication on this network). Because there are no client communication traffic going thru this network adapter, you don't have to even configure the Interface Metric property. 

Monday, May 14, 2018 - 2:48:27 PM - Greg Back To Top (75941)


Great Article!


What happens if you are using iSCSI? Does setting the Network adapters for iSCSI to 2 slow down your iSCSI network? 

get free sql tips
agree to terms