Maintain Driver Configurations When Capturing a Windows Image

A common deployment scenario is to capture a single Windows® image from a reference computer and to apply it to a group of destination computers with identical hardware configurations.

To save time during installation and to speed up the out-of-box experience for end users, you can instruct Windows Setup that the hardware on the reference computer and the destination computers are identical. By doing this, Windows Setup maintains driver configurations during image capture and deployment.

Background

The Windows® 7 and Windows Server® 2008 R2 in-box driver packages include device drivers that support a wide variety of popular hardware. If your specific hardware requires additional device drivers to boot, you can preinstall additional device drivers on your Windows image. These additional device drivers are often supplied with their device hardware by independent hardware vendors (IHVs). For more information about how to add device drivers, see the topic Add Device Drivers by Using Windows Setup in the Windows® OEM Preinstallation Kit (Windows OPK) User's Guide or Windows® Automated Installation Kit (Windows AIK) User's Guide.

To prepare a Windows image for deployment to multiple computers, you must use the System Preparation tool (Sysprep) tool to generalize the Windows image. Generalizing a Windows image removes the computer-specific information and prepares the device drivers for first boot. This preparation includes the following steps:

• Device state for hardware is removed.

• Boot-critical driver settings are reset to their default values.

• Device log files are purged.

The unattended-Setup setting: Microsoft-Windows-PnpSysPrep\PersistAllDeviceInstalls can save time by preventing Windows Setup from removing and reconfiguring the device state for identical hardware. On first boot, the detected device drivers are already preconfigured, potentially enabling a quicker first-boot experience.

It is good practice to not use the PersistAllDeviceInstalls setting on your primary reference image. Instead, for each group of computers with a different hardware configuration, first load your primary reference image onto a new reference computer with the planned hardware configuration. Next, capture a new image of this setup and use the PersistAllDeviceInstalls setting.

For more information about generalizing the Windows image, see the topic Prepare to Capture an Image for Deployment (Generalize) in the Windows OPK User's Guide or Windows AIK User's Guide.

Hardware-configuration changes

For the PersistAllDeviceInstalls setting to work properly, the hardware configuration must be identical on the reference computer and the destination computers. Hardware configuration includes the following components:

• Hardware make and model.

• Firmware. Updates, revisions, and configuration changes can cause some devices to report different device driver-matching criteria or use different resources. For example:

  • PCI-based devices can embed different subsystem revision numbers into their reported hardware IDs.

  • BIOS revisions can change the ACPI namespace, causing existing devices to either be reported differently or to be introduced as new devices.

  • BIOS system configuration changes can result in system devices claiming different memory, I/O, DMA, or IRQ resources.

• Physical location. Slot, port, or socket numbers that devices are connected to must not change between hardware configurations. For example:

  • PCI expansion cards must be plugged into the same slot numbers.

  • USB devices must be connected or wired to the same port numbers on the same USB host controllers and integrated hubs.

  • Storage devices must be connected to the same storage controllers and channels.

Hardware-configuration changes that are likely to cause problems

When using the PersistAllDeviceInstalls setting, any hardware change can potentially cause problems. Some changes are more likely to cause problems than others.

Low risk

For these types of hardware changes, you may be able to work around potential driver conflicts and still use the PersistAllDeviceInstalls setting:

• CPUs with different clock speed.

• Amount of memory.

• Hard disk capacity.

• External input devices, such as keyboards and mice.

• Monitors.

For more information, see the Working around driver conflicts section of this whitepaper.

Medium risk

For these types of hardware changes, we recommend that you do not use the PersistAllDeviceInstalls setting:

• Video cards.

• Storage drives and media readers, such as optical drives and card readers.

• Internal or integrated bus devices, such as USB or 1394 devices.

With these types of hardware changes, using this setting may not reduce installation time, even if you work around potential driver conflicts.

High risk

For major hardware changes, do not use the PersistAllDeviceInstalls setting:

• Motherboard chipset or CPU brand.

• Storage controllers.

• Form-factor changes, such as from desktop to laptop or from laptop to desktop.

• Keyboard-layout changes, such as from a standard 101-key keyboard to a Japanese 106-key keyboard.

• Any other devices that are in the enumeration path of the Windows boot volume.

Types of problems that can occur with a hardware-configuration change

Even seemingly minor changes to the hardware or hardware configuration can cause severe or easily-overlooked problems, such as the following:

• System instability.

• Inability to use some of the basic or extended functionality of a device.

• Extended boot times and extended installation times.

• Misnamed devices in the Devices and Printers folder, Device Manager, and other device-related user interfaces.

• Severe system problems that leave the computer in a non-bootable state. For more information about which devices Windows Setup relies upon to boot, see the Hardware-configuration changes that can cause the system to fail to boot section of this whitepaper

Hardware-configuration changes that can cause the system to fail to boot

When the boot-critical hardware is not identical on the reference computer and destination computers, using the PersistAllDeviceInstalls setting can cause severe system problems that can leave the computer in a non-bootable state.

