Windows 8.1 Pro with the Hyper-V Role installed. One physical NIC with a static IP address.
Configure an External Virtual Switch bound to the physical adapter.
Virtual machines can get to the Internet just fine but the Hyper-V server cannot.
Hyper-V server can’t even ping Bing.
Hmmmm…can’t even resolve bing.com. Looking at the IPv4 properties of the vEthernet (External) NIC there is no DNS configured.
Add the IP of the router (or whatever DNS server you use) back in for the DNS server(s). Now the Hyper-V server can access the Internet.
When creating the External Virtual Switch a dialog box popped up that said, “Pending changes may disrupt network connectivity. This computer may loose blah, blah, blah”. But then it says, “These changes also may overwrite some static changes. If that happens, you must reapply the static changes to restore network connectivity.”
So there you go. When configuring Hyper-V to use a NIC that has a static IP configured you may loose some or all of it when it moves those settings to the vEthernet NIC.
Description – When connecting to a server’s console you receive an error that says, “Unable to connect to the MKS: Failed to connect to server esxi01.laptoplab.net:902”
Cause – This is due to a DNS problem where the computer connecting to the console cannot resolve the name for the ESXi hosts. This is likely to happen in a lab environment. If this is happening in a production environment then you need to troubleshoot why you cannot resolve the names for your ESXi hosts. May be a sign of a bigger problem.
Solution/Workaround – Create HOSTS file entries for the ESXi hosts management IPs.
From my home network I signed up to watch a webinar. As is typical when registering for a webinar I was provided the option to download an ICS file to save to my Outlook calendar. I clicked the link to open the ICS file & Outlook 2010 (which was already open) hung for about 3 minutes then finally displayed the appointment.
I closed the calendar item then clicked the link again only this time I saved it to my desktop. I double clicked the ICS file & same thing. Outlook hung for about 3 minutes.
I run Process Monitor & open the ICS file again to get a capture. After the appointment opens I stop the capture. I set the filter to only show Outlook.exe. In a case like this where I’m not really sure what’s going on I go through each of the utilities on the Tools menu. Nothing is really jumping out at me until I open Network Summary.
What’s with Outlook connecting to these various IPs? I flip over to Process Explorer, open the Properties of the running Outlook process, & select the TCP/IP tab. I open the ICS file again. To my surprise I see Outlook making all these connections for the next few minutes.
Well this should not be happening. My Outlook profile is configured to connect to a CAS array which does not have a public DNS record. I run a DIG to see what’s getting resolved. (I’m using alternate info but the results are the same with my production FQDN.)
Yeah, that’s not right. I should be getting a status of NXDOMAIN & no answers.
So what’s going on? DNS Hijacking or as Cox Communications likes to call it…”Enhanced Error Results”. I’ll post some links below for further reading but in a nutshell, DNS hijacking means that when you browse to a website (i.e. query DNS for an FQDN) that does not exist the DNS server returns an IP address instead of an NXDOMAIN error. Since you received an IP address your browser will go to that site. A chill should have just gone down your spine.
In my case Cox was gracious enough to post an article on how to “opt-out of enhanced error results”. I have to hard code two alternate DNS servers in my router. Once I made the change & renewed my IP settings I did another DIG.
Much better. I open the ICS file & it pops right up. “Problem” solved I guess. Of course I wish Outlook would handle this a little better. I have been unable to find a KB article addressing this issue but if you know of one please leave a comment. One day when I have some spare time I might open up a case with Microsoft about it.
Links & what not:
Now before any DNS hijacking huggers out there say anything I’m well aware of this draft RFC but it’s expired therefore RFC 1035 & 2308 take precedence. Even ICANN thinks it’s a bad idea. See here & here.
You can also read up on the subject here.
I was in the process of enabling DNS scavenging following the steps in this blog post. I’m used to it already being on but going into an existing environment with it disabled & enabling it could be bad. I was at the “enable” phase mentioned in the blog when I thought that it would be nice to have an export of all the zones just in case. While I’m sure there are other solutions, this is mine.
- Browse to C:\Windows\System32\dns.
- Create a folder called export.
- Open a command prompt.
- Browse to C:\Temp.
- Run the following commands:
dnscmd /enumzones > AllZones.txt
for /f %a in (AllZones.txt) do dnscmd /ZoneExport %a export\%a.txt
- In the export folder you will now have a text file with an export for every zone (forward & reverse) in your DNS server.
- Now create a subfolder in the YYYYMMDD format under the export folder created earlier.
- Move all the text files to that folder.