Hyper-V Lingering Internal NICs – Unable to Remove

I recently had a Windows Server 2008 R2 server running the Hyper-V role with some Internal NICs created for private “sandboxing” of some VMs.  After adding some additional virtual machines to utilize the Private NICs, I was up and running.  This turned out to be a temporary situation until we put another server into production to host the machines.  Using VMM R2, I stored the virtual machines in the library once the new server was racked.  (I could have migrated but I chose to not do this)

The interesting thing that came up, hence the reason I’m posting, is the fact that when removing some of the private NICs I had errors that was causing the internal NIC to still be listed as a Microsoft Virtual Machine Adapter in Network control panel applet.  Using my typical approach, I immediately checked the registry for the NIC (it’s easy to find, do a search for the name you’ve provided the NIC like “My corpnet NIC”.  I found it, deleted it but here it goes the funny thing – it didn’t leave!  Phantom NIC is still around and is unable to be deleted via UI or registry.  Hmmm…

Using GUID to locate other areas in Registry

The search began now to find how this virtual NIC created by Hyper-V is still remaining on the Hyper-V physical host although Hyper-V doesn’t have it still listed as a Virtual Network Manager.  The method I used was to do a search for GUID assigned to the NIC by Hyper-V.  All internal and private NICs are provided a GUID when created and I located this GUID, did CTRL+F and pasted into registry editor and did a search.  Look at there…

As I usually do (not recommended, but I live dangerously), I right-clicked and selected delete on the node listed 0006.  This action preceded to fail with an odd Access Denied error.  How is this possible since I’m an admin on this server?  I was in a elevated administrator console when I opened Regedit so I should have the elevated token, but turns out it didn’t matter.  I then moved on to attempt to take ownership of the key that wouldn’t delete itself and turns out this was a no-go as well.

Owner is System – then let’s be System

When I right-clicked and attempted to take ownership, I noticed that the current owner was Local System.  Because I couldn’t seem to have any luck viewing any information in the GUID key (see below screenshot), I decided to take the drastic measure of elevating myself to run as Local System.  To simplify this process, I invoke Mr. Russinovich and his psexec.exe tool which allows me to open regedit as local system.

Launching Regedit as Local System

I downloaded PsExec and opened an elevated command prompt and typed:

psexec –i –d –s c:\windows\regedit.exe

Removing Phantom Properties in Regedit

After elevating to Local System, I was now able to access the details of the keys which prior to this gave me Access Denied.  I now successfully was able to delete the rogue Hyper-V NIC that wasn’t helping matters on this server.  Because this server happen to be a member of a cluster, this rogue NIC played havoc with the Network Bindings.

Summary

It is possible that, in some cases, previously needed or created NICs created by Hyper-V are not cleaned up properly.  In today’s post, I shared one of the techniques I’ve used to remove the phantom NICs.  I didn’t immediately post this “workaround” due to my desire to ensure that this server saw no ill effects from my ‘rip it’ approach.  The server, I’m happy to report, is still happy and running with no problems at all.  I hope this saves you some time in the future if you run into a similar problem.  Off to jury duty I go…

Thanks,

-Chris