Windows Server 2012 Essentials remote client loses its Internet connection, here's your DNS-related fix

Posted Sep 10 2012 (updated on Nov 4 2013) in
  • HomeServer
  • Windows
  • Feb 27 2013 Update: Issue is promised by Microsoft to be fixed in the next public refresh. Meanwhile, this article covers a viable workaround/tweak (not really a fix). This issue was evident in Release Candidate, and is now seen the RTM versions, but perhaps only for those who do the "skip domain join" step before installing the client connector. Scroll down to the end of the article here for all the details from Microsoft, hosts/lmhosts editing suggestions, and a lively 'Disqus'ion below the post.

    So, you've downloaded and installed the new Windows Server 2012 Release Candidate Essentials from Microsoft's August 21st 2012 blog announcement here. And perhaps you have some clients also installed, and they run fine in your local network. But once those client connector connected PCs wander to other networks, they may find themselves in a pickle. They can't browse the web. Turns out their DNS is pointing to your server, but they're not on your network, so they can't "see" your DNS server. So they're toast. The fix is more complicated than just fixing the DNS, read on for backstory, or just jump ahead and follow along with the screenshots. And please make a comment below, to let others know of your successes (or failures). Even better, take a minute of your time to confirm with Microsoft that you've also had this bug bite you, just by clicking the up vote arrows and/or the "I can to" button at their site here, which looks like this:

    microsoft-connect-feedback-e5ad92125d4b7629fdcb2cc540f45bd0

    Here's the issue. Turns out that when you install the connector, the installer routine changes just the DNS portion of your primary network connection to the IP address of your WHS2012E system, leaving the rest as DHCP. When you're on the same network, the PC seemed to work fine after the install, and can browse the web. It's only when it goes offsite that the trouble starts. Even if that user has Hamachi VPN installed to connect to your network, they still can't surf. Since the Hamachi VPN service relies on DNS working as well.

    If you just talk them through resetting their DNS back to DHCP, the problem will strike again in less than a day. That's aggravating. Turns out the "Windows Server LAN Configuration" service is running on their system whenever it's booted, user logged in or not.  And that service resets the DNS IP back to your WS2012E system's private IP. Ouch.

    VPN-connection-that-client-connector-created

    This DNS issue happens even if you remove your client PC from the domain and go back to workgroup model right after installing the connector. This workgroup mode doesn't seem to have any side effects, you can still get to network shares, do backups, use the tap-to-dial super easy VPN connection (that it set up for you) to your remote server.

    If you skipped out of the domain join requirement entirely, and went with this method instead, How to skip domain joining during client deployment in a Windows Server 2012 Essentials network, I would suspect it also reconfigures your DNS. This is something I plan to confirm.

    This DNS issue bit me when trying to install a remote computer that was connected to my home network via LogMeIn Hamachi VPN, where soon after the successful install and configuration, I found the network connection died. The system had gone offline in LogMeIn UI list of systems, despite the stating the system was powered up. The user also noticed the computer couldn't browse the web, despite saying it was actually connected to the WiFi network. That was tough to troubleshoot remotely, verbally. Yeah, it's all beta/unsupported, I realize that. My pain, your benefit, here's my fix/workaround, that doesn't seem to have any unexpected/adverse side-effects, hopefully helping me ride out this beta period and get some more testing/feedback done.*

    *A server-side fix is also being discussed with the previous release here on Microsoft's forums, but not sure I want the remote PCs to always try to resolve through my DNS server before failing to their secondary DNS configuration, and that approach wouldn't have help me out of the pickle I was in.


    Step-by-step fix to get your client PC's DNS back to DHCP, permanently

    Well, at least until the client connector is automatically re-installed after updates someday in the future, at which time you may need to perform this fix again. Even better would be for Microsoft to address this with a better fix, I'm reporting this to their feedback site soon of course. (update, feedback submitted here)

    1) On your Windows 7 desktop or Windows 8 desktop (all the steps appear nearly identical in either OS), at the bottom-right of your Taskbar Desktop, in the Tray area, left-click the 'Network' icon in your system tray

    01

    2) Left-click “Open Network and Sharing Center”:

    02

    3) Left-click “Local Area Connection” for the Network Adapter that you're currently using:

    03-48653d597895c695dfda1ea56023d062

    4) Left-click the “Properties” button:

    04

    5) Left-click the “Internet Protocol Version 4 (TCP/IPv4)” option, then left-click the “Properties” button:

    05

    6) Note, the IP address of your Windows Server 2012 Essentials system shows up for the Preferred DNS Server, but probably don’t want that, particularly for remote computers, or that backup server isn’t left running. The fix is done by clicking on the “Obtain DNS server address automatically” option:

    06

    7) It’ll then change to this, click the “OK” button:

    07

    8) Click Close:

    08

    9) Now wait about 10 seconds, and it should then say “Internet”, click the “Close” button:

    09

    10) Notice how the connection along the top shows a solid line connected to “Internet”, you can also close this window:

    10-b2bb7651ea875eab0441fabdb19a4744

    11) If you have multiple network connections, say WiFi and Wired, please repeat this entire section again (back to Step 1 above), removing the fixed DNS IP for the not-currently-in-use Network Adapter as well. To get to the properties of those other adapters, click on the "Change adapter settings" link along the left edge of the Network and Sharing Center.

    12) Once all network connections are fixed, In either Windows 7 or Windows 8, just press the "Windows" key, then just start typing “services.msc” (without the quotes), followed by the Enter key:

    11

    13) Scroll through the long list, looking for “Windows Server LAN Configuration” and double-left-click on it:

    12-81b7a09e9c522fa972cbc3d70afadf70

    14) Change "Startup type:" from “Automatic” to "Disabled" in the drop-down menu:

    13

    15) Finally, click on the the “Stop” button, then click on the “OK” button, and you’re all done, problem resolved, and effective immediately, no reboot required:

    14

    Source: Issues With Fixed Ip Adresses? (On Client Pcs) Started by teq, Aug 30 2012 07:27 AM
    forum.wegotserved.com/index.php/topic/25241-issues-with-fixed-ip-adresses-on-client-pcs


    Nov 20 2012: Great news, this Microsoft Connect entry was just updated: Windows Server 2012 Release Candidate Essentials remote client loses its Internet connection due to DNS issue. by tinkererguy

    Here's the excerpt, direct from Microsoft:

    Posted by Microsoft on 11/19/2012 at 10:44 PM

    Hi tinkererguy, Thank you very much for submitting feedback to us via Connect. Your input is very valuable to us. We are happy to inform you that the particular issue will be addressed in our next public refresh – as a result we will be closing this feedback. Best wishes, Windows Server Team

    microsoft-connect-bug-id-761868-e0ed94d1e408ebe0b6bc36ff97aab999
    Microsoft Connect Bug ID 761868

    Feb 24 2013 Update: Turns out that with Windows Server 2012 Essentials, the actual release (RTM), this DNS behavior is still very much the same right through today. The console will warn you of the potential issue, pictured below. I've found it safe to just ignore, since my WS2013E server is not being used for DNS services for my clients. BPA-complaint

    bpa-complaint-a01fbe76df2675bd6b47fb2ce0dddfb6
    Ignore-the-rule

    Feb 26 2013 Update: Turns out that you may have trouble locating network shares on your WS2012E system when working remotely, using the built-in VPN. Fix is straight forward, tested it today (when working remotely). Network shares that were mapped using names (rather than IPs) began working just fine again, within about a minute. Reboot after making the changes, for a truly clean, convincing test. This does mean that your server is found via IPv4 instead of IPv6, so far, but so far, seeing no adverse side-effects of this method.

    1. Command Prompt Press 'Alt+x' keys, choose 'Command Prompt (Admin)', say 'Yes' to User Access Control
    2. Change Directories Assuming Windows is installed on your C: drive, type:
      C: cd C:\windows\system32\drivers\etc
    3. edit hosts file copy hosts hosts.bak notepad hosts add one line to the end of your hosts file, something like this (IP address of your WS2012E server, followed by a space or tab, followed by hostname): 10.10.1.100 vzilla
    4. edit lmhosts file copy lmhosts.sam lmhosts notepad lmhosts add one line to the end of your lmhosts file, something like this (IP address of your WS2012E server, followed by a space or tab, followed by hostname, careful, it's case sensitive): 10.10.1.100 vzilla
      See also Microsoft Support's How to write an Lmhosts file for domain validation and other name resolution issues, Article ID: 180094.

    Jun 18 2013 Update: The issue still exists! So this workaround is still needed, unfortunately. Even after updating to last week's UR2 (Update Rollup 2), I had to redo the steps above, to get my DNS squared away. There is some consensus on this longstanding issue:

    1. If you're doing the domain join skip when installing your client connectors, this workaround is probably a good idea for you, especially if your WS2012E system isn't booted 24/7, or some client systems are remote.
    2. If you've joined the domain when installing your client connectors, leave it as is, discussed here.
    3. Looks like we might be waiting until the release of Windows Server 2012 R2 Essentials before this issue gets properly addressed, see also a preview release that is coming soon, discussed here.

    This article, at TinkerTry.com/ws2012e-dns-fix, is apparently referenced as the workaround at the Microsoft Connect feedback site here. Even though the entry is "Closed", I went ahead and added a comment tonight, pictured below.

    Details-of-Microsoft-Connect-report-updated

    Aug 25 2013 Update:

    Good news, UR3 may finally fix this issue, at last! Read all about it here:
    Windows Server 2012 Essentials UR3 coming soon, with the DNS fix I requested? Aug 24, 2013.

    See also this excellent read that Jason pointed out on the forums here, where he tips me off to this gem:
    Unravelling the mystery of Client DNS with Essentials family Servers Jun 17 2013 by Robert Pearman


    Nov 04 2013 Update:
    New article about UR3 now out, Microsoft has acknowledged the problem, and help to (sort of) fix it:
    Windows Server 2012 Essentials Update Rollup 3 has arrived, with DNS fixes by Paul Braren, Nov 04 2013.