are obvious, there are a number of common but incorrect settings that keep Exchange Server running, but end up causing a variety of hard-to-find issues.
Network vendors provide the ability to bind two or more physical network interface cards (NICs) together in a single logical adapter. This technique, known as link aggregation or network association, reduces single points of failure in the network. The association comes in two forms: linking each network card as separate channels to provide additional bandwidth, or an active / passive link for redundancy.
In the days of Exchange 2003, the clustering component of Windows 2003 limited Exchange clusters. In other words, only the public network adapter (MAPI client) can be associated; private network cards could not. In Windows Server 2008, this restriction has been removed, per KB 254101.
Also, in an Exchange database availability group (DAG), clustered replication network adapters have no benefit if you can have multiple replication networks. Microsoft’s Tim McMichael discusses this in a blog post on Exchange Server Network Design.
Never use network association on interfaces that you will add to a Windows Network Load Balancing cluster.
Microsoft’s advice on IPv6 in Windows Server 2008 and later is clear. These versions of Windows Server were specifically designed to support IPv6. In the past, the Exchange team has specifically recommended not disabling IPv6 on Exchange 2010 or Exchange 2013 servers, unless you:
- Solve a specific problem;
- have been invited to do so by Microsoft support; Where
- Have followed the appropriate process to disable IPv6.
Today, Exchange requirements simply refer to official Windows guidelines on IPv6.
Disabling the IPv6 component completely is more complicated than just disabling the single component binding in the properties of the network adapter. IPv6 is not bound to the specified adapter, but the rest of the IPv6 stack, including all hidden tunneling adapters, is still active. The supported process to completely disable IPv6 is described in KB 929852, which provides an easy-to-use, downloadable Fixit Wizard.
Multiple network interfaces
When your Exchange Server network has multiple network interfaces – think of replication, storage, or backup networks on Mailbox servers or multiple websites on Client Access servers – there is the potential for confusion and errors. networking. Unnecessary components are a common source of DAG instability.
Only one interface can be the main interface. This interface registers in DNS and Active Directory and should be the only interface that uses Server Message Block (SMB).
Open the Properties page of your main interface and do the following:
- Make sure the “File and Printer Sharing for Microsoft Networks” and “Client for Microsoft Networks” components are enabled.
- Click on Advanced.
- On the DNS tab, make sure that “Save 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, do the following:
- If IPv6 is enabled on the main interface, enable it here as well.
- Make sure that the “File and Printer Sharing for Microsoft Networks” and “Client for Microsoft Networks” components are disabled.
- Click on Advanced.
- On the DNS tab, make sure that “Register this connection’s addresses in DNS” is disabled.
- On the WINS tab, make sure that “NetBIOS Setting” and “Enable LMHOSTS Lookup” are disabled.
The next step is to verify that the interface links are configured correctly. Before we go ahead, I suggest reading a TechNet forum discussion on how to change interface bindings.
Configure your interfaces as follows:
- The main interface should be at the top of the list of connections. All secondary interfaces should be below the primary interface.
- For each component, ensure that the IPv4 links for “File and Printer Sharing for Microsoft Networks” and “Client for Microsoft Networks” are above the IPv6 links (Figure 1).
Figure 1: Configure your primary interface bindings as well to avoid Exchange Server network configuration issues.
To note: If IPv6 is disabled on the system, the IPv6 links in Figure 1 will not be verified.
On secondary interfaces, all links must be disabled, as shown in Figure 2.
Figure 2: How to configure your secondary interface bindings to avoid Exchange Server network configuration issues.
Sometimes administrators find that the cluster virtual adapter in Exchange DAGs is not properly bound. These adapters use an APIPA auto-configuration IP address in the 169.254.xy address range.
Although it is 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 correct this configuration, follow the procedure described in the TechNet blog post by Jeff Hughes.
About the Author
Devin Ganger is an email architect and technical writer with over 15 years of experience administering email systems, Windows, Unix, and TCP / IP networks. Today, he works primarily with Exchange Server, Windows Active Directory, and associated Microsoft and third-party technologies. Ganger was recognized as a Microsoft MVP for Exchange Server from 2007 to 2011.