Last night, I rebuilt my Windows Server 2008 machine at home to use the RTM build (it was running on an escrow build from a few days before it was finally released) and Hyper-V RC0. It was non-trivial because the virtual machines I had running on the server had to be recreated in order to move from the Hyper-V beta to the release candidate (which meant merging snapshots) and so it’s taken me a few weeks to get around to it.

The recreation of the virtual machine configuration (but using the existing virtual hard disk) meant that Windows detected new network adapters when I started up the VM. Where I previously had a NIC called Local Area Connection using Microsoft VMBus Network Adapter I now had a NIC called Local Area Connection 2 using Microsoft VMBus Network Adapter #2. The original adapter still configured but not visible. Ordinarily, that’s not a problem – the friendly name for the NIC can be edited but when I went to apply the correct TCP/IP settings, a warning was displayed that:

The IP address ipaddress you have entered for this network adapter is already assigned to another adapter Microsoft VMBus Network Adapter. Microsoft VMBus Network Adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?

That wasn’t a problem for my domain controller VM, but the ISA Server VM didn’t want to play ball – hardly surprising as I was messing around with the virtual network hardware in a firewall!

In a physical environment, I could have reinserted the original NIC, uninstalled the drivers, removed the NIC and then installed the new one, but that was less straightforward with my virtual hardware as the process had also involved upgrading the Hyper-V gues integration components. I tried getting Device Manager to show the original adapter using:

set devmgr_show_nonpresent_devices=1
start devmgmt.msc

but it was still not visible (even after enabling the option to show hidden devices). Time to break out the command line utilities.

As described in Microsoft knowledge base article 269155, I ran devcon to identify the phantom device and then remove it. Interestingly, running devcon findall =net produced more results than devcon listclass net and the additional entries were the original VMBus Network Adapters. After identifying their identifier for the NIC (e.g. VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}: Microsoft VMBus Network Adapter), I could use devcon to remove the device:

devcon -r remove "@VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}"

Result! devcon reported:

VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}: Removed
1 device(s) removed.

I repeated this for all phantom devices (and uninstalled the extra NICs that had been created but were visible, using Device Manager). I then refreshed Device Manager (scan for hardware changes), plug and play kicked in and I just had the NIC(s) that I wanted, with the original name(s). Finally, I configured TCP/IP as it had been before the Hyper-V upgrade and ISA Server jumped into life.

Just one extra point of note: the devcon package that Microsoft supplies in Microsoft knowledge base article 311272 includes versions for i386 and IA64 architectures but not x64. It worked for me on my ISA Server virtual machine, which is running 32-bit Windows Server 2003 R2, but was unable to remove the phantom device on my domain controller, which uses 64-bit Windows Server 2003 R2. I later found that devcon is one of the Support Tools on the Windows installation media (suptools.msi). After installing these, I was able to use devcon on x64 platforms too.