I recently had a customer who converted a virtual vSphare Exchange 2010 guest to a Hyper-V guest. In that process you should remove all orphaned devices on the machine. But as it happens they aren’t immideately visible. You have to tell Device Manager to show hidden devices (like the orphaned ones are). You can read more about this here: Device Management
Now on to the Exchange related issue. Even after the hidden orphaned NIC from vSphare was removed, Exchange had serious trouble emptying its queues. Error message: 451 4.4.0 DNS query failed. Okay, what gives? A look into Event Viewer Application log file revealed more information:
And attached to this Event ID we also have some information from the mothership.
Running Get-TransportServer | fl *DNSAdapter* revealed:
Well actually it revealed the GUID of bf6e0c9e-ff6f-4943-848d-8fc9944898d8 (the GUID of the no longer present vSphare NIC). I forgot to take a screen shot before changing it. This shows that even after the administrator uninstalled the old virtual NIC and made sure it didn’t show up as a hidden device any longer, Exchange still hung on to it. Even after a reboot.
A GUID of all zeroes just mean grab any DNS Server setting of any available IPv4 enabled NIC. Funny enough this setting does not work on my home lab Exchange Server on Hyper-V. On that machine I have to specify the GUID of the Hyper-V NIC, just like this blog post by Tony Redmond discusses; Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS
Obviously Exchange Server is very dependant on working DNS settings, but sometimes it feels like Exchange is a bit too sensitive in its settings. More robustness would be greatly welcomed.