In the last couple of weeks my colleagues and I encountered several issues with virtual machines in relation to network configurations. These issues where relatively easy to fix but I wanted to write them down for myself and share them with you all. Problems first arose when we started vMotioning and/or rebooting newly deployed Windows Server 2012 Virtual Machines on ESXi 5.1 The network configuration of Windows would just reset to DHCP instead of the static address we assigned to it. The second issue happened with our Windows 7 Horizon View desktops after we deployed a new build. The Desktops got warnings about duplicate IP Addresses (only for IPv6) and our network administrator was receiving a lot of errors within Infoblox.

Issue number one:

For the first issue a colleague found a KB article. As the article describes the virtual machine kept running its guest customization which resets your network configurations. The article isn’t specifically written for Windows 2012 virtual machines, but since we only deploy new virtual machines with Windows 2012 we encountered the issue on that specific OS. To test if this KB article was indeed applying to our infrastructure we first checked if we where running ESXi build 1743533 (which we where) and applied the workaround that was described to a less significant virtual machine.

After we cleared the value for the advanced virtual machine setting tools.deployPkg.fileName we first tried to vMotion the VM to another ESXi host. This test went fine, network settings where still in place. Second test was rebooting the server using the vSphere client power buttons. This also ended with a positive result.

With both tests giving a positive reaction the decision was made to apply the patch that was described in the article. Now that all hosts where patched we tried vMotion and restarting virtual machines again and the problem was resolved.

Issue number two:

As described in the first part of the blog we deployed a new build for our View desktops and shortly after the deployment the warnings and errors started to occur. At first the idea was that some of the Netsh commands that we apply for IPv6 on our builds did not apply properly. Checking those settings turned out negative and we had to look further. Searching the Internet we found this article from Microsoft.

We deleted the Dhcpv6DUID entry found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters within the golden image and than provisioned some new desktops from it. This did the trick and both the desktops and Infoblox where free of warnings or errors.

Then the question arose, why is this happening now? What did we do differently compared to the previous builds? As the article describes the patch that should fix this issue was released by Microsoft back in November 2012! When looking in the list of installed patches we could not find this patch, so we took a look at our WSUS. In WSUS we found that the patch was approved for installation onto our desktops so why wasn’t the patch on our clients then?

As it turns out the last build that was made was now done with SCCM 2012 where as the previous builds were done with SCCM 2007. With SCCM 2007 the patches where installed from WSUS after the task sequence of SCCM was done. Now with SCCM 2012 we are using the build in mechanic of SCCM to deploy patches, however not all patches where yet approved for installation including the needed patch to prevent this issue.

So there you go, two different problems in relation to network issues. It’s not really rocket science to resolve them but its a shame having to waste time searching for these solutions, so hopefully this article can save you some time in the future 😉