Windows Deployment Services trumps Internet Connection Sharing

I imagine the responses to this post’s title will fall in to one of three categories:

  • What’s Windows Deployment Services?
  • What’s Internet Connection Sharing?
  • Why on earth would you use both in one machine?

To answer the last question I need to unveil a bit about the network approach that we’ve adopted for the Hyper-V on Windows Server 2008 R2 laptop build that I mentioned in my last post. One of the primary requirements was that the VMs must be isolated from the network in order to prevent machine conflicts, while maintaining limited outbound connectivity, primarily for communicating with the TFS server over HTTPS.

Although I’m not a developer, I made myself the first own dogfood eater recipient of the build in order to identify issues as early as possible in the pilot. In order to do so I built the image on a second laptop but I still needed something to run Windows Deployment Services (WDS) in order to capture the image. I was already running Windows Server 2008 R2 (RC) with the Hyper-V role and since I planned to move on to the new build imminently, I opted to install WDS on my laptop. This all went smoothly until I tried to connect externally from one of my Hyper-V virtual machines. ICS and WDS don’t play nicely together.

Internet Connection Sharing (ICS) is designed for home usage – say to provide connectivity to your X-Box from your home switch. It’s like network bridging, but rather than passing connectivity on to another adapter, it enables sharing via NAT, which prevents inbound traffic and can limit outbound traffic. These are desirable constraints in our environment.

So we have an enterprise class deployment solution and a home networking black box – both trying to allocate DHCP at once. Despite the fact that they are allocating addresses to/from distinct networks, this doesn’t work. The DHCP allocator fails to allocate addresses to ICS recipient NICs correctly, leaving the guest with an APIPA address. These are the accompanying event log IDs:

30002
The DNS proxy agent was unable to allocate 0 bytes of memory. This may indicate that the system is low on virtual memory, or that the memory manager has encountered an internal error.

31004
The DHCP allocator was unable to bind to the IP address 192.168.137.1. This error may indicate a problem with TCP/IP networking. The data is the error code.

Error 30002 was the most common and recurrent error – typically appearing whenever ICS was re-enabled on the host NIC. After a great deal of erratic behaviour, testing potential conflicts between bridged connections and ICS, reviewing changes in Windows 7 Network Location Awareness and the Windows Firewall, WDS was removed, resolving all 30002 issues and creating consistent ICS behaviour in all guests.

It’s probably worth noting (in case you didn’t already notice) that Windows 7 and Windows Server 2008 R2 are allocating ICS addresses on the 192.168.137/24 subnet, which is extremely welcome. 192.168.0/24 is one, if not the most prevalent home network IP range, forcing unwanted IP reconfguration at home and a potentially massive support burden. Whoever decided to sneak in this scarcely noticed/mentioned/documented change deserves a big pat on the back.

Also note: Routing and Remote Access Services (RRAS) is a more robust service that provides the same functionality as ICS (and much more), but since this system has been designed for developers who are not generally network gurus, we opted for a simpler approach.

In the end we worked around this problem by building a WDS Hyper-V virtual machine, which has a really small memory footprint and resolved all of the DHCP allocation issues. I should add that I’m really impressed with the low storage footprint in WDS, which makes running it in a VM all the more viable.

6 thoughts on “Windows Deployment Services trumps Internet Connection Sharing”

  1. Thanks for posting this. I just ran into an issue connecting to my VPN on a computer with ICS enabled. Disabling ICS wasn’t an option, but thanks to the info found here I figured out that disabling DNS for the VPN resolves the issue. Not ideal, but at least I can connect! (side note: hardcoding DNS and bypassing DHCP isn’t enough, surprisingly)

      1. Yes, I think so.
        To be more clear the computer in question is:
        1. Running ICS (that is, acting as the host to allow other PCs access to the internet)
        2. Connecting to a VPN using the built in VPN adapter in Windows 7.
        3. VPN is now configured to not use DNS.
        4. Using the default ICS settings. (I’m not actually sure how ports are opened/closed in ICS in Win7)

        However I spoke too soon about it working. The VPN connection still fails, but instead of failing immediately, it fails at seemingly random intervals, so now it’s usable but unreliable. The VPN connection works fine from other PCs that do not have ICS enabled, including (somewhat ironically) PCs that are connected to the internet via the host PC, even with DNS enabled on the VPN connection.

        Again to be clear:
        Computer A – Host computer running ICS
        Computer B – Client computer running VPN

        In this configuration, computer B is able to establish a connection over the VPN without any problems, even though Computer B is connected to the internet via Computer A.

        So whatever is happening is a compatibility problem between running VPN and ICS on the same computer, not necessarily a problem with running them on the same connection, if that helps at all…

        1. I think this will work for you if you just share from the VPN adapter when the VPN is connected. So:

          -disable ICS on your internet connection
          -establish the VPN connection
          -share the connection from the VPN adapter

          To share when the VPN is disconnected:

          -unshare the VPN connection
          -disconnect the VPN
          -reshare the internet connection

          Hope this helps.

          Cheers,

          Tristan

Leave a Reply

Your email address will not be published.