Geek of All Trades: The Availability Answer

When configuring highly available Dynamic Host Configuration Protocol in Windows Server 2012, you can now include features and support that were never there before.

Greg Shields

This was written using the Windows Server 8 beta. All information is subject to change.

Microsoft support for NIC teaming has been confusing at best. Prior to Windows Server 2012, Microsoft offered no support for teamed NICs. There were no drivers or any other functionality for bonding those NICs. That reality created plenty of confusion in the early days of Hyper-V. Many believed Microsoft wouldn’t support NIC teaming using hardware manufacturer drivers.

The truth with Windows Server 2008 R2 and earlier OSes was a bit more nuanced. Microsoft indeed did not support NIC teams, because Microsoft didn’t write the code. By using them, you weren’t violating any Microsoft support agreements. Any problems were the responsibility of the hardware manufacturer.

That confusion disappears in Windows Server 2012. The OS now includes native support for NIC teaming, written by Microsoft and thankfully now supported by Microsoft. Even better, NIC teaming configuration tools have become a native part of the Windows OS. Every NIC card, no matter who makes it, is configured with the same Windows interface.

The new high availability (HA) features in Windows Server 2012 benefit more than just NICs. Dynamic Host Configuration Protocol (DHCP) gets an HA facelift as well. You can now deploy Fault-Tolerant Scopes without requiring the complexity and overhead of a Windows Failover Cluster. DHCP never had it so good. Here’s how to set it up.

Highly Available Network Teaming

Network teaming has long been a challenging task, with different configuration interfaces provided by different manufacturers. Keeping up with the latest drivers added yet another level of configuration management. Teaming NICs in Windows Server 2012, on the other hand, happens via a universal interface.

To set up a team in Server Manager, you start by clicking Local Server | Network adapter teaming. Doing so launches the NIC Teaming control panel (see Figure 1). Click the Tasks dropdown box next to Teams and choose New Team.

Figure 1 Get started with NIC teaming.

Next you’ll see a window similar to that shown in Figure 2. Check the boxes next to the interfaces you wish to include in the team. You may also wish to configure a Teaming mode (see “Teaming Modes”) or Load distribution mode under Additional Properties.

Figure 2 Set up your new team.

Teaming Modes

If you’ve previously configured NIC teaming, you’re aware NIC teams usually require the assistance of network-side protocols. Prior to Windows 2012, using a NIC team on a server also meant enabling protocols like EtherChannel or LACP (also known as 802.1ax or 802.3ad) on network ports.

Those options remain today, as you can see in the Figure 2 dropdown box titled Teaming mode. Its selection for Static Teaming corresponds to IEEE 802.3ad, whereas LACP links with 802.1ax dynamic teaming.

There’s also an interesting third option called Titled Switch Independent. This lets you bond NICs without the assistance of network-side protocols. Switch Independent teaming is also compelling because it lets different NICs connect to different switches. Keep an eye on these settings, as there’s relatively little else known at this point about how they’ll work in production.

Click the link next to Primary team interface to expose a place to define a specific VLAN for the team. Click OK to close the control panel. In a few seconds, you’ll find your server now communicates via a brand-new NIC team. You can verify the successful creation of that team by finding the team’s name in the result of an ipconfig command (see “My Team – Default” in Figure 3).

Figure 3 Use the ipconfig command to verify you successfully created a team.

Take a peek now at Network Connections (see Figure 4), and you’ll see a new adapter for the team you just created. That adapter will be a Microsoft Network Adapter Multiplexor Driver, and will use the Microsoft Load Balancing/Failover Provider to interface with each physical NIC. If you view the properties of either physical NIC, you’ll see they’ve been reconfigured to use only the Microsoft Network Adapter Multiplexor Protocol. Once you’ve created them, network settings are configured only for the team, not each individual NIC.

Figure 4 Checking Network Connections will show you your new team adapter.

Highly Available DHCP

With your network connection now highly available, you’re ready to do the same for DHCP. To do this in Windows Server 2012 still obviously requires two separate servers. However, it no longer requires a Windows Failover Cluster. In place of that cluster is built-in support for fault-tolerant DHCP scopes. With two servers ready, here are the steps you’ll need to deploy one.

Start in Server Manager’s dashboard by clicking All Servers, and then click on the first of your two servers. Click Manage | Add Roles and Features, and click through the Add Roles and Features Wizard. Install only the DHCP Server role and accept the defaults. Repeat this for the second server. Once you’ve completed the wizard, you’ll notice that Server Manager has created a new DHCP server group containing your two servers.

You’ll also notice two new notifications in the Server Manager ribbon. Click the flag icon and select Complete DHCP Configuration to launch the DHCP Post-Install configuration wizard. Supply the appropriate credentials and click Commit to authorize each server in Active Directory Domain Services.

Once authorized, the process for creating and managing DHCP scopes is relatively unchanged from previous versions. Launch the DHCP console and create a scope on one server by right-clicking IPv4 (or IPv6 if appropriate). Then select New Scope. Configure the scope with the appropriate settings for your network.

Adding HA begins by right-clicking that scope and selecting Configure Failover. Supply the host name or IP address for a Partner Server (see Figure 5). There’s a checkbox at the bottom (grayed out in the figure) that lets you reuse any existing failover relationships.

Figure 5 Configure the failover services.

DHCP servers in a failover configuration can operate in either of two modes: Load balance or Hot standby. Servers in Load balance mode will share the address distribution. Hot standby mode identifies a partner server that will take over when the primary server fails.

Figure 6 shows the Load balancing (left) and Hot standby (right) configuration screens. On the left, you can adjust the percentage of addresses hosted by each DHCP server in load balancing mode. On the right, you can adjust the percentage of addresses reserved for use by the standby server. That range ensures a recently failed-over server can continue to distribute addresses after the primary fails, but before it assumes control of the entire scope.

Figure 6 Load balance and Hot standby configuration.

There’s an important distinction to make here about what happens when a server loses communication with its partner (called “communication interrupted” mode), and when that surviving server determines its partner is down (called “partner down” mode) and takes over control of the entire scope.

A surviving server enters communication interrupted mode once it loses communication with its partner. At that point, you can manually change the surviving server’s state to partner down and failover the scope. You can also set the Auto State Switchover Interval to automatically change state to partner down after a specified number of minutes. Once in the partner down state, the Maximum Client Lead Time defines the amount of time the surviving server will wait before assuming control of the entire scope.

Finally, you can enable authentication for failover messages by checking the box marked Enable Message Authentication. Supply a Shared Secret to secure the authentication. Click Next and Finish to complete the wizard.

HA, There’s No Excuse

Getting HA for many of the Windows core services was difficult for a long time. With previous versions relying on vendor teaming drivers and Windows Failover Clustering, the sheer overhead of managing HA was often more effort than the result. Windows Server 2012 changes things for the better. Now there’s simply no excuse for not implementing HA at every turn.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.

Related Content

• Geek of All Trades: The USMT Is Your Friend
• Geek of All Trades: Certificates Made Easy
• Geek of All Trades: The Curiosity that Killed the App