When it comes to NIC teaming there are times that we need to pay attention to how the NICs get attached to the various services that will be run on the server.
If we are working with a server that will be solely a Hyper-V server using the native teaming in Server 2012 then we should be okay with the way the teaming process transpires and the resulting team(s).
However, when we are working with an OS that will have NICs teamed and it will also be delivering roles and/or services to the production network we have encountered some funky behaviours in that server _after_ the NIC team was created.
If we have a physical box with 4 NICs we have 4 MAC addresses.
When we set up the roles/services on that box before teaming and bind them to the IP address we will be setting to the team we run into a small problem.
The MAC address that is currently bound to the NIC with that IP address may _not_ be the MAC address that the team inherits going forward.
So, as a rule we recommend setting up the NIC teaming as one of the first steps before anything else is accomplished on the box.
We tend to set up two teams across at least two separate adapters. We prefer to run Intel NICs in our server configurations as a rule.
- Team 0: Management
- NIC 0 & 1 port 0 (2 ports)
- Team 1: vSwitch
- NIC 0 & 1 ports 1-7 (6 ports)
- On Server 2012: Static Team with Hyper-V Port chosen
From there, make sure the binding order is set correctly _after_ a reboot. If changes are made to the binding order then a reboot will be required.
- Start –> ncpa.cpl [Enter]
- Hit the ALT key on the keyboard
- Advanced Settings...
- Verify binding
- Production network is run by the guests so vSwitch gets priority.
Once we have our binding order verified we can look at setting up the respective VLANs.
As a side note, there does not seem to be any rhyme or reason to the way the NICs get named in the OS.
In the above snip, based on an Intel Server System R2208GZ4GC with dual Intel Quad Port i350 NICs, we have done a lot of testing with various storage setups. Thus, we have had a number of fresh operating system installs and to date _none_ of them have had the NICs named the same.
Since we always use the same two ports, port 0 on both NICs, we usually just pull the cables on those two ports for a quick “which one is which” check. Another way we could do that is via the Cisco SG500 series management console by turning off the ports.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book
Find out more at