(This article assumes familiarity with Windows Deployment Services and image deployment in a Windows environment. For more information, please visit TechNet)
Windows Deployment Services (WDS) is an extremely powerful tool that you are likely already using if you are an IT support professional in a mid-sized or enterprise environment. Windows Deployment Services is available with a Windows Server Standard edition license and higher, and centralizes the deployment of Windows OS images and drivers. It allows images to be installed to PCs over the network via PXE boot. It also allows for the creation of “Discovery Images” which are WinPE images that are able to find WDS servers on different subnets (no network configuration required, aside from ensuring a route exists between the field office and the WDS datacenter), which is perfect for field techs that need access to many images, but have limited flash drive space.
Windows Deployment Services is compatible with other valuable deployment tools such as the Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager (SCCM). It’s a common misconception that Microsoft Deployment Toolkit and System Center Configuration Manager replace Windows Deployment Services, but a more accurate statement is that they extend Windows Deployment Services.
However, Windows Deployment Services does have its fair share of gotchas. Chief among them being that you cannot inject drivers into a WinPE that’s newer than the WDS server’s Windows version. So a Windows Server 2012 R2 server cannot (through the GUI) inject drivers into a WinPE for Windows 10 boot image or a Windows 10 install image. This is because the DISM version used by the server is older than the version of the WinPE/Windows 10 image. We’ll get into a workaround for this a little later.
Despite its shortcomings, Windows Deployment Services is still an extremely powerful (but finicky) tool for OS and driver deployment, and for many IT organizations it is “good enough.” If an endless torrent of driver issues plague your WDS environment, it may be attractive to ask upper management to pony up for SCCM. However, this very rarely, if ever, goes well…as long as the lights are still on, at least.
It is much more prudent to fix your WDS environment instead.
BYOC – Scourge of the Earth
My current employer is moving from a BYOC policy back to keeping PCs as internal assets in order to retain control over PCs. However, there are still a smattering of HP, Dell and Lenovo PCs and laptops in our environment, which presents challenges when it comes to deploying drivers. Here are some tips I have gathered fighting the good fight against corrupt and incompatible driver packages.
Tip #1 – Use WinPE for Windows 10
WinPE for Windows 10 is Microsoft’s updated offering of a pre-boot environment. This environment only supports a fraction of Windows features, but it’s just enough to deploy a full version of Windows from it. The reason I prefer the upgrade is because some RealTEK drivers work better (read: they work) on WinPE for Windows 10 rather than WinPE 3.1 (Windows 7 SP1’s version of Windows PE). WinPE for Windows 10 also offers an updated set of generic drivers that works with most Intel NICs out-of-the-box. Using this, I only have to inject 1 driver into the boot image to ensure that 100% of the PCs in the company can PXE boot the WinPE environment (and thus, successfully complete an imaging process).
This, however, creates an issue with WDS if you are running Windows Server 2012 R2 or lower. Since DISM will only operate on images that have a lower system version than itself, Server 2012 R2’s DISM won’t work on the WinPE for Windows 10 boot image to inject drivers, so they’ll need to be manually injected by an administrator using Windows Deployment Toolkit, which offers a newer version of DISM.
Tip #2 – Keep your boot images light
Driver corruption is the number 1 reason that image deployments fail. It is prudent to ensure that your boot images that load WinPE only have the minimum amount of drivers needed for image deployment.
For my boot images, I only include the network drivers as that is all that is needed for the devices in my environment to boot into a WinPE environment and contact the imaging server.
Also, remember to match your driver’s intended Windows version lines up with the WinPE version. Also, watch out for drivers that are specifically made for WDS as they are intended to be used in boot images and WDS driver deployments.
Tip #3 – Use driver groups and filters
This might seem like a no-brainer to some, but I am shocked at how many WDS environments I’ve come across that put all driver packages in the same group with no filters. This makes it extremely difficult to troubleshoot driver issues that may arise via corrupt or incompatible drivers.
A sane grouping and filtering strategy is to group and filter drivers by machine model. This way, if a driver is introduced that is applicable to a lot of PCs, which also happens to break images and deployments — it will minimize impact to just those driver groups, and make it easier to remediate the issue.
With the rapidly changing workplace and BYOC policies becoming commonplace, well-planned imaging strategies have become a must for the modern sysadmin. This post concludes the first part of a series on WDS. In part 2, we’ll talk about how to troubleshoot driver issues within WinPE, and an introduction to answer files.
Until next time!
Posted in Tutorials