Blog The Case of NIC Teaming VS Sysprep
By Nick Taylor
Published December 28, 2016
Estimated Reading Time: 4 minutes

Hello again all and I hope everyone had a great set of Holidays!  Today I’ll be blogging about an incident I ran across with sysprep on a bare metal host.  We were attempting to deploy out a new 4 Node Hyper-V 2012 cluster.  Our long term goal was to eventually take advantage of Bare Metal Deployments over IPMI in System Center Virtual Machine Manager but as this was the first Hyper-V cluster in the environment we wanted to build VMM on top of these hosts.  We moved forward with installing on our first host, running updates, updating driver sets, and then we decided to attempt to save some time but setting up the NIC teams in the image as well.

 

The last step of building out the NIC teams in the image ended up costing us a bit more time as it leads to some odd behavior.  Lets list out the steps of building the NIC team, syspreping the OS, seeing the encountered errors, and finally resolving those errors.

 

 

This is my base server that I plan to sysprep.  You can see no NIC teams yet exist

I’m going to create a new NIC team by the name of “MGMT” and set it to the defaults.

After a minute or two you can see I have a nice new happy little NIC Team

I’m now going to sysprep the OS so I can redeploy out this VHDX file to other VMs

As you can see Sysprep is doing its job and will then shutdown my original VM

After sysprep completed I copied the original VHDX file to a new location and renamed the VHDX file

I then created a new VM on my Host and pointed it at the copied VHDX

I added my adapters to my VM

Once my VM was up and Server Manager spawned I could see that NIC Teaming was indeed enabled but I could see my two adapters were getting individual addresses and not showing my team name with a single address like it should if things were working as intended.

I now launched my NIC Teaming console and I can see that the VM is showing “Host unmanageable”  In this console I cannot preform any operations other then a refresh.

So I moved on over to PowerShell and did a quick Get-NetLBFOTeam command.  I can see that my members are Ethernet and Ethernet 2

If I then take a look at my Network Connections I can see that I upon the addition of additional NICs they have been enumerated as Ethernet 3 and 4 and my original adapters no longer exist.  Of course this makes sense after watching it happen but how do we address the odd functionality in the NIC Teaming interface.

Luckily a simple PowerShell Remove-NetLBFOTeam Team Name lets me destroy the problematic NIC Team.  I do still see issues in the console until I reboot the effected VM.

Once Rebooted I can see in Server Manager that NIC Teaming is back to its original state of Disabled.

I can then go into NIC Teaming and see the functionality is restored.

In conclusion for NIC Team provisioning I’d recommend not creating teams prior to a sysprep.  Then either running some PowerShell to create the teams after deployment or in the case of bare metal host installs using Logical Switches paired with Uplink Port Profiles to define out your teaming and then deploying the OS via IPMI and Bare Metal Installation.  As always thanks for reading and have a Happy New Year all!!!

Post Tags: NIC Teaming
Article By Nick Taylor
Consultant – Model Technology Solutions Nick is an IT professional with more than 19 years of experience and a passion for learning about technology. His areas of expertise include datacenter, hypervisors, storage, network, cloud, and OSD. He spends his free time delving in crypto, video games, automation, IoT, and really anything nerdy.

Related Posts