Geek of All Trades: Get to that Single Image
Using WDS Driver Databases can help you refine your image-based Windows deployment strategies to a refined science.
About 15 years ago I created my first Windows deployment image. Those were the days. Back then, the hardest part of image-based deployment was finding the right NDIS network drivers for your DOS boot disk.
Years later in 1999, my company’s chief engineer was in a bind. He needed to build a fleet of new desktops on an exceptional deadline. Short on resources and ready to try anything, I offered him a wager: If I could build 300 desktops in a month, he would promote me to server administrator. Having Symantec’s Ghost imaging technology as my secret weapon, I beat his deadline by a full week. Shortly thereafter, I became the company’s youngest server administrator in its history.
For many of us, the practice of “building desktops” hasn’t evolved much from those early days. Automated image deployment has dramatically accelerated the process. We can deploy hundreds, if not thousands, of desktops almost as fast as they’re delivered. There are changes afoot that may scare you for their added complexity while simultaneously impressing you with new levels of automation.
Two of these changes are most notable. First is the evolution from the traditional monolithic approach for creating Windows images. Replacing it is a layered approach I discussed almost two years ago in my December 2009 column, “A Case for the Layered Approach to Deploying Windows Desktops.”
The layered approach shatters the components of a Windows OS into discrete layers, which lets you flexibly insert whatever configurations you require. In fact, if you do it right, it introduces the possibility you may never need to troubleshoot desktops again. With the proper automations in place, rebuilding a desktop is faster than troubleshooting. Free deployment tools from Microsoft get you most of the way there, as I explained in my August 2010 column, “The Troubleshooting Singularity.”
The second change is the foundation of the layered approach: the single image that deploys everywhere.
Getting to single image deployment has been elusive for too long. Much of the problem stems from driver set differences among all the desktops and laptops. An HP Pavilion Elite desktop, for example, doesn’t use the same drivers as an HP Pavilion dv7t laptop. Thus, we’ve needed multiple images for OS deployment, one for each different driver configuration.
All of that changes with Windows Deployment Services (WDS) in Windows Server 2008 R2. If you’re currently using earlier versions of Windows Server for WDS deployment, consider upgrading to this new version. You’ll like what you’re about to see.
Figure 1 The Windows Deployment Services Drivers node.
Among the improvements to WDS, the most central is a new feature for creating an image that installs everywhere under the Drivers node. Figure 1 shows a picture of that node within the WDS console.
This new Drivers node completely changes the game. You can now populate a database of drivers a Windows installation can search. That database isn’t just the driver set for one desktop or laptop configuration—it’s one location to store all drivers for all hardware. Using the built-in Windows Plug and Play functionality, any Windows installation can use this custom database for finding drivers that correspond to any hardware.
This functionality is enabled through the same Plug and Play architecture that lets you plug in a new USB hard drive or digital camera and watch Windows locate the drivers for those devices. You can read more about this automated process in my new book, “Automating Windows 7 Installation for Desktop and VDI Environments” (see, “Plug and Play: Awesome for Windows Installations,” from Chapter 2, which explains the process).
Plug and Play: Awesome for Windows Installations
During Windows installation, the real power of Microsoft Plug and Play shines. You already know that Plug and Play is the service that watches for new hardware to be connected. When it detects new hardware, it matches the hardware component’s characteristics to the drivers available. When it finds a match, the correct driver is automatically installed, making the hardware ready for use.
Although you’re used to seeing its actions when you plug in a new device, Plug and Play is also in action during the install process. During install, Windows invokes Plug and Play to detect the installation hardware. The correct drivers are then installed if they’re available. If they’re not, Windows uses a generic driver when one is available. In the end, what you need is a mechanism to make custom drivers available during the install. If they’re available, Windows will take care of the rest.
Figure 2 The Add Driver Package Wizard.
That “mechanism” is basically the new WDS Drivers node. Within WDS, right-click Drivers and select Add Driver Package. You’ll see a screen similar to Figure 2. Adding driver packages requires you to unpack those drivers into their most elemental format. This wizard seeks a driver INF file along with the associated CAT, SYS, DLL and whatever other files the INF file needs to finish the installation.
Figure 3 An unpacked NIC driver for an HP laptop.
The actual process to unpack these drivers differs based on how they’re initially packaged. Most require unzipping at a minimum. HP, for example, distributes drivers within a self-extracting EXE file you download from its support Web site.
Don’t double-click this EXE. Use a third-party unzip tool like WinZip or 7-Zip to unpack the driver files. The result may look similar to Figure 3, where you see the INF file that the wizard in Figure 2 is seeking. Point that wizard to the location in Figure 3 to automatically ingest the driver into the WDS Drivers database.
Figure 4 A look at the available Driver Packages.
An INF file is really just a series of instructions for how to install whatever content the driver needs. Some INF files actually install more than one driver. That’s why the wizard’s next screen (see Figure 4) gives you a place to select or deselect the drivers you want to add. Select those you need and continue through the wizard’s remaining pages to add them to your Driver Group.
Automate Driver Addition
Adding a driver using those steps is an easy way to populate your database. There’s one added capability that elevates this tool to sheer brilliance, though. Most IT teams store their content on an IT-only server or share. That share might have folders with ISO files for applications, tools you regularly use, and probably a subfolder full of the drivers you’ve collected over the years.
Figure 5 A large group of drivers.
Take a second look at Figure 2 and notice which radio button is selected. The second radio button, “Select all driver packages from a folder,” is where the magic happens. It exposes a powerful way to add every driver from your IT share’s subfolder (and, although not specifically stated, every subfolder of that subfolder) all at once.
Select this option, point the Add Driver Package Wizard to your IT share’s subfolder, and watch it automatically ingest every driver you’ve collected over the years. Obviously, those drivers need to be unpacked using the process noted earlier.
Once you’ve completed this step, try deploying a Windows image with WDS. The Windows installation should pair the GUID for each device with one of the associated drivers. For each pair it finds, it automatically installs the driver.
Separate by Filters and Groups
Ingesting the drivers for my devices creates 26 separate driver packages. Each is a little different. As you can see in Figure 5, some of those packages are for different processor architectures. Other devices may require multiple drivers for different functionality. Right-click any package, select Properties, and look at the resulting Drivers tab to learn more about exactly which drivers each package intends to install.
Creating a single driver group for everything is a good starting point. Most deployment teams won’t need to go any further. There are occasionally some drivers that don’t behave well, however. Plug and Play may grabs the wrong driver for a device, or the driver has special hardware needs WDS can’t determine on its own.
You’ll know this has happened when a Windows deployment completes and the device doesn’t function or shows an error in Device Manager. You may simply want to separate your drivers for easier administration and visibility. The filters and groups within each Driver Group will help with this.
You’ll notice in Figure 1 there is already a group called DriverGroup1. Creating new groups is accomplished by right-clicking Drivers and selecting Add Driver Group. The Hardware filters and Image filters you can apply to that Driver Group after it’s created are much more valuable.
Figure 6 Applying a Manufacturing filter to a group.
Hardware filters limit a driver group’s contents to specific hardware characteristics. Figure 6 shows how you can create a Manufacturer filter that limits the driver group’s installation to only HP hardware. There are also filters for Bios Vendor, Bios Version, Chassis Type and UUID.
Finding these values takes a little up-front work. You must have an OS installed, if even just for a minute to grab those values. You can use the following Windows PowerShell commands to gather the information each filter needs (note that each filter’s value must be entered precisely for it to work):
- Manufacturer: Get-WmiObject Win32_ComputerSystemProduct Vendor
- Bios Vendor: Get-WmiObject Win32_Bios Manufacturer
- Bios Version: Get-WmiObject Win32_Bios Version
- Chassis Type: Get-WmiObject Win32_SystemEnclosure ChassisTypes
- UUID: Get-WmiObject Win32_ComputerSystemProduct UUID
You’ll need a lookup table to translate information from the Chassis Type query. That query reports an integer value that corresponds to the system chassis type. The WDS filter doesn’t use this value. Instead, it uses a label associated with the value. Figure 7 gives you the mapping you’ll need between the Chassis Type values and labels.
|Value||Chassis Type Label|
|4||Low Profile Desktop|
|13||All in One|
|17||Main System Chassis|
|20||Bus Expansion Chassis|
|23||Rack Mount Chassis|
Figure 7 Chassis Type values and labels.
Image filters work differently. Unlike Hardware filters, these compare values with the characteristics of the deployment image. Their comparison information is gathered from metadata attached to the WIM image file.
Image Filters come in three types: OS Version, OS Edition and OS Language. Unfortunately, gathering values for these types requires three very different—and very obtuse—mechanisms:
- OS Version: Gathering the correct OS Version requires constructing it from properties of the WIM image within WDS. In WDS, right-click and view Properties of the image you intend to deploy, then click the Version tab. Note the value next to Image version. This value will resemble the format 6.1.7600. Next, click on the Service Pack level item name and note its value. For Windows 7 without a Service Pack, this value would be 0. Add this value to the end of the previous value, separated by a period. The resulting format will resemble 6.1.7600.0. Enter this final value into the filter.
- OS Edition: Export the image you intend to deploy to a file by right-clicking the image and selecting Export Image. Export the image to a file, then from an elevated command prompt run the command dism /Mount-Wim /WimFile:<pathToWimFile> /index:1 /MountDir:<targetFolder>. This command mounts the WIM file, enabling the next command to gather the information it needs. Run the command dism /image:<targetFolder> /Get-CurrentEdition to report back the current edition’s value. Enter that value into the filter. Once done, you can dismount and dispose of the WIM.
- OS Language: This one is particularly challenging. First, run the somewhat-complex Windows PowerShell command [convert]::ToString((Get-WMIObject Win32_OperatingSystem OSLanguage | Select-Object -ExpandPropertyOSLanguage), 16). This command gathers the OSLanguagevalue’s integer value and converts it to hexadecimal. Match the resulting hexadecimal value to the culture name you’ll find here.
Figure 8 There is an Applicability setting for each Driver Group.
There’s one more setting worth noting as you start populating your Driver Group databases. Each Driver Group has an Applicability setting, found in the Driver Group Properties under the General tab (see Figure 8). You’d typically use this setting to install driver packages that match client hardware. This setting instructs Plug and Play to only install drivers for devices on the system during the installation. Consider this your default setting.
There’s an alternate setting for all driver packages in the group. Here’s how it works: Think about the USB hard drives, digital cameras or other devices you may someday connect. These devices also need drivers. Creating a Driver Group of those “someday” drivers and setting their Applicability to install everything means being ready for that day. When they connect their device, the driver is already available and ready for use.
Boot Driver Injection
Your Driver Group databases are fully automated for install images only. There are some desktops and laptops where WinPE can’t boot or install Windows without special drivers. These include computers with non-standard hard drives. Problem network cards or the occasional video card are also possibilities.
Figure 9 The Add Driver Packages to Boot Image Wizard.
Boot images aren’t as automated as install images. You have to inject custom drivers specifically into the boot image before using it. You can do this under the Boot Images node by right-clicking the boot image and selecting Add Driver Packages to Image. Starting that wizard brings you to the page in Figure 9.
This wizard automatically filters drivers to just those WinPE cares about. You can also adjust search terms in the top half of the wizard page. Clicking Search for Packages returns a list of the potential drivers that meet the filter. Select those you want to add and continue through the wizard. This process will take time to complete.
Be careful doing this. As I mentioned, Plug and Play gets confused about mapping between GUIDs and drivers. When it does, you may find WinPE hasn’t started the devices it needs to begin the installation. That means you’ve injected a confusing driver. As a rule, only add the minimum drivers you absolutely need to get WinPE doing its job.
When you do inject a driver that causes WinPE confusion, stop what you’re doing and recreate the core boot image. Install alternate drivers until you find the perfect set that works across all your devices. Trying to troubleshoot a WinPE is a complex process that can take more time than just recreating the image and beginning again.
The Foundation of Layering
Moving to layering makes desktop deployment a far simpler task, freeing you up for all the more exciting activities in IT. It’s only a foundation, though. You’ll soon add other technologies like automated user-data migration, packaged and streamed applications, and others in-between to further automate the process. You can realize that future of fully automated OS deployment today. Even better, you can get there with free tools from Microsoft.
Getting to that click-and-go nirvana for OS deployment is a future that’s already here today. There’s absolutely some setup work involved, and in some cases plenty of it. Paying that little bit of extra effort up-front will reap automation rewards into the far, far future.
Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.