Clearly, Exchange Server 2010 and Exchange 2013 need a correctly configured network environment. While major misconfigurations are obvious, there are a number of common yet incorrect settings that allow
Networking vendors offer the ability to bind two or more physical network interface cards (NICs) together into a single logical adapter. This technique -- known as link aggregation or network teaming -- reduces network single points of failure. Teaming comes in two flavors: bonding each NIC together as separate channels to provide additional bandwidth, or an active/passive bonding for redundancy.
Back in the days of Exchange 2003, the Windows 2003 clustering component limited Exchange clusters. In other words, only the public (MAPI client) NIC could be teamed; private NICs could not. In Windows Server 2008, this restriction has been removed, according to Knowledge Base article 254101.
Additionally, in an Exchange database availability group (DAG), there is no advantage in teamed replication NICs if you can have multiple replication networks. Microsoft's Tim McMichael discusses this point in a blog post on Exchange Server network design.
Never use networking teaming on interfaces that you will add to a Windows Network Load Balancing cluster.
Microsoft's guidance onIPv6 in Windows Server 2008 and later is clear. These versions of Windows Server have been specifically engineered for IPv6 support. In the past, the Exchange team has specifically recommended not disabling IPv6 on Exchange 2010 or Exchange 2013 servers unless you:
- Are fixing a specific issue;
- Have been directed to do so by Microsoft support; or
- Have followed the proper process to disable IPv6.
Today, the Exchange requirements simply defer to the official Windows guidance on IPv6.
Fully disabling the IPv6 component is more complicated than simply unchecking the single component binding in the NIC properties. IPv6 is unbound from the specified adapter, but the rest of the IPv6 stack -- including all of the hidden tunneling adapters -- is still active. The supported process to fully disable IPv6 is described in Knowledge Base article 929852, which provides an easy-to-use downloadable Fixit wizard.
Multiple network interfaces
When your Exchange Server network has multiple network interfaces -- think replication, storage or backup networks on mailbox servers or multiple websites on client access servers -- there is the potential to create confusion and networking errors. Unnecessary components are a common source of DAG instability.
Open your primary interface's Properties page and follow these steps:
- Make certain that the "File and Printer Sharing for Microsoft Networks" and "Client for Microsoft Networks" components are enabled.
- Click Advanced.
- On the DNS tab, make sure that "Register this connection's addresses in DNS" is enabled.
- On the WINS tab, make sure that "NetBIOS setting" is either enabled or set to Default.
- Check that "Enable LMHOSTS lookup" is enabled (optional).
For your secondary interfaces, follow these steps:
- If you have IPv6 enabled on the primary interface, enable it here as well.
- Ensure that the "File and Printer Sharing for Microsoft Networks" and "Client for Microsoft Networks" components are disabled.
- Click Advanced.
- On the DNS tab, ensure that "Register this connection's addresses in DNS" is disabled.
- On the WINS tab, make sure that both "NetBIOS setting" and "Enable LMHOSTS lookup" are disabled.
The next step is to check that the interface bindings are correctly configured. Before moving forward, I suggest reading a TechNet forum discussion on how to change interface bindings.
Configure your interfaces in the following manner:
- The primary interface should be on the top of the Connections list. All secondary interfaces should be below the primary interface.
- For each component, ensure that the IPv4 bindings for "File and Printer Sharing for Microsoft Networks" and "Client for Microsoft Networks" are on top of the IPv6 bindings (Figure 1).
Note: If IPv6 is disabled on the system, then the IPv6 bindings in Figure 1 would not be checked.
On the secondary interfaces, all bindings should be disabled, as seen in Figure 2.
Occasionally, admins find that the cluster virtual adapter in Exchange DAGs is not properly bound. These adapters use an APIPA auto-configuration IP address in the169.254.x.y address range.
While not visible in the Network Control Panel applet, you can see this adapter if you run ipconfig /all from the command line. If this adapter is first in the binding order, the server will respond to its own pings with the APIPA address. To fix this configuration, follow the process in the TechNet blog article by Jeff Hughes.
About the author
Devin Ganger is a messaging architect and technical writer with more than 15 years of experience in administering messaging systems, Windows, Unix and TCP/IP networks. Today, he works primarily with Exchange Server, Windows Active Directory and related Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.
This was first published in March 2013