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.