Adding Drivers to Windows Deployment Services Boot Images

A while back, I posted an article on building a SharePoint development environment in Hyper-V, which included a part on automating deployment of the host machine. Although we’ve now moved to VMware Workstation, we still use this approach for automating deployment of our standard Windows 7 builds, and this commentary is generally relevant to any Windows Deployment Services (WDS) deployment.

When I learned WDS and the Windows Automated Installation Kit (which were both quite new in Windows Server 2008 R2 at the time), I contented myself with getting ~90% of the way to a fully-automated build, as the additional effort to get from 90 to 100% (mostly re: drivers) wouldn’t have paid enough immediate dividends and we needed to start capitalising on some of the other wins of our new environment. As is often the case, we never got back to that remaining 10%, but it’s become more of an issue in recent months, as we’ve added a few Dell Latitude E6410 and Lenovo W520 laptops – both of which had network drivers that the Windows 7/Windows Server 2008 R2 boot images didn’t recognise. Unfortunately the TechNet guidance on adding drivers to boot images is unclear (to me anyway), so I’m contributing this quick post to attempt to clarify the problem that we had and the simple step-by-step solution.

A matching network card driver was not found in this image

After preparing our image with current patches and making the state as general-purpose as possible, we ran SysPrep with Generalise and OOBE, then Shut Down the machine. I always Shut Down rather than rebooting because I don’t want to miss the window in which I need to hit F12 to trigger the PXE boot to capture the image. If the post-SysPrep boot initiates there’s a risk that the SysPrep rearm count will be incremented, which is rather undesirable.

During capture, I was able to run through the wizard but I was not able to connect to the WDS server during the imaging process. Not the end of the world… I just manually uploaded the image after the process completed. However, this was my first indication that all would not be well with the NIC drivers. Note: my solution below should be repeatable for the capture images as well as the boot images, correcting this issue as well.

When it came time to deploy the image, we got in to the Windows PE setup splash, but no further than this error:

WdsClient: An error occurred while starting networking: a matching network card driver was not found in this image. Please have your Administrator add the network driver for this machine to the Windows PE image on the Windows Deployment Services server.

An Outdated KB

As you will note in this knowledge base article (which dominates search results for this error), the work-around is fairly detailed and laborious. Nevertheless, I proceeded, with a few caveats.

1. I didn’t actually get the error that the KB article describes from the Setupapi.app.log, so after a bit of head scratching, I moved on to step 2, deducing which driver I needed from my extracted NIC driver INF file.
2. peimg /inf=driver.inf mount\Windows, from step 3h, just didn’t work for me. “PEImg” couldn’t be found. Eventually I figured out that PEImg refers to an older version of Windows Deployment Services, so this just didn’t work.

At this point I went back to the drawing board and started reviewing the Windows Server 2008 R2 TechNet documentation, leaving this KB article behind. I was pretty sure there was a less convoluted way of getting this done anyway. Eventually I found the Add Driver Packages to Boot Image Wizard, as I’ll detail in step-by-step instructions below, but now I was getting error code 0xc1420127 in the wizard, as detailed here (with a good screen shot) and here (with this solution):

1. Clear all your temp directorys.
2. Browse to “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WIMMount\Mounted Images” and delete any keys below this.

I think the important step here is the second one, which removes the mounted image that I never unmounted via imagex /unmount /commit mount; the registry keys align precisely with Imagex /info Drive:\remoteinstall\boot\x86\images\boot.wim andImagex /mountrw D:\remoteinstall\boot\x86\images\boot.wim 2 mountfrom steps 3f/3g/3h:

I purposely avoided committing the mount since I couldn’t make the PEImg changes, but this inadvertently caused the Add Driver Packages to Boot Image Wizard 0xc1420127error.

A much simpler solution

After deleting these keys, I was back on track. If I’d never stepped through the outdated KB article I could have followed these steps below and saved myself (and apparently a few others) much hassle, but for whatever reason the Add Driver Packagecommand has always eluded me – tucked away as it is under the Drivers node in WDS. I was always distracted by the Add Driver Packages to Image command under the Boot Images node, as in step 3 below, which gets you nowhere without adding the driver first. But once you find that and step through, it’s pretty easy.

1. Add Driver Package
   
2. Select driver packages from an .inf file
   
3. On the boot image, select Add Driver Packages to Image:
   
4. Click Search for Packages:
   
5. While adding the package to the image it will be temporarily dismounted. In order to account for this in advance you can temporarily disable the image before doing any of this and then re-enable it afterwards.

Repeat this process for other boot/capture images as needed, and make sure the driver matches the boot/capture image architecture. The install image doesn’t need to match the boot image architecture though.

Ultimately, this all shows off how much better WDS in Windows Server 2008 R2 is than its predecessors, which were dark arts that few could master. Not so any more, but unfortunately automated deployment is still confusing when it goes wrong  per the number of technologies that all support the same or similar ends, new and old, including WDS, WAIK, MDOP, SCCM, DISM, RIS, ADS and I’ve forgotten how many others, especially when the changing interrelationships between these products over time further obscures the quality of guidance.