Boot-critical driver packages can belong to any of the following Windows 7 or Windows Server 2008 R2 device setup classes, as identified by the ClassGUID directive in the [Version] section of the .inf files in their driver packages:

For more information about these device setup classes, see the MSDN topic System-Supplied Device Setup Classes.

Undetectable hardware

When deploying a new computer to an end user, some hardware, such as a removable device or a device with an on/off switch, may not be present or detected during first boot. By default, on first boot, Windows Setup removes the preconfigured device state for undetected hardware.

To deploy hardware that may not be present or detected on first boot, add any applicable device drivers to the reference image, connect or turn on the applicable devices so that Windows can install them, and use the unattended-Setup setting Microsoft-Windows-PnpSysprep/DoNotCleanUpNonPresentDevices when capturing the image.

Driver revisions and driver ranking

Do not maintain multiple versions or revisions of the same driver package in the same image. Use offline or online servicing tools to update drivers. For more information, see the Updating drivers section of this whitepaper.

Normally, when Windows Setup boots a computer and there are multiple versions of a driver package, Setup determines which driver should be installed by using driver ranking. However, when the PersistAllDeviceInstalls setting is used, the normal driver-ranking processes do not occur and devices that use outdated drivers may remain installed. For more information about driver ranking, see the MSDN topic How Setup Ranks Drivers.

Updating drivers

If you do need to add a device driver to an image where the PersistAllDeviceInstalls setting is used, you can update your device drivers by one of the following methods:

• Use offline servicing tools such as Deployment Image Servicing and Management (DISM) tool or an unattended answer file. For more information about adding a driver offline, see the topic Add and Remove Drivers Offline in the Windows OPK or Windows AIK.

• Alternatively, use online-servicing methods or tools, such as an unattended answer file or DPInst. For more information about adding a driver online, see the topic Add a Driver Online in Audit Mode in the Windows OPK or Windows AIK.

Working around driver conflicts

To avoid driver conflicts between independent boot-critical driver packages, the IHV should make sure that each device driver uses different service names, registry key values, and binary filenames.

Example of a potential driver conflict

In the following example, a fictitious IHV named Fabrikam produces two types of storage controllers: the StandardController and the ExtremeController. Fabrikam assumes that only one type of storage controller is installed at a time on a given computer.

The driver package defines the StandardController and ExtremeController configurations to use the same driver service name, storctrl. The storctrl driver service uses different service settings that change depending on which hardware (StandardController or ExtremeController) is installed. Because both the StandardController and ExtremeController use the same service, they cannot coexist.

Sample driver package file: storctrl.inf

[Version]Signature = "$WINDOWS NT$"Class = SCSIAdapterClassGuid = {4D36E97B-E325-11CE-BFC1-08002BE10318}...[Manufacturer]%Fabrikam% = Fabrikam,NTx86[Fabrikam.NTx86]%StandardController% = StandardController_DDInstall,PCI\VEN_ABCD&DEV_0001%ExtremeController%  = ExtremeController_DDInstall, PCI\VEN_ABCD&DEV_0002...[StandardController_DDInstall.Services]AddService = storctrl,0x00000002,StandardController_ServiceInstall[StandardController_ServiceInstall]ServiceType  = 1 ; SERVICE_KERNEL_DRIVERStartType    = 0 ; SERVICE_BOOT_STARTErrorControl = 1 ; SERVICE_ERROR_NORMALImagePath    = %12%\storctrl.sysAddReg       = StandardController_ServiceSettings[StandardController_ServiceSettings]HKR,Settings,LowPowerMode,0x00010001,1HKR,Settings,ErrorCorrection,0x00010001,1...[ExtremeController_DDInstall.Services]AddService = storctrl,0x00000002,ExtremeController_ServiceInstall[ExtremeController_ServiceInstall]ServiceType  = 1 ; SERVICE_KERNEL_DRIVERStartType    = 0 ; SERVICE_BOOT_STARTErrorControl = 1 ; SERVICE_ERROR_NORMALImagePath    = %12%\storctrl.sysAddReg       = ExtremeController_ServiceSettings[ExtremeController_ServiceSettings]HKR,Settings,LowPowerMode,0x00010001,0HKR,Settings,ErrorCorrection,0x00010001,4...

If a StandardController is present on the reference computer and its settings are maintained during image capture, the storctrl driver service is preconfigured. When an ExtremeController is present on the destination computer, Windows may use the preconfigured settings and files intended for StandardController, which can create potentially unexpected results.

The IHV can help resolve the conflict by using one of the following options:

• Create separate driver packages with separate .inf files for each configuration, and import only the required driver package into the Windows image during deployment. For example, split storctrl.inf into two separate .inf files: one version for StandardController and one version for ExtremeController, and import only the required driver package into the Windows image.

• Alternatively, create another service in the driver package for each configuration. Give each service a different name (example: storctrl and storctrlx) and point to a different binary image file (example: storctrl.sys and storctrlx.sys).

For more information

To learn more about device drivers, see Understanding Device Drivers and Deployment in the Windows OPK or Windows AIK.