Windows Deployment Services

You can use Windows Deployment Services to install Windows to computers over a network instead of installing each operating system directly from a CD or DVD. To use Windows Deployment Services, you should have a working knowledge of common desktop deployment technologies and networking components, including Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Active Directory Domain Services.

Note

This documentation is a subset of the documentation that is online at http://go.microsoft.com/fwlink/?LinkId=134776.

  • Overview of Windows Deployment Services

  • Configuring Windows Deployment Services

  • Managing Windows Deployment Services

  • Resources for Windows Deployment Services

  • User Interface: Windows Deployment Services


Overview of Windows Deployment Services

Windows Deployment Services is a server role that enables you to remotely deploy Windows operating systems. You can use it to set up new computers by using a network-based installation. This means that you do not have to install each operating system directly from a CD or DVD. To use Windows Deployment Services, you should have a working knowledge of common desktop deployment technologies and networking components, including Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Active Directory Domain Services.

You can use the Windows Deployment Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=84628), which will lead you through installing this role, adding images, configuring the server, and then installing an image. It also includes instructions for how to perform more advanced tasks such as multicasting your images, creating your own images, and configuring an unattended installation.

Note

This is a subset of the documentation available online at http://go.microsoft.com/fwlink/?LinkId=134776.

Quick start checklist

To get up and running quickly, perform the following steps.

 | Task | Reference
Check box | Configure the server. | Configuring Windows Deployment Services
Check box | Add the default images (Install.wim and Boot.wim) that are included on the installation DVD (in the \Sources folder). | Add a Boot or Install Image
Check box | Install an operating system. | Install an Operating System

Tools for managing Windows Deployment Services

There are two tools that you can use to manage your server. For procedures for common tasks, see How to Perform Common Tasks (http://go.microsoft.com/fwlink/?LinkId=143204).

  • Windows Deployment Services MMC snap-in . A Microsoft Management Console (MMC) that provides an easy way to manage images, computers, and common server settings. You can perform almost all tasks from the MMC snap-in (for example, you cannot prestage client computers or manage .vhd images). Note that the snap-in is not available when you install only the Transport Server role service.

  • WDSUTIL command-line tool. A tool that enables you to manage the full functionality of the server. WDSUTIL also enables you to script common tasks. Simple batch files can run the required commands because the commands do not require an interactive user session.

Benefits

Windows Deployment Services provides the following benefits:

  • Allows network-based installation of Windows operating systems, which reduces the complexity and cost when compared to manual installations.

  • Supports mixed environments including Windows XP and Windows Server 2003 through Windows 7 and Windows Server 2008 R2.

  • Uses standard Windows Setup technologies including Windows Preinstallation Environment (Windows PE), .wim files, and image-based setup.

  • Transmits data and images by using multicast functionality.

  • Allows you to create images of a reference computer using the Image Capture Wizard, which is an alternative to the ImageX tool. For more information, see the “Creating Custom Install Images” section of Creating Images (http://go.microsoft.com/fwlink/?LinkId=115311).

  • Allows you to add driver packages to the server and configure them to be deployed to client computers along with the install image. In addition, you can add driver packages (such as network adapter drivers, mass storage drivers, and bus drivers) to your Windows 7 and Windows Server 2008 R2 boot images. For more information, see Managing Driver Packages.

  • Allows you to deploy virtual hard disk (.vhd) images as part of an automated deployment. For more information, see Deploy Virtual Hard Disk Images.

Additional references

  • Configuring Windows Deployment Services

  • Managing Windows Deployment Services

  • Resources for Windows Deployment Services


Checklist: Create a Custom Install Image

You can use Windows Deployment Services to customize the operating systems that you deploy. You can modify your images and create new images that are customized to your business needs. By standardizing applications, drivers, and configuration settings, you can increase consistency across your organization. For more information, see Creating Images (http://go.microsoft.com/fwlink/?LinkId=115311).

 | Step | Reference
Check box | Add a boot image to the server. | Add a Boot or Install Image
Check box | Create a capture image. | Create a Custom Install Image
Check box | Create a custom install image and add it to the server. | Create a Custom Install Image
Check box | Modify the image (optional). | Modify a Boot or Install Image
Check box | Deploy the custom install image. | Install an Operating System


Checklist: Manage Known and Unknown Computers

You can use Windows Deployment Services to link client computers to computer account objects in Active Directory Domain Services (AD DS). This is called prestaging a client. Prestaged clients are also called “known computers”. Prestaging enables you to configure account settings to control the installation for each client. For example, you can configure which network boot program and unattend file the client receives, as well as which server the client downloads the network boot program from. For those computers that are not prestaged (unknown computers), you can enable the Auto-Add policy. When this policy is enabled, administrator approval is required before an unknown computer can install an image. For more information, see Prestaging Client Computers (http://go.microsoft.com/fwlink/?LinkID=131987).

 | Step | Reference
Check box | Prestage client computers in AD DS. | Prestage Client Computers
Check box | Configure how to respond to unknown clients. | Configure the Auto-Add Policy and PXE Response Tab
Check box | Configure AD DS settings for clients. | AD DS Tab
Note

See How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265) for a list of procedures related to the Auto-Add policy and prestaging clients.


Checklist: Manage Driver Packages

You can use Windows Deployment Services to add driver packages to the server and then deploy them to clients during a network-based installation. Once you add driver packages to your server, you can define which clients receive the drivers by using driver groups, and you can also add the drivers into boot images.

 | Step | Reference
Check box | Obtain and add driver packages to the server. | Extract and Add Driver Packages
Check box | Create driver groups. | Deploying Driver Packages
Check box | Configure the driver packages on the server. | Deploying Driver Packages
Check box | Modify driver packages. | Driver and Package Attributes
Check box | Add driver packages to a boot image. | Add Driver Packages to a Boot Image


Checklist: Create an Unattended Installation

With Windows Deployment Services, you can configure the entire deployment process to be performed without user interaction. To do this, you need to automate the Windows Deployment Services UI screens and the later phases of Setup, including joining the computer to a domain. You can also automate the Image Capture Wizard by using a WDSCapture.inf file. For more information, see Performing Unattended Installations (http://go.microsoft.com/fwlink/?LinkId=89226).

 | Step | Reference
Check box | Create a Windows Deployment Services client unattend file and set it as the default to be used for each architecture. | Configure an Unattended Installation
Check box | Create an image unattend file and associate it with an image. | Configure an Unattended Installation
Check box | Create an unattend file for the Image Capture Wizard and save it within the image. | Automating the Image Capture Wizard (http://go.microsoft.com/fwlink/?LinkId=131989)


Configuring Windows Deployment Services

After you install Windows Deployment Services, you will need to configure the server. The server configuration depends on which role services that you install.

In this section:

  • Transport Server. You can install only the Transport Server role service. This role service provides a subset of the functionality of Windows Deployment Services and you can install it in environments that do not have Active Directory Domain Services, DHCP, or DNS. You can use Transport Server to network boot computers into Windows Preinstallation Environment (Windows PE), transmit data (including operating system images) using multicasting, or both.

  • Deployment Server. You can install both the Deployment Server and Transport Server role services, which provides the full functionality of Windows Deployment Services. (You cannot install only Deployment Server without Transport Server.)

Additional references

  • Windows Deployment Services


Transport Server

During installation, you can choose to install only the Transport Server role service. This role service provides a subset of the functionality of Windows Deployment Services and you can install it in environments that do not have Active Directory Domain Services, DHCP, or DNS. Transport Server contains only the core networking parts of Windows Deployment Services.

You can use Transport Server to network boot computers into Windows Preinstallation Environment (Windows PE), transmit data (including operating system images) using multicasting, or both. Install Transport Server in advanced scenarios as a part of a custom deployment solution. Although you do not need to have experience with software development to implement this solution, you should have experience with using command-line tools and writing scripts.

For information about how to configure Transport Server to network boot computers, and/or to multicast data, see Using Transport Server (http://go.microsoft.com/fwlink/?LinkId=143905).


Deployment Server

During installation, you can choose to install both Deployment Server and Transport Server role services, which provides the full functionality of Windows Deployment Services. You can then configure and remotely install Windows operating systems. Deployment Server is dependent on the core parts of Transport Server (which is why you cannot install only Deployment Server without Transport Server).

Note

See the Windows Deployment Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=84628) for information about setting up your server.

Installing Windows Deploying Services

You can install Windows Deployment Services by using the Initial Configuration Wizard, Server Manager, or the command line.

  • To install the role by using the Initial Configuration Wizard, click Add roles on the Initial Configuration Tasks startup screen. Click Next and then select Windows Deployment Services.

  • To install the role by using Server Manager, click Add roles, which is located in the Roles Summary pane. Click Next and then select Windows Deployment Services.

  • To install the role by using the command line, run ServerManagerCmd -install WDS.

Configuring Windows Deployment Services

After you install Windows Deployment Services, you will need to configure the server.

  • To configure using the Windows interface

  • To configure using a command line

To configure using the Windows interface

  1. Ensure that you are a member of the Domain Admins group.

  2. Click Start, click Administrative Tools, and then click Windows Deployment Services. If there is not a server listed under the Servers node, right-click the Servers node and click Add Server to add the local computer.

  3. In the left pane of the Windows Deployment Services MMC snap-in, expand the Servers node.

  4. Right-click the server, and then click Configure Server.

  5. Follow the instructions in the wizard.

  6. When the configuration is complete, ensure that the Add images to the server now check box is selected and then click Finish.

  7. Follow the instructions in the wizard to add at least one boot and one install image. For more information, see Add a Boot or Install Image.

  8. If you want to modify any of the settings of the server, right-click the server in the MMC-snap in, and click Properties. For a list of configuration tasks and instructions, see How to Manage Your Server (http://go.microsoft.com/fwlink/?LinkId=143379).

To configure using a command line

  1. Click Start, right-click Command Prompt, and then click Run as administrator.

  2. Type the following command where <path> is the location where you want the RemoteInstall folder to be located. This folder must be an NTFS partition that is large enough to hold all of the images that you will have, and it should not be the system partition.

    WDSUTIL /initialize-server /reminst:<path>

  3. To set the answer policy, run the following command. If you set this value to Known, a computer must be prestaged in Active Directory Domain Services (AD DS) before it will be answered by the Windows Deployment Services server.

    WDSUTIL /Set-Server /AnswerClients:{all|known|none}

  4. If you are installing Windows Deployment Services on a computer with the DHCP Server role installed, run the following command. For more information about why you must configure these options, see DHCP Tab.

    WDSUTIL /Set-Server /UseDHCPPorts:no /DHCPoption60:yes

  5. Perform additional configurations as needed for your environment. For a list of additional configuration tasks and instructions, see How to Manage Your Server (http://go.microsoft.com/fwlink/?LinkId=143379).

  6. Now that you have configured the server, you will need to add images. These images include a boot image (which is the bootable environment that you initially boot the computer into, and the install images (which are the actual images that you deploy). For instructions, see Add a Boot or Install Image.

Additional references

  • Overview of Windows Deployment Services

  • Configuring Windows Deployment Services

  • Managing Windows Deployment Services

  • Resources for Windows Deployment Services


Managing Windows Deployment Services

This section contains information about how to manage client computers, images, and driver packages.

In this section:

  • Managing Client Computers

  • Managing Images

  • Managing Driver Packages


Managing Client Computers

You can use Windows Deployment Services to link client computers to computer account objects in Active Directory Domain Services (AD DS). This is called prestaging a client. Prestaged clients are also called “known computers”. For those computers that are not known, you can configure the Auto-Add policy to require administrative approval before they will be allowed to boot against the server to install an operating system. In addition, you can configure an unattended installation for clients in order to automate the Windows Deployment Services client and the later stages of Windows Setup.

In this section:

  • Prestage Client Computers

  • Configure the Auto-Add Policy

  • Install an Operating System

  • Configure an Unattended Installation


Prestage Client Computers

You can use Windows Deployment Services to link physical computers to computer account objects in Active Directory Domain Services (AD DS). This is called prestaging the client. Prestaged clients are also called known computers. Prestaging the client allows you to configure properties to control the installation for the client. For example, you can configure the network boot program and the unattend file that the client should receive, as well as the server from which the client should download the network boot program. For more information, see http://go.microsoft.com/fwlink/?LinkId=131987. For a list of procedures related to the Auto-Add policy and prestaged clients, see How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265).

You can create a computer account object and associate it with a physical computer using the following methods:

  • Using WDSUTIL. You can prestage client computers before they have attempted a network boot using the command line. For instructions, see the second procedure below. Note that you cannot prestage computers by using the Windows Deployment Services MMC snap-in, but you can set the Configure the Auto-Add Policy and approve or reject pending computers.

  • Using the Active Directory Users and Computers snap-in. You can prestage client computers before they have attempted a network boot using AD DS. For instructions, see the first procedure below.

  • Enabling the Auto-Add policy. If you enable this policy, when you approve the installation for an unknown client, the installation will proceed and a computer account will be created in AD DS for the client. For more information, see Configure the Auto-Add Policy.

  • Using Windows Deployment Services as part of the image installation. By default, all operating system installations using Windows Deployment Services result in a client computer that is joined to a domain. You can disable this functionality using the Client tab of the server’s properties page.

To prestage client computers by using the Windows interface

  1. On the server running Active Directory Users and Computers, open the Active Directory Users and Computers MMC snap-in (click Start, click Run, type dsa.msc, and then click OK).

    Note

    To manage the server remotely, you can install “AD DS Snap-Ins and Command-Line Tools” in Remote Server Administration Tools. To do this, click Add Features in Server Manager, and install the feature from the following location: Remote Server Administration Tools>Remote Administration Tools>AD DS and AD LDS Tools>AD DS Tools>AD DS Snap-Ins and Command-line Tools.

  2. In the console tree, right-click the organizational unit that will contain the new client computer.

  3. Click New, and then click Computer.

  4. Type the client computer name, click Next, and then click This is a managed computer.

  5. In the text box, type the client computer's media access control (MAC) address preceded with twenty zeros or the globally unique identifier (GUID) in the format: {XXXXXXXX-XXXX-XXXX-XXX-XXXXXXXXXXXX}.

  6. Click Next, and click one of the following options to specify which server or servers will support this client computer:

    • Any available remote installation server

    • The following remote installation server

  7. Click Next, and then click Finish.

To prestage client computers by using a command line

  1. Click Start, right-click Command Prompt, and then click Run as administrator.

  2. Type the following, where <devicename> is the name and <GUIDorMACAddress> is the identifier of the new computer. If you use a MAC address with the /ID option, you must precede it with twenty zeros (0).

    WDSUTIL /add-device /device:<devicename> /ID:<GUIDorMACAddress> <options>

    For example: WDSUTIL /Add-Device /Device:Computer1 /ID:{E8A3EFAC-201F-4E69-953F-B2DAA1E8B1B6} /ReferralServer:WDSServer1 /BootProgram:boot\x86\pxeboot.com /WDSClientUnattend:WDSClientUnattend\unattend.xml /User:Domain\MyUser/JoinRights:Full /BootImagePath:boot\x86\images\boot.wim /OU:"OU=MyOU,CN=Test,DC=Domain,DC=com"

Additional references

  • Managing Windows Deployment Services

  • Configure the Auto-Add Policy


Configure the Auto-Add Policy

The Auto-Add policy specifies that administrative approval is required before unknown computers (computers that have not been prestaged in Active Directory Domain Services (AD DS)) are allowed to install an operating system. When you enable this policy, clients that are awaiting approval will be shown in the Pending Devices node of the MMC snap-in. If you approve the pending computer, the computer will continue booting from the network, and a computer account object will be created in AD DS to represent the physical computer. This is helpful because it gives you the ability to prestage computers without needing to know the client computer's GUID or MAC address in advance. If you reject the computer, the network boot will stop, the computer will boot from the next item in the boot order, and a computer account will not be created.

If you do not enable the Auto-Add policy, Windows Deployment Services will not create a computer account for unknown clients when they first PXE boot. However, an account will still be created as part of the installation if the server is configured to join clients to the domain. To configure this setting, right-click the server, and click Properties. On the Client tab, see the Joining a Domain section.

For more information, see Prestaging Client Computers (http://go.microsoft.com/fwlink/?LinkID=131987).

To configure the Auto-Add policy

  1. Right-click the server and click Properties.

  2. On the PXE Response tab, click Respond to all client computers (known and unknown), and then select Require administrator approval for unknown computers.

  3. To modify the statement that client computers are shown when they are in the pending state, run WDSUTIL /Set-Server /AutoAddPolicy /Message:<message>.

  4. Configure the settings for unknown clients. For a list of procedures, see the “Specify Settings for Pending Computers” section at How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265).

  5. When an unknown computer boots to the server, the computer will appear in the Pending Devices node of the MMC snap-in. For a list of the actions you can take at this time, see the “Approve and Reject Pending Computers” section of How to Manage Client Computers (http://go.microsoft.com/fwlink/?LinkID=115265).

Additional references

  • Managing Windows Deployment Services


Install an Operating System

After you have at least one boot image and one install image on the server, you can deploy an install image. To PXE boot a computer to install an image, complete the steps in this section.

To install an operating system

  1. Configure the BIOS of the computer to enable PXE booting, and then set the boot order so that the computer boots from the network first.

  2. Restart the computer and when prompted, press F12 to initiate a network boot.

  3. If you are presented with a boot image selection screen, select the appropriate boot image. This screen will only be available if you have two or more boot images on the Windows Deployment Services server. For more information, see Add a Boot or Install Image.

  4. On the first screen of the Windows Deployment Services client user interface, select the locale and input method, and click Next.

  5. When prompted, provide a user name and password with sufficient credentials to install images from the Windows Deployment Services server.

  6. Continue to follow the instructions provided in the Windows Deployment Services client user interface.

  7. When image installation is complete, the computer will restart and Windows Setup will continue.

Additional references

  • Managing Windows Deployment Services


Configure an Unattended Installation

Windows Deployment Services enables you to automate the user interface screens of the Windows Deployment Services client and the later stages of Windows Setup. You use the following two unattend files to automate either or both of these processes:

  • Windows Deployment Services client unattend file. To automate the Windows Deployment Services client user interface screens (for example, for entering credentials, choosing an install image, and configuring the disk), create an Unattend.xml file and save it to the \WDSClientUnattend folder on the Windows Deployment Services server. For instructions, see Configuring unattended installation for the Windows Deployment Services client.

  • Image unattend file. To automate the remaining phases of Setup (for example, offline servicing, Sysprep specialize, and mini-setup), you create an image unattend file and associate it with an image. In most cases, you create another Unattend.xml file. For Windows images prior to Windows Vista, you must use your existing Sysprep.inf files and save the file to the $OEM$ structure of the image. For instructions, see Configuring unattended for Windows Setup.

We recommend that you use Windows System Image Manager (included as part of the Windows AIK) to author the Unattend.xml files. For more information, see Performing Unattended Installations (http://go.microsoft.com/fwlink/?LinkId=89226).

Configuring unattended installation for the Windows Deployment Services client

You can use the following procedures to associate a client unattend file for an entire architecture or for a specific prestaged computer. Assigning the file for an entire architecture allows you to have differing settings for x86-based and x64-based clients. Assignment at the client level overrides the architecture setting.

To associate a client unattend file by architecture using the Windows interface

  1. Create an Unattend.xml. (See Sample Unattend Files at http://go.microsoft.com/fwlink/?LinkId=122642.)

  2. Copy the client unattend file to RemoteInstall\WDSClientUnattend.

  3. Open the Windows Deployment Services MMC snap-in and right-click the server that contains the image that you want to associate the unattend file with, and then click Properties.

  4. On the Client tab, select Enable unattended installation, browse to the appropriate unattend file, and then click Open.

  5. Click OK to close the Properties page.

To associate a client unattend file by architecture using a command line

  1. Create an Unattend.xml. (See Sample Unattend Files at http://go.microsoft.com/fwlink/?LinkId=122642.)

  2. Copy the client unattend file to RemoteInstall\WDSClientUnattend.

  3. Click Start, right-click Command Prompt, and then click Run as administrator.

  4. Type the following (the file path must be relative from the RemoteInstall folder):

    WDSUTIL /Set-Server /WDSUnattend /Policy:enabled /File:wdsclientunattend\Unattend.xml /Architecture:{x86|ia64|x64}
    Note

    Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt.

To associate a client unattend file per computer using a command line

  1. Create an Unattend.xml. (See Sample Unattend Files at http://go.microsoft.com/fwlink/?LinkId=122642.)

  2. Copy the unattend file to RemoteInstall\WDSClientUnattend.

  3. Click Start, right-click Command Prompt, and then click Run as administrator.

  4. Type the following (the file path must be relative from the RemoteInstall folder):

    WDSUTIL /Set-Device /Device:<computername> /ID:<GUID or MAC address> /WDSClientUnattend:wdsclientunattend\Unattend.xml

Configuring unattended installation for Windows Setup

You automate the remaining phases of Setup with an image unattend file—either Unattend.xml or Sysprep.inf, depending on the operating system of the image.

  • Unattend.xml. For most images (Windows Vista with SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2) author an Unattend.xml by using Windows SIM, save it to a known location, and then associate the file with an image using the following procedures.

  • Sysprep.inf. For Windows images prior to Windows Vista, author Sysprep.inf by using Setup Manager and then save these files to the $OEM$ structure of the image (for example, D:\RemoteInstall\Images\Windows XP\winxpsp2\$OEM$\$1\sysprep\sysprep.inf). Now when you deploy the image, Setup will automatically locate and use the Sysprep.inf file.

To associate an Unattend.xml file to an image by using the Windows interface

  1. Create an Unattend.xml file. (See Sample Unattend Files at http://go.microsoft.com/fwlink/?LinkId=122642.)

  2. From the Windows Deployment Services MMC snap-in, click to expand the image group that contains the image.

  3. Right-click the image that you want to associate the unattend file to, and click Properties.

  4. On the General tab, click Allow image to install in unattend mode.

  5. Click Select File, browse to select the unattend file, and then click OK twice.

To associate an Unattend.xml file to an image using a command line

  1. Create an Unattend.xml file and save it to a known location. (See Sample Unattend Files at http://go.microsoft.com/fwlink/?LinkId=122642.)

  2. Click Start, right-click Command Prompt, and then click Run as administrator.

  3. Type the following, where <imagename> is the name of the image to associate the unattend file with, <imagegroupname> is the name of the image group that contains the image, and <unattendfile> is the path and file name of the unattend file:

    WDSUTIL /Set-Image /Image:<imagename> /ImageType:install /ImageGroup:<imagegroupname> /UnattendFile:<unattendfile>

Additional references

  • For Help for WDSUTIL, type WDSUTIL /? at a command prompt or download the WDSUTILCommands.chm at http://go.microsoft.com/fwlink/?LinkId=89381.

  • Managing Images


Managing Images

The image types used in Windows Deployment Services are install images and boot images.

  • Install image. The operating system image that you deploy to the client computer. You can use the default install image (Install.wim) located in the \Sources directory on the Windows 7 or Windows Server 2008 R2 DVDs. You can also modify the default images or create your own images.

  • Boot image. The Windows Preinstallation Environment (Windows PE) image that you boot a client into before you install the install image. In most cases, you should use the default boot image (Boot.wim) that is included in the \Sources directory of the Windows Server 2008 R2 installation DVD. Except in advanced scenarios, you will not need to modify this file unless you want to add drivers to the image (see Add Driver Packages to a Boot Image). To install an operating system, you first boot the computer into the boot image, and then you select the install image to install.

    You can also create two additional types of boot images:

    • Capture image. A type of boot image that you boot a client computer into to capture the operating system as a .wim file. You must first create a capture image in order to create a custom install image.

    • Discover image. A type of boot image that you can use to install an operating system on a computer that is not Pre-Boot Execution Environment (PXE)–enabled. When you boot a computer into a discover image, the Windows Deployment Services client will locate a valid Windows Deployment Services server, and then you can choose the install image you want to install.

    For more information, see Creating Images (http://go.microsoft.com/fwlink/?LinkId=115311).

In this section:

  • Add a Boot or Install Image

  • Create a Custom Install Image

  • Create a Discover Image

  • Modify a Boot or Install Image

  • Enable Multicast Transmission of an Image

  • Convert RIPREP Images

  • Deploy Virtual Hard Disk Images


Add a Boot or Install Image

You must add at least one boot image and one install image to the server before you can boot a client computer and install an operating system.

  • Adding an install image

  • Adding a boot image

Adding an install image

Install images are the operating system images that you deploy to the client computers. You can use the default install image (Install.wim) located in the \Sources directory on the Windows 7 or Windows Server 2008 R2 DVDs. You can also create and modify images using the tools in the Windows Automated Installation Kit (Windows AIK) at http://go.microsoft.com/fwlink/?LinkId=139642.

To add an install image

  1. Expand the server that you want to add the install image to.

  2. Right-click the Install Images node, and then click Add Install Image.

  3. Specify a name for the image group, and then click Next.

  4. Browse to the install image and click Open. You can use the default install image (Install.wim) located in the \Sources directory on the Windows 7 or Windows Server 2008 R2 DVD.

  5. To add a subset of the images included in the Install.wim, clear the check boxes for the images that you do not want to add to the server. You should only add the images for which you have licenses.

  6. Follow the instructions in the wizard to add the images.

Note

You can also perform this procedure from the command line by running the following: WDSUTIL /Add-Image /ImageFile:"C:\MyFolder\Install.wim" /ImageType:Install

Adding a boot image

Boot images are the Windows Preinstallation Environment (Windows PE) images that you boot a client into before you install an install image. In most cases, you should use the default boot image (Boot.wim) that is included in the \Sources directory of the Windows Server 2008 R2 installation media. Except in advanced scenarios, you will not need to modify this file except to add driver packages (see Add Driver Packages to a Boot Image). To install an operating system, you first boot the computer into the boot image, and then you select the install image to install.

A boot menu will appear when you PXE boot a computer, and more than one supported boot image exists on the Windows Deployment Services server. You can accomplish many tasks by using Windows PE boot images—for example, you could have boot images that:

  • Launch Setup to install Windows.

  • Reformat the hard disks to support BitLocker Drive Encryption (using unattend) and then install Windows.

  • Contain the Windows Recovery Environment that you want to use when a computer fails to start.

  • Contain the Windows Deployment Services Image Capture Wizard, which creates an install image from the client computer's operating system.

  • Include a Windows PE image for administrators who want to perform other operations from within Windows PE.

In addition, x64-based computers can run x86-based or x64-based Windows PE boot images. Therefore, for each of these tasks, you could have two boot images—one for x86 and one for x64. The boot menu on x86-based computers will only display the x86 boot images because x86-based computers cannot run x64 boot images.

To add the default boot image included in the product installation DVD

  1. Expand the server that you want to add the boot image to.

  2. Right-click the Boot Images node, and then click Add Boot Image.

  3. Browse to choose the default boot image (Boot.wim) located in the \Sources directory on the Windows Server 2008 R2 DVD.

  4. Click Open, and then click Next.

  5. Follow the instructions in the wizard to add the image.
Note

You can also perform this procedure from the command line by running the following: WDSUTIL /Add-Image /ImageFile:"C:\MyFolder\Boot.wim" /ImageType:Boot

To make additional changes to the boot menu, use Bcdedit.exe to edit the Default.bcd file located at RemoteInstall\boot\<architecture>. For more information, see How to Modify the BCD Store Using Bcdedit (http://go.microsoft.com/fwlink/?LinkId=115267).

Additional considerations

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate user rights.

Additional references

  • Managing Images


Create a Custom Install Image

You can create custom install images using Windows Deployment Services. To do this, use the instructions in this section to create a capture image, prepare a reference computer using Sysprep, and then capture the operating system using the Image Capture Wizard. Note that install images that are older than Windows Vista are hardware abstraction layer (HAL)–specific, so you cannot deploy an image with one type of HAL to a computer with a different type of HAL. However, Windows Vista images are not HAL-specific, so you only need one image for each architecture. For more information, see Creating Images (http://go.microsoft.com/fwlink/?LinkId=115311).

  • Creating a capture image

  • Creating a custom install image

Creating a capture image

To create an install image, you must first create a capture image. Capture images are boot images that you boot a client computer into to capture the operating system into a .wim file. You can also create media (a CD, DVD, USB drive, or other type of media) that contain a capture image, and then boot a computer from the media. These images provide an alternative to the command-line utility, ImageX.exe. Except in advanced scenarios, you should create a capture image by using the Boot.wim file from the Windows Server 2008 R2 DVD. You can also use the WinPE.wim file from the Windows Automated Installation Kit (Windows AIK) to create a capture image, which is slightly smaller than the Boot.wim file.

To create a capture image

  1. In the Windows Deployment Services MMC snap-in, expand the Boot Images node.

  2. Right-click the image to use it as a capture image. In most cases, you can just use the Boot.wim file from the DVD.

  3. Click Create Capture Image.

  4. Type a name, a description, and the location where you want to save a local copy of the file. You must specify a location in case there is a problem with the network when you deploy the capture image.

  5. Continue to follow the instructions in the wizard and when it is complete, click Finish.

  6. Right-click the Boot Image node.

  7. Click Add Boot Image.

  8. Browse and select the new capture image, and then click Next.

  9. Follow the instructions in the wizard.

  10. After you have created the capture image, follow the instructions in the next section to boot a computer into the capture image and capture the operating system.

Creating a custom install image

Now that you have a capture image, you need to prepare a reference computer and then create the install image. The reference computer can be a computer with a standard Windows installation or a Windows installation that has been configured for your environment. First, you boot a computer that has been prepared with Sysprep into the capture image. Then a wizard creates an install image of the reference computer and saves it as a .wim file. After that, you can deploy the .wim file to a computer. Note that in the Image Capture Wizard, you will only see drives that contain operating systems prepared with Sysprep. If you do not run Sysprep on the computer before you boot into the image, you will not see any drives to capture.

To create a custom install image

  1. Create a reference computer (install the operating system, applications, and make any other changes that you want).

  2. Ensure that you have the correct version of Sysprep.exe on the computer.

  3. At a command prompt on the reference computer, change folders to \Windows\System32\Sysprep or the folder that contains Sysprep.exe and Setupcl.exe.

  4. Run sysprep /oobe /generalize /reboot. If you prefer, you can also use the Sysprep graphical user interface by double-clicking Sysprep.exe.

    Note

    On computers running Windows XP or Windows Server 2003, run sysprep -mini –reseal -reboot.

  5. When the computer restarts, perform a network boot on the computer by pressing F12.

  6. On the boot menu, select the capture image that you created in the preceding procedure, and then click Next.

  7. Follow the instructions in the Image Capture Wizard to name, save, and upload the image to the Windows Deployment Services server.

After you add the image to the server, you can PXE boot a client computer to install this image. For instructions, see Install an Operating System.

Additional references

  • Managing Images


Create a Discover Image

If you have a computer that is not PXE-enabled, you can create a discover image and use it to install an operating system on that computer. When you create a discover image and save it to media (a CD, DVD, USB flash drive, or other type of media), you can then boot a computer to the media. When you boot a computer into the discover image, it locates a Windows Deployment Services server, and the server deploys the install image to the computer. You can configure discover images to target a specific Windows Deployment Services server. This means that if you have multiple servers in your environment, you can create a discover image for each one, and then name them based on the name of the server. After you create the discover image, create media that contains the image. For more information, see Creating Images at http://go.microsoft.com/fwlink/?LinkId=115311.

To create a discover image

  1. In the Windows Deployment Services MMC snap-in, click the Boot images node.

  2. From the right pane, right-click the image you want to use as a discover image.

  3. Click Create Discover Image.

  4. On the first screen of the wizard, under Location and file name, type C:\boot.wim.

  5. Click Next, and when the operation is complete, click Finish.

Note

You can also perform this procedure at a command prompt by running WDSUTIL /New-DiscoverImage /Image:<name> /Architecture:{x86|x64|ia64} /DestinationImage /FilePath:<path and name to new file>. To specify which server the discover image connects to, append /WDSServer:<server name or IP>.

To create media that contains the discover image

  1. Download and install the Windows Automated Installation Kit (Windows AIK) (http://go.microsoft.com/fwlink/?LinkId=139642).

  2. Click Start, click All Programs, click Microsoft Windows AIK, and then click Deployment Tools Command Prompt.

  3. To create a Windows Preinstallation Environment (Windows PE) build environment, type:

    CopyPE <architecture> C:\Winpe

  4. To copy the discover image that you created to the environment, type:

    Copy /y c:\boot.wim c:\Winpe\ISO\Sources

  5. To change back to the PETools folder, type:

    Cd C:\Program Files\Windows AIK\Tools\PETools

  6. To create the bootable .iso image, type:

    Oscdimg -n -bc:\winpe\ISO\boot\etfsboot.com c:\winpe\ISO c:\<imagename>.iso

  7. Use a utility that can create a CD or DVD to transfer the .iso image to the media.

    Note

    Using the Windows copy command to copy the image to media will not create a bootable disk.

  8. Boot the client computer to the media. You may need to change the boot order in the client BIOS to do this. When the client boots to the media, your experience will be the same as if you had booted to the network.

Additional references

  • Managing Images


Modify a Boot or Install Image

You can modify images by using the tools in the Windows Automated Installation Kit (Windows AIK). The processes are similar for a boot or install image—however the tool sets and syntax vary between image types. If you only need to add drivers to an image, you can do that using Windows Deployment Services. To add drivers to install images, you can add drivers to your server and then define which client computers should install them. For more information, see Managing Driver Packages (http://go.microsoft.com/fwlink/?LinkID=143313).

Modifying boot images

You can modify your boot images using the ImageX and Deployment Imaging Servicing and Management (DISM) tools in the Windows AIK. For more information, see (http://go.microsoft.com/fwlink/?LinkId=143437). You can also use Windows Deployment Services to add driver packages to boot images. For instructions, see Add Driver Packages to a Boot Image.

You can also make additional changes to the boot menu, using the Bcdedit.exe tool to edit the Default.bcd file located at RemoteInstall\boot\<architecture>. For more information, see How to Modify the BCD Store Using Bcdedit (http://go.microsoft.com/fwlink/?LinkId=115267).

To modify a boot image

  1. Disable the image that you want to modify. If you are using the Windows Deployment Services snap-in, right-click the image and select Disable. This will allow existing installations to continue, but new clients will not be able to install the image.

  2. Export the image.

  3. Modify the image using the tools included in the Windows AIK.

  4. Add the image back to the Windows Deployment Services server. There are two ways to accomplish this:

    • Replace the existing image with the newly serviced version (assuming that all installations using the existing image have completed). (Recommended) To do this, right-click the image and click Replace Image.

    • Add the image as a new image and remove the old image at a later time.

Modifying install images

You can modify install images using the tools in the Windows AIK. For more information, see the following in the Waik.chm (http://go.microsoft.com/fwlink/?LinkId=139641):

  • Phase 5: Managing and Servicing Your Windows Image

  • Deployment Image Servicing and Management Technical Reference

  • Add and Remove Drivers Offline

  • Add and Remove Language Packs Offline

To modify an install image

  1. Disable the image that you want to modify. In the Windows Deployment Services MMC snap-in, right-click the image and select Disable. This will allow existing installations to continue, but new clients will not be able to enumerate the image.

  2. Export the image.

  3. Modify the image by using the tools included in the Windows AIK.

  4. Add the image to the server. There are two ways to do this:

    • Replace the existing image with the updated version (as long as all installations using the existing image have completed) (Recommended). To do this, right-click the image and click Replace Image.

    • Add the image as a new image. Later, you can remove the old image (which will not be enumerated because it was disabled).

Additional references

  • Managing Images


Enable Multicast Transmission of an Image

This topic contains information about how to implement multicast transmissions. If you installed only the Transport Server role service, see the Transport Server topic for information related to multicasting with Transport Server. When you create a multicast transmission, content is transferred over the network only if clients request the data. If no clients are connected (that is, the transmission is idle), then data is not sent over the network.

In this topic

  • Creating multicast transmission for an install image

  • Creating multicast transmission for a boot image

Creating multicast transmission for an install image

  • Creating a transmission

  • Configuring install image transmissions

  • Configuring clients in a transmission

Creating a transmission

To perform this task, use the following procedure.

To enable multicasting of an install image

  1. Before you create a transmission, you should set the transfer policy for the server. To do this, right-click the server, click Properties, click the Multicast tab, and select an option under Transfer Settings. These settings allow you to enable the following:

    • Multiple stream transfer. The first option under Transfer Settings uses a single stream for all multicast clients, regardless of client speed. The next two options allow you to separate slower clients into their own multicast stream, which enables faster clients to complete their deployment more quickly instead of being held back by slower clients. These settings are only available for clients that boot into a boot image from Windows 7 or Windows Server 2008 R2.

    • Automatic disconnect. The last option under Transfer Settings allows you to automatically stop clients that fall under a specified speed. The clients that are disconnected will continue to transfer the image using unicasting (Server Message Block). These settings are only available for clients that boot into a boot image from Windows Vista with Service Pack 1, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

  2. To create a multicast transmission for an install image, right-click the Multicast Transmissions node (or an install image) and click Create Multicast Transmission. The wizard will walk you through selecting the image and configuring the transmission. There are two types of multicast transmissions:

    • Auto-Cast. This option indicates that as soon as an applicable client requests the image, a multicast transmission of the selected image begins. Then, as other clients request the same image, they too are joined to the transmission that has already started.

    • Scheduled-Cast. This option sets the start criteria for the transmission based on the number of clients that are requesting an image and/or a specific day and time. In addition to these criteria, you can start a transmission manually at any time by right-clicking the transmission and clicking Start. If you do not select start criteria for the transmission, then you must manually start it.

Configuring install image transmissions

After a transmission is created, you can do the following:

  • Start the transmission. If a Scheduled-Cast transmission has at least one client and has not started yet, then you can right-click the transmission and click Start.

  • Delete the transmission. If you right-click the transmission and click Delete, the multicast transmission stops and each client installation reverts to using unicast. That is, the client installations are not deleted or stopped, but they do not use the multicast transmission to complete the installation.

  • Deactivate the transmission. If you right-click the transmission and click Deactivate, each client that is currently installing continues, but no new clients are joined to the transmission. After the last current client installation is complete, the transmission is deleted. If there are no clients when you click this option, then the transmission is deleted immediately.

  • View properties. To view the properties of a transmission, right-click it, and click Properties. Note that you cannot edit the properties of a transmission after it is created. To make a change after you have created a transmission, you need to delete and recreate it.

  • Refresh the transmissions and data. To refresh the data, right-click a transmission and click Refresh, or press F5.

Configuring clients in a transmission

After you have created the transmission, client computers join the transmission by selecting the image in the Windows Deployment Services client. Client computers can also join a transmission using Wdsmcast.exe—a command-line tool included in the Windows Automated Installation Kit (Windows AIK). When there are clients in a transmission, you can:

  • View clients and see progress. To view information about clients that are connected to a transmission, expand the Multicast Transmissions node, and click the transmission. The clients are shown in the right pane.

  • Stop a client installation. To stop the installation completely, right-click a client and click Disconnect. You should use this option with caution because the installation will fail and the computer could be left in an unusable state.

  • Disconnect a client from a multicast transmission. To discontinue the transmission for a particular client but continue to transfer the image through unicast, right-click the client, and then click Bypass multicast.

Creating multicast transmission for a boot image

You can enable multicast transmissions for boot images for computers that use Extensible Firmware Interface (EFI) using WDSUTIL. The following are the commands that you can use to create, start, and remove a transmission. Just like with install images, you can create Automatic-Cast or Scheduled-Cast transmissions. For information about the syntax of these commands, see Wdsutil (http://go.microsoft.com/fwlink/?LinkId=143438).

  • Create a multicast transmission.

    • To create an Automatic-Cast transmission of a boot image, run:

      WDSUTIL /New-MulticastTransmission /FriendlyName:"WDS Boot Transmission" /Image:"X64 Boot Image" /ImageType:Boot /Architecture:x64 /TransmissionType:AutoCast

    • To create a Scheduled-Cast transmission of a boot image, run:

      WDSUTIL /New-MulticastTransmission /FriendlyName:"Boot SchedCast Transmission" /Server:MyWDSServer /Image:"X64 Boot Image" /ImageType:Boot /Architecture:x64 /TransmissionType:ScheduledCast /Time:"2006/11/20:17:00" /Clients:10

  • Start a ScheduledCast transmission. To start a previously created ScheduledCast transmission, run:

    WDSUTIL /Start-MulticastTransmission /Server:MyWDSServer /Image:"X64 Boot Image" /ImageType:Boot /Architecture:x64 /Filename:boot.wim

  • Remove a transmission. To remove a transmission but allow all current transfers to complete, run:

    WDSUTIL /Remove-MulticastTransmission /Image:"X64 Boot Image” /ImageType:Boot /Architecture:x64

Additional references

  • Managing Images


Convert RIPREP Images

If you upgraded your server from Windows Server 2003, your Remote Installation Preparation (RIPREP) images are stored under the Legacy Images node in the Windows Deployment Services MMC snap-in. Remote Installation Setup (RISETUP) images are not supported in Windows Deployment Services. Before you can deploy your RIPREP images to client computers, you must first convert them to Windows image (.wim) format.

To convert a RIPREP image to .wim format by using the Windows interface

  1. Save a backup copy of the RIPREP images to a temporary location (in case the process fails or if you want to revert to the original image).

  2. Click to expand Legacy Images.

  3. Right-click the image to be converted and click Convert Image.

  4. Follow the instructions in the wizard.

  5. When the image conversion is complete, add the image to the appropriate image group.
To convert an image to .wim format by using a command line

  1. Save a backup copy of the RIPREP images to a temporary location (in case the process fails or if you want to revert to the original image).

  2. To convert the image, type the following:

    WDSUTIL /convert-riprepimage /filepath:<path to RIPREP image .sif file> /destinationimage /filepath:<path and name of .wim image>

    In addition, you can use the following with this command:

    • To give the new .wim image a name in the metadata, use /Name:<name>.

    • To give the new .wim image a description in the metadata, use /Description:<description>.

    • To convert the original RIPREP image, rather than a copy, use /InPlace.

    • To determine behavior when the image file specified in /DestinationImage already exists, use /Overwrite:{Yes|No|Append}. Yes will overwrite the .wim file, No will cause an error, and Append will append the new image to the existing .wim file.

  3. To add the file to the server, type the following where <filepath> is the full path to the new .wim file:

    WDSUTIL /add-image /imagefile:<filepath> /imagetype:install

Additional references

  • For more information about Windows Deployment Services coexisting with Remote Installation Services, see Managing a Complex Environment (http://go.microsoft.com/fwlink/?LinkId=89227).

  • For more information about upgrading your server from Remote Installation Services, see the Windows Deployment Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=84628).

  • Managing Images


Deploy Virtual Hard Disk Images

You can deploy virtual hard disk (.vhd) images of Windows Server 2008 R2 to a physical (not virtual) computer using Windows Deployment Services. In general, you deploy .vhd images in the same way that you deploy .wim images. However, using WDSUTIL at the command line is the only supported method of adding and configuring the images. In addition, the deployment must be part of an unattended installation.

To deploy .vhd images, follow the steps at http://go.microsoft.com/fwlink/?LinkId=146973. This guide will walk you through configuring your installation. First, you create an image group and add images to it. Then, you create two unattend files and configure the server. After that, you will be ready to deploy a .vhd image. Optionally, you can also configure the images to be deployed using multicasting.

Prerequisites for deploying virtual hard disk images

To deploy .vhd images, you need the following:

  • A configured Windows Deployment Services server. For information about installing and configuring your server, see the Windows Deployment Services step-by-step guide (http://go.microsoft.com/fwlink/?LinkId=84628).

  • Familiarity with WDSUTIL. The only way to import and configure these images is to use the WDSUTIL command-line tool. For information about the commands in this topic, run WDSUTIL /?. You can also download the WDSUTIL command-line reference at http://go.microsoft.com/fwlink/?LinkId=89381.

  • A supported .vhd image. The only supported operating systems are Windows Server 2008 R2, Windows 7 Enterprise, and Windows 7 Ultimate. Fixed, dynamic, and differencing .vhd images are supported. However, note that a supported image cannot contain the following:

    • More than one operating system.

    • More than one partition.

    • Applications or data (instead of an operating system).

    • A 64-bit operating system that is partitioned with a GUID partition table (GPT).

Additional information

For more information about .vhd images, see the following:

  • Frequently Asked Questions: Virtual Hard Disks in Windows 7 (http://go.microsoft.com/fwlink/?LinkId=147081)

  • What's New in Virtual Hard Disks (http://go.microsoft.com/fwlink/?LinkId=147082)

  • Deploying Virtual Hard Disk Images (http://go.microsoft.com/fwlink/?LinkId=146973)


Managing Driver Packages

You can use Windows Deployment Services to add driver packages to the server and configure them to be deployed to client computers along with the install image. In addition, you can add driver packages (such as network adapter drivers, mass storage drivers, and bus drivers) to your Windows 7 and Windows Server 2008 R2 boot images. This means that you do not have to export the image, use the tools in the Windows Automated Installation Kit to add driver packages manually, and then add the updated boot image. For step-by-step instructions, see Managing Driver Packages (http://go.microsoft.com/fwlink/?LinkId=143313).

In this section:

  • Extract and Add Driver Packages

  • Deploying Driver Packages

  • Add Driver Packages to a Boot Image

  • Troubleshoot Failed Packages


Extract and Add Driver Packages

In order to add driver packages to your server, you must first obtain them from the manufacturer and ensure that they are extracted (the packages cannot be in .exe or .msi format). This is a requirement because Windows Deployment Services needs the .inf file that describes the package. For a list of driver Web sites for your manufacturer's hardware, see Update Management Drivers Directory (http://go.microsoft.com/fwlink/?LinkId=143440).

In this topic

  • Locating the .inf file

  • Extracting driver packages

  • Adding driver packages to the server

Locating the .inf file

When adding the packages, you can point to a folder that contains the extracted driver packages, or to the .inf file that describes the package. The .inf file includes a list of the files that make up the package (and their locations), and is included with the driver installation program. Generally, the .inf file is located on the driver installation media in the same folder as the Setup program, or in a subfolder.

Extracting driver packages

If your packages are in .exe or .msi format, you must extract them in order to add them to your server.

Non-Microsoft driver packages

For non-Microsoft packages you should contact the manufacturer of the driver package for information about how to extract them because each manufacturer designs their drivers in different formats. However, the following are some general ways to extract driver packages.

Important

The non-Microsoft products that this document discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

  • Use a file compression program to extract the files. If the driver files are packaged in a single executable file, you may be able to use a file compression tool such as WinZip or WinRAR to extract the contents of the driver package to a folder.

  • Use the Windows Compressed Folders feature to extract the files. If you do not have the WinZip program or the WinRAR program, you may be able to extract the files by using the Windows Compressed Folders feature. To do this, change the file name extension from .exe to .zip. Then, use Windows Explorer to copy the files from the compressed folder.

  • Extract the contents from the .cab file. If there is no .inf file in the driver package, but there are one or more .cab files, you may be able to extract the contents of the .cab files. However, this method is usually unsuccessful. Typically, these kinds of driver packages are created by using the InstallShield program. The InstallShield program uses a special .cab format that is not designed to be accessed by tools such as WinZip or WinRAR.

  • Locate the files in the temporary folder. Some driver package installers (for example, for video cards) use an .exe installer that will prompt you for a location where the files should be temporarily extracted. In these cases, you can specify a location, and view the folder while the installer is running. Even if your computer does not have compatible hardware and the installer stops, you can copy the files from the temporary folder.

Microsoft driver packages

If you obtained your package from Windows Update, use the following procedure to extract the package.

To extract a driver package from Windows Update

  1. Download driver packages from the Microsoft Update Catalog (http://go.microsoft.com/fwlink/?LinkID=66676).

  2. Extract the contents of each .cab file to a directory on your computer using one of the following:

    • Expand.exe. For more information about this command-line tool, see http://go.microsoft.com/fwlink/?LinkId=143439.

    • Windows Explorer. To do this, right-click the package and click Open. Then copy the files to another folder.

  3. Add the driver packages to your Windows Deployment Services server. For instructions about managing and deploying your packages, see Deploying Driver Packages.

Adding driver packages to the server

After you have obtained and extracted your driver packages, you must add them to the server. To do this, right-click the Drivers node, click Add Driver Package, and follow the instructions in the wizard. For step-by-step instructions about how to add and deploy driver packages, see Deploying Driver Packages.

Additional references

  • Managing Driver Packages


Deploying Driver Packages

You can use Windows Deployment Services to add driver packages to the server and configure them to be deployed to client computers along with the install image. Note that this functionality is only available when you are installing images of the following operating systems: Windows Vista with SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This section walks you through configuring this functionality, but you must have a configured server before you begin. For instructions on how to configure your server, see the Windows Deployment Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=84628).

  • Terminology used in this section

  • Choosing a scenario

  • Prerequisites

Terminology used in this section

Term | Definition
Driver group | A driver group is a collection of driver packages. You can add filters to a driver group to make the packages in the group available to a select group of client computers. Alternatively, if there are no filters on a driver group, then the packages will be available to all clients that have matching hardware. You can define whether clients that have access to the driver group install either 1) all the packages in the group, or 2) only those packages that match the hardware that is connected to or installed on the client (that is, Plug and Play hardware).
Filters | Filters enable you to map the packages in a driver group to specific client computers. The filters define which clients have access to the packages. There are two types of filters: filters based on the hardware of the client (for example, manufacturer and BIOS vendor) and filters based on the attributes of the install image that is selected on the client (for example, the version or edition of the image). For a list of the filters, see Driver Group Filters.
Plug and Play hardware | Plug and Play functionality provides automatic configuration of hardware and devices for Windows operating systems.

Choosing a scenario

You can configure the driver packages to be deployed to clients in three ways. The following table describes each of these methods and describes when you should use each.

Scenario Description When To Use This Scenario

Scenario 1: Deploy Driver Packages Based on the Plug and Play Hardware of the Client

In this scenario, you make all packages available to all clients (that is, you do not add filters to your driver groups), and you configure the groups so that only those packages that match the hardware on the computer will be installed.

This is the simplest scenario to configure, and most companies should try this scenario first. However, if you encounter problems because incompatible packages are installed simultaneously on a computer (for example, if you have computers that cannot boot, or hardware that does not work correctly), then you will need to add filters to your driver groups as defined in Scenario 2.

Scenario 2: Deploy Driver Packages Using Filters to Define Which Clients Have Access to Each Driver Group

In this scenario, you organize your packages into driver groups, and then map each group to computers using filters. The filters define which computers have access to the driver group based on the hardware of the computer and/or the attributes of the selected install image. You can still configure the packages to be installed based on Plug and Play hardware, but you can use the filters to further define which clients will have access to the packages.

You should consider using this scenario if:

  • Scenario 1 is resulting in hardware that does not work correctly on a computer.

  • You have a complex environment including computers with various hardware and software configurations.

  • You need to install specific driver packages on certain computers (for example, computers with different languages or versions of an install image).

Scenario 3: Deploy All Driver Packages in a Driver Group to Clients

In this scenario, you deploy all of the driver packages in a driver group to a client computer (not just those that match the Plug and Play hardware on the client). After the installation, when you connect the hardware to the client, the device driver will be installed automatically.

Use this option if you have hardware that is disconnected from the computer (for example, a printer) and you want to force all of the packages in a driver group to be installed on the client. Typically, you should use this scenario in combination with either Scenario 1 or 2.

Prerequisites

The following are prerequisites for all three of the scenarios:

  • A Windows Deployment Services server configured with the following:

    • The boot image from either Windows 7 or Windows Server 2008 R2 (from \Sources\Boot.wim on the DVD).

    • Install images for Windows Vista SP1, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

  • Driver packages for the hardware that you want to deploy. Note that these packages must be extracted (that is, the package cannot be a .msi or .exe file).


Scenario 1: Deploy Driver Packages Based on the Plug and Play Hardware of the Client

In this scenario, you make all packages available to all clients (that is, you do not add filters to your driver groups) and you configure the groups so that only those packages that match the hardware on the computer will be installed.

Important

You should thoroughly test this scenario before implementing it across your organization.

Known issues

  • Depending on the driver packages on the server and the hardware of the client, this scenario could result in a computer that will not boot. If this happens, you will need to figure out which driver packages are causing the problem and either remove them from the server, or restrict them using filters as outlined in Scenario 2: Deploy Driver Packages Using Filters to Define Which Clients Have Access to Each Driver Group.

To add packages and configure the server

  1. Open the Windows Deployment Services MMC snap-in. (Click Start, click Administrative Tools, and click Windows Deployment Services).

  2. Expand the Servers node and the node for your Windows Deployment Services server.

  3. Right-click the Drivers node and click Add Driver Package.

  4. Follow the instructions in the wizard to add the driver packages. When asked which driver group to add the packages to, click Select an existing driver group, and ensure that DriverGroup1 is selected. This driver group (by default) is configured as follows: 1) it has no filters so all clients will have access to the packages in this group and 2) only packages that match the client’s hardware will be installed. To view these settings, right-click DriverGroup1, and click Properties.

  5. On the last page of the wizard, do not select the check box to modify the filters for the group, and click Finish.

  6. Repeat steps 3-5 until you have added all of your driver packages to DriverGroup1.

    Note

    If you would prefer to organize your packages into different driver groups, you can create driver groups when adding packages. However, you should not add any filters to them for this scenario.

    The server is now configured, so all computers that install a supported image (that is, Windows Vista with SP1, Windows Server 2008, Windows 7, or Windows Server 2008 R2) will have access to this driver group. However, computers will only install those packages that match the Plug and Play hardware. You can now install an image as described in the next procedure.
To install the driver packages and an install image

  1. Ensure that all hardware (for which you want packages to be installed) is connected to client computers.

  2. Boot a client computer and install an image.

  3. When the installation is complete, open Device Manager on the client computer from the Control Panel and verify that the device drivers for all connected hardware were installed.

Additional references

  • Deploying Driver Packages

  • Driver Group Filters

  • Driver and Package Attributes


Scenario 2: Deploy Driver Packages Using Filters to Define Which Clients Have Access to Each Driver Group

Scenario 2: Deploy driver packages using filters to define which clients have access to each driver group

This scenario is not as simple as Scenario 1 because it will require you to test your configuration until the filters are configured appropriately for your environment. You may need to create many driver groups with different filter combinations before you find a configuration that works for you. In general, the more complex your environment is, the more complex your configuration will need to be.

Known issues

  • The filter value must exactly match the client hardware or the install image specifications. The two available operators for most filters are Equal to or Not equal to. Therefore, if the value you specify is one character off (for example, if you omit a period) the filters will not filter the clients as intended. For this reason, we recommend that you create multiple filters to account for all cases. For example, create filters for Fabrikam, Inc. and Fabrikam and so on.

  • When searching through the packages using the MMC snap-in to perform a task (for example, to delete a package), the dialog may be briefly unresponsive if you have hundreds of packages on your server. In these cases, note that you should continue to wait because the server is working on your request. For this reason we recommend that you add no more than 2000 driver packages to a group at time (although there is not an enforced limit).

Steps for deploying driver packages using filters

The first step in this scenario is to create driver groups that have filters. The filters define which computers should have access to the driver packages in that group. You can configure packages to be installed based on the hardware of the client (for example, the manufacturer or BIOS vendor) and the attributes of the Windows image that is selected during the installation (for example, the version or edition). For example, you could specify that the only client computers that should have access to a group are those that 1) are manufactured by Fabrikam, Inc. and 2) select a Windows 7 image during the installation. Once you have your driver groups configured, you will add packages to them, and then you will be ready to boot a computer and install an operating system.

To create driver groups with filters

  1. Open the Windows Deployment Services MMC snap-in.

  2. Expand the Servers node and the node for your Windows Deployment Services server.

  3. Right-click DriverGroup1 and click Disable. You must disable DriverGroup1 because (by default) it does not have filters on it and therefore, it will deploy all packages to all clients.

  4. Right-click the Drivers node and click Add Driver Group.

  5. Type a name for the group, click Next, and follow the instructions to add filters as appropriate for your organization. For a list of the filters, see Driver Group Filters.

  6. On the Packages to Install screen, select Install only the driver packages that match a client’s hardware.

  7. Click Next and then click Finish.

  8. Repeat steps 3-6 until you have created and configured all desired driver groups.

Now that you have configured your driver groups, you are ready to add driver packages to them as described in the next procedure.

To add driver packages to the driver groups

  1. For packages that you have not already added to the server, right-click the Drivers node, click Add Driver Package, and follow the instructions to add the package to one of the groups that you created in the previous procedure.

  2. For packages that are already on the server but are not in the correct group, right-click the desired driver group, and click Add Driver Packages to this Group.

  3. Use the search attributes to search through the packages that are on the server, and then click Add to add them to the group.

    Note

    To add a specific package to a group, you can also right-click the package and click Add or Remove from Groups. In the dialog, configure the driver package using the arrows, and then click Apply.

  4. Repeat steps 1-3 until you have added all the packages that you want, and click Close.

  5. If you need to remove a package from a group, click the group, right-click the specific driver package in the right pane. Then you can click Add or Remove from Groups to see a list of groups that you can add it to or remove it from. You can also click Remove from this Group to remove it instantly. To delete the package from the server, right-click the package and click Delete.

Now that you have configured driver groups and added packages to them, you are ready to boot a client as described in the following procedure.

To install the driver packages and an install image

  1. Ensure that all hardware (that you want the driver packages to be installed for) is connected to client computers.

  2. Boot a computer and install an image.

  3. When the installation is complete, open Device Manager on the client computer from the Control Panel and verify that the appropriate device drivers were installed.

  • Deploying Driver Packages

  • Driver Group Filters

  • Driver and Package Attributes


Scenario 3: Deploy All Driver Packages in a Driver Group to Clients

Scenario 3: Deploy all driver packages in a driver group to clients

You can configure any driver group so that all of the packages within it will be deployed to applicable clients—not only those for which hardware is connected to the client. To configure a driver group in this way, use the following procedure.

Important

Depending on the driver packages on the server and the hardware of the client, this scenario could result in a computer that will not boot. If this happens, you will need to figure out which driver packages are causing the problem and either remove them from the server, or restrict them using filters as outlined in Scenario 2.

To install all packages to applicable clients

  1. Open the Windows Deployment Services MMC snap-in.

  2. Right-click the driver group, and click Properties.

  3. Under Applicability, select All driver packages in the group from the drop-down menu.

  4. Boot a client computer and install an image.

  5. When the installation is complete, connect the Plug and Play hardware to the client computer and verify that Windows finds the device driver for it.

Additional references

  • Deploying Driver Packages

  • Driver Group Filters

  • Driver and Package Attributes


Add Driver Packages to a Boot Image

This topic contains information about adding driver packages to a boot image, as well as links to information about how to view the drivers in an image. For more information, see Managing Driver Packages (http://go.microsoft.com/fwlink/?LinkID=143313).

Adding driver packages to boot images

You can use Windows Deployment Services to add driver packages (such as network adapter drivers, mass storage drivers, and bus drivers) to your Windows 7 and Windows Server 2008 R2 boot images. This means that you do not have to export the image, use the tools in the Windows Automated Installation Kit to add driver packages manually, and then add the updated boot image. You can add packages using the command line or the MMC snap-in.

To add driver packages to a boot image using the Windows interface

  1. Add the driver package to the server. For more information, see Extract and Add Driver Packages.

  2. In the Windows Deployment Services MMC snap-in, expand the Boot Images node.

  3. Right-click the image that you want to add the driver to, and click Add Driver Packages to Image.

  4. Follow the instructions in the wizard to search for the package and then add it to the image.

Note

If the image that you are updating is currently being downloaded to a client when you perform this procedure, Windows Deployment Services will ensure that the client receives a consistent copy of the file.

To add driver packages to a boot image using a command line

  1. Click Start, right-click Command Prompt, and then click Run as administrator.

  2. Add the image using the following syntax: WDSUTIL /Add-ImageDriverPackage [/Server:<Server name>] /Image:<Image name> /ImageType:Boot /Architecture:{x86 | ia64 | x64} [/Filename:<File name>] {/DriverPackage:<Package Name> | /PackageId:<ID>}

    For example:

    WDSUTIL /Add-ImageDriverPackage /Image:"WinPE Boot Image" /ImageType:Boot /Architecture:x86 /DriverPackage:”My Driver Package”

    or

    WDSUTIL /verbose /Add-ImageDriverPackage /Image:"WinPE Boot Image" /Server:MyWDSServer /ImageType:Boot /Architecture:x64 /PackageId:{4D36E972-E325-11CE-BFC1-08002BE10318}

Viewing the drivers in a boot image

After you add driver packages to your boot image, you can use the following procedure to view the drivers that are currently in the image. For more information about modifying a boot image, see Modify a Boot or Install Image.

To view packages in a boot image

  1. Export the image. To do this, right-click the image, click Export Image, name the file, and click Save.

  2. Click Start, right-click Command Prompt, and click Run as administrator.

  3. Mount the second image in the boot image to a local directory using the following syntax:

    Dism /Mount-Wim /WimFile:<path_to WIM_file> /index:<image_index_number> /MountDir:<path_to_mount_directory>

    Example: Dism /Mount-Wim /WimFile:C:\test\images\boot.wim /index:2 /MountDir:C:\test\offline

  4. Run the dism /Get-Drivers command to view all driver packages in the current image. For example:

    dism /image:c:\test\offline /Get-Drivers

  5. Unmount the image and commit any changes. For example:

    DISM /Unmount-Wim /MountDir:C:\test\offline /commit

  6. Add the image back to the Windows Deployment Services server. There are two ways to accomplish this:

    • Replace the existing image (as long as all installations using it have completed) (Recommended). To do this, right-click the image and click Replace Image.

    • Add the image as a new image and remove the old image at a later time.

For more information about Deployment Image Servicing and Management (DISM.exe), see http://go.microsoft.com/fwlink/?LinkId=143441.

Additional references

  • Managing Driver Packages


Troubleshoot Failed Packages

This topic contains information about common causes for failures when you attempt to add driver packages to a server or boot image.

Failures when adding packages to a server

Common causes for failed packages in this scenario include the following:

  • A corrupt package or a package that is missing files.

  • A network connectivity issue.

  • An unsigned x64-based driver package (x64-based driver packages must be signed).

  • An .inf file that is not authored correctly.

If you are adding driver packages using the MMC snap-in, then to view details about the package, double-click it from the list of failed packages. If you are adding driver packages using WDSUTIL /Add-AllDriverPackages and one or more packages could not be added, then a list of the failed packages will be printed in the console. To see a more detailed error message for one of the packages, try to add it individually using WDSUTIL (for example, WDSUTIL /verbose /Add-DriverPackage /InfFile:"C:\Temp\Display.inf").

If you cannot resolve the issue, contact the manufacturer of the package to obtain a new package and try the operation again.

Failures when adding packages to a boot image

Common causes for failed packages in this scenario include the following:

  • Adding a package that does not match the architecture of the image.

  • Adding a driver package to an unsupported image (for example, an install image).

  • Adding a package to an older boot image. You can only add packages to boot images that are based on Windows 7 and Windows Server 2008 R2.

Additional references

  • Managing Driver Packages


Resources for Windows Deployment Services

This documentation is a subset of the documentation that is online at http://go.microsoft.com/fwlink/?LinkId=134776. You can also download the Windows Deployment Services documentation (including a step-by-step guide, deployment and management guide, technical reference, and WDSUTIL command-line reference) at http://go.microsoft.com/fwlink/?LinkId=89381. In addition, see the following online resources:

  • Windows Deployment Services Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=84628)

  • Setup Deployment forum (http://go.microsoft.com/fwlink/?LinkId=87628)

  • Windows Automated Installation Kit (Windows AIK) (http://go.microsoft.com/fwlink/?LinkId=139642)

  • Windows AIK documentation (http://go.microsoft.com/fwlink/?LinkId=139641)


User Interface: Windows Deployment Services

This section contains information about the some of the user interface screens for Windows Deployment Services.

  • PXE Response Tab

  • Multicast Tab

  • DHCP Tab

  • AD DS Tab

  • Driver Group Filters

  • Driver and Package Attributes


PXE Response Tab

The settings on the PXE Response tab determine which clients Windows Deployment Services responds to, what action is taken when responding to an unknown client, and how long to wait before responding to a client. To view this tab, right-click the server in the MMC-snap in, and then click Properties.

Option Explanation

PXE Response Policy

The following options specify how the Windows Deployment Services server responds to incoming Pre-Boot Execution Environment (PXE) requests from client computers. For more information online, see Prestaging Client Computers (http://go.microsoft.com/fwlink/?LinkID=131987).

  • Do not respond to any client computers. Note that this option will only work if Windows Deployment Services and DHCP are running on different servers. This is because although Windows Deployment Services will not respond, DHCP will. You can try to work around this issue by disabling DHCP option 60 on the DHCP Tab.

  • Respond only to known client computers. Choose this option if you have prestaged clients in Active Directory Domain Services. When you select this option, clients that are not prestaged (unknown) will not be able to PXE boot to the Windows Deployment Services server.

  • Respond to all client computers (known and unknown). Choose this option to allow all clients to PXE boot to the Windows Deployment Services server. The check box labeled Require administrator approval for unknown computers is called the Auto-Add policy. Choose this option if you want to approve new clients using the Pending Devices node in the MMC snap-in before allowing them to PXE boot. For more information about this option, see Configure the Auto-Add Policy.

PXE Response Delay

Use this setting to adjust how quickly the server responds to clients on the network. It sets the amount of time that the PXE server waits for other PXE servers to respond. This setting should remain at zero (default) unless there are other PXE responders on the network that have precedence or if your network requires an increased PXE response delay.

Additional references

  • User Interface: Windows Deployment Services

  • Prestage Client Computers

  • Configure the Auto-Add Policy


Multicast Tab

On the Multicast tab, you can set the multicast IP address and the settings for how to transfer each multicast transmission. To view this tab, right-click the server in the MMC snap-in, and then click Properties. For more information about multicasting, see Enable Multicast Transmission of an Image.

Important

After you configure the Windows Deployment Services server, if you modify any of these options, or the RPC port number (by running wdsutil /set-server /rpcport:<portnum>), you must restart Windows Deployment Services before the changes will take effect. If you do not, the server will use the old values and may not answer clients. To restart the service, right-click Windows Deployment Services in the MMC snap-in and click Restart.

Option Explanation

Multicast IP Address

This setting is applicable only if you are enabling multicast transmissions. You can choose from the following options:

  • Obtain IP address from DHCP. You can only select this option if your DHCP server supports it. If you select it, the IP address will be obtained by using the Multicast Address Dynamic Client Allocation Protocol (MADCAP) (RFC 2730) for each namespace. For more information, see Multicast Address Dynamic Client Allocation Protocol (http://go.microsoft.com/fwlink/?LinkId=81507). You might want to select this setting for manageability reasons—for example, if you have multiple Windows Deployment Services servers for the same clients.

    Selecting this setting is the same as running:

    WDSUTIL /Set-Server [/Server:<name>] /Transport /ObtainIPv4From:DHCP

  • Use IP addresses from the following range. This option specifies the range of IP addresses for the Windows Deployment Services server to use. When setting this range, make sure that it does not overlap with the ranges defined for other servers. Setting this option is the same as running:

    WDSUTIL /Set-Server [/Server:<name>] /Transport /ObtainIPv4From:Range /Start:x.x.x.x /End:y.y.y.y

Transfer Settings

These settings are only available for clients that boot into a boot image from Windows 7 or Windows Server 2008 R2. These settings allow you to enable the following:

  • Single stream transfer. The first setting uses a single multicast stream for all clients, regardless of client speed.

  • Multiple stream transfer. The next two settings allow you to separate slower clients into their own multicast stream. This allows faster clients to complete their deployments more quickly instead of being held back by slower clients.

  • Automatic disconnect. The last option allows you to automatically stop clients that fall below a specified speed. The clients that are disconnected will continue to transfer the image using unicasting.

Additional references

  • User Interface: Windows Deployment Services

  • Enable Multicast Transmission of an Image


DHCP Tab

The client that is booting and the server communicate using Dynamic Host Control Protocol (DHCP) packets. The settings on the DHCP tab allow you to configure the server’s DHCP settings. To view this tab, right-click the server in the MMC-snap in, and then click Properties. For more information, see Configuring DHCP (http://go.microsoft.com/fwlink/?LinkId=131988).

This tab contains the following settings:

  • Do not listen on port 67. Select this check box if DHCP is running on the same server as Windows Deployment Services (that is, this server).

  • Configure DHCP option 60 to indicate that this server is also a PXE server. Note the following about this option:

    • When you select this option, clients booting from the network are always notified that the PXE server is available, even if the server is not operational or has stopped.

    • There are some scenarios (particularly those that require running a DHCP server) that do not support adding custom DHCP option 60 on the same physical computer as the Windows Deployment Services server. In these circumstances, it is possible to configure the server to bind to User Datagram Protocol (UDP) port 67 in nonexclusive mode by passing the SO_REUSEADDR option. For more information, see Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE (http://go.microsoft.com/fwlink/?LinkId=82387).

If DHCP is installed on a server that is located in a different subnet, you will need to do one of the following: configure your IP Helper tables (recommended) or add DHCP options 66 and 67. For more information about these settings, see Managing Network Boot Programs (http://go.microsoft.com/fwlink/?LinkId=115304).

Additional references

  • User Interface: Windows Deployment Services


AD DS Tab

You can use the AD DS tab to specify the computer naming policy and where to create the computer account. The settings on this tab will be applied when administrative approval is required for unknown computers (this is a setting on the PXE Response Tab). That is, these settings do not apply to computer accounts that you prestage in Active Directory Domain Services (AD DS). To view this tab, right-click the server in the MMC snap-in, and then click Properties. For more information online, see Configuring AD DS Integration (http://go.microsoft.com/fwlink/?LinkId=143071).

Computer naming policy

The following table outlines the variables that you can specify to create the customized name. You can use these options separately, or you can combine them.

Variable | Result
%First | The user's first name. You can limit the length of the first name by adding a numerical value between the % and First. For example, %5First will limit the first name to five characters.
%Last | The user's last name. You can limit the length of the last name by adding a numerical value between the % and Last. For example, %5Last will limit the last name to five characters.
%Username | The user name. You can limit the length of the user name by adding a numerical value between the % and Username. For example, %5Username will limit the user name to five characters.
%MAC | The media access control (MAC) address for the network adapter.
%[0][n]# | The computer name includes an incremental number containing n digits. To include zero-padding in the incremental number, type a zero as shown. For example, if you use %03#, a three-digit number in the range from 001 through 999 is used.

Examples

  • If you want to limit the computer name to three characters of the user's last name with a two-digit incremental number appended, you would type the string %3Last%02#. For example, for the fifth computer user whose last name is Smith, the corresponding computer name would be Smi05.

  • If you want the computer name to consist of the first three letters of the user's first name, followed by the first three letters of the user's last name, followed by a three-digit incremental number, type the string %3First%3Last%03#.

Note the following issues when you set the client naming policy:

  • 15 characters is the maximum length for a computer name. However, the default policy allows names up to 63 characters. When a name that is more than 15 characters is generated, any characters after the first 15 will be truncated, and the computer will be unable to join the domain. You must specify a naming policy that generates names with 15 or fewer characters.

  • The computer name can contain only standard characters as defined in RFC 1123 (Requirements for Internet Hosts - Application and Support) as follows: all uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), and a hyphen (-).

Computer account location

This section allows you to specify the location where you want Windows Deployment Services to create accounts for computers that are pending administrative approval. If you do not want any computers to be joined to a domain after installation, you can specify this on the Client tab.

Additional references

  • User Interface: Windows Deployment Services


Driver Group Filters

You can use filters to map client computers to the packages in a driver group. The filters define which clients will install the drivers. For example, you can configure drivers to be installed based on the hardware of the client (for example, manufacturer or BIOS vendor) and the attributes of the Windows image that is selected during the installation (for example, the version or edition). In addition, you can configure whether clients install all packages in a driver group, or only the drivers that match the installed hardware on the client. For instructions on how to configure these filters in order to deploy driver packages, see Deploying Driver Packages.

Note

A package can be in many driver groups, but it must be in at least one group in order to be available to clients.

To create a driver group, right-click the Drivers node and click Add Driver Group. To modify the filters for a driver group, right-click the group and click Modify Filters for this Group.

Note the following functionality when adding filters to a driver group:

  • The filter value must exactly match the client hardware or the install image specifications. The two available operators for filters are Equal to or Not equal to. Therefore, if the value you specify is one character off (for example, if you omit a period) the filters will not match the clients as intended. For this reason, we recommend that you create multiple filter values to account for all cases. For example, create filter values for Fabrikam, Inc., Fabrikam, and so on. Note that the filter is not case sensitive, and leading and trailing spaces are ignored.

  • If you do not add any filters, all clients will have access to the drivers in the group. If you add one or more filters, clients must match all filters in order to have access to the drivers. In addition:

    • If the operator of a filter is set to Equal to, then the filter will match if a client’s value is equal to one or more values in the list.

      Example: If you add Chassis Type|Equal to|Mini Tower, Laptop, then all mini tower and laptop computers will match, but those computers with other chassis types will not match.

    • If the operator is set to Not Equal to, then the filter will match only if the client’s value is not equal to any of the values in the list. That is, only those clients that have a value that is different from all the values in the filter will match.

      Example: If you add UUID|Not equal to|<UUID 1>, <UUID 2>, then all clients except for the two specified computers will match.

For more examples, see Examples.

In this topic

  • Client hardware filters

  • Install image filters

  • Examples

Client hardware filters

You can add client hardware filters to a driver group if you want clients with certain hardware to receive the drivers in a group. Note that drivers are automatically filtered by the architecture of the client.

Filter type | Accepted Values | Description and Examples
Manufacturer | String | The name of the manufacturer as listed in the BIOS. You can find this information on the client computer using the System Information tool (Msinfo32.exe). To open this tool, click Start, click Run, type msinfo32.exe, and then click OK. This value is listed as the System Manufacturer.
Bios Vendor | String | The name of the BIOS vendor as listed in the BIOS. To find this information on a client computer, run wmic bios get manufacturer from a command prompt. The first line of the output is the attribute name. Use the entire second line of output for the Bios Vendor.
Bios Version | String | The BIOS version as defined by the manufacturer. To find this information on a client computer, run wmic bios get smbiosbiosversion from a command prompt. The first line of the output is the attribute name. Use the entire second line of the output for the Bios Version.
Chassis Type | String | The physical container that contains the components of a computer. Traditionally, the only way to identify the chassis type has been by visual inspection. However, you can write a script using the Windows Management Instrumentation (WMI) class to determine the chassis type of a computer. For more information, see http://go.microsoft.com/fwlink/?LinkId=143449.
UUID | GUID with brackets in the format: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} | The computer GUID as listed in the BIOS and as displayed on the screen when you PXE boot a computer. You can also write a WMI script to obtain this information using the universally unique identifier (UUID) value of the Win32_ComputerSystemProduct class. For more information, see http://go.microsoft.com/fwlink/?LinkId=143450. For example: {E8A3EFAC-201F-4E69-953E-B2DAA1E8B1B6}.

Install image filters

You can add install image filters if you want clients that select specific images to have access to a driver group. The following filter types are from the metadata of the image .wim file.

Filter type Accepted Values Description and Examples

OS Version

Number

The operating system version of the install image that is chosen by the user in the form: Major.Minor.BuildNumber.ServicePackNumber. For Windows Vista with Service Pack 1 (SP1) and the initial release of Windows Server 2008, specify 6.0.6001.18000.

To locate these values for an image

  1. Locate the image in the Windows Deployment Services MMC snap-in.

  2. Right-click the image and click Properties.

  3. On the Version tab, click Image version and note the value in the right column. Note that this value is missing the ServicePackNumber – that is, it is in the form Major.Minor.BuildNumber.

  4. To locate the ServicePackNumber, click Service Pack level and note the value in the right column.

  5. To create a filter with the correct format, insert ServicePackNumber after Major.Minor.BuildNumber. For example, if 6.1.7025 was listed and the service pack number is 2, specify 6.1.7025.2 as the value for this filter.

OS Edition

String

The edition of the image that the user chooses. For example: BUSINESS or ULTIMATE. You can find the OS Edition by using Deployment Image Servicing and Management (DISM.exe).

To view the operating system edition of computer

  1. If the computer is running Windows Vista with SP1 or the initial release of Windows Server 2008, install the latest version of the Windows Automated Installation Kit (Windows AIK).

  2. Open an elevated command prompt (right-click Command Prompt and click Run as administrator).

  3. Run Dism /online /Get-CurrentEdition.

To view the operating system edition of an image

  1. Export the image to a new file. To do this, right-click the image in the MMC snap-in, click Export, name the file, and click Save.

  2. Open an elevated command prompt (right-click Command Prompt and click Run as administrator).

  3. Mount the image using the following syntax:

    Dism /Mount-Wim /WimFile:<path_to WIM_file> /index:<image_index> /MountDir:<target_mount_directory>

    Example: Dism /Mount-Wim /WimFile:C:\test\images\install.wim /index:1 /MountDir:C:\test\offline

  4. To list information about the current edition, run Dism /image:C:\test\offline /Get-CurrentEdition.

OS Language

String in the form XX-XX

The language of the image in the format <language>-<REGION>, where <language> is the lowercase ISO 639 language code and <REGION> is the uppercase ISO 3166-1 country/region identifier. The valid language specifications are listed in the Culture Name column on the National Language Support (NLS) information page (http://go.microsoft.com/fwlink/?LinkId=86010). For example, en-US, ar-SA, and de-DE.

Examples

Filters Result

Hardware filters:

  • Manufacturer | Equal to | Fabrikam, Inc.

  • Chassis Type | Not equal to | Laptop

Install image filters:

  • OS Version | Equal to| 6.0. 6001.18000

  • OS Edition | Not equal to | Business

Applicability: Driver packages matching client hardware

The only clients that will have access to these drivers are Fabrikam, Inc. computers that are not laptops. Of those computers, only clients that select a Windows Vista with SP1 image that is not Windows Vista Business will have access to these drivers. The applicability setting indicates that, for those clients that have access to the driver group, Windows Deployment Services will only install packages that match the client’s hardware.

Hardware filters:

  • UUID | Equal to | {E8A3EFAC-201F-4E69-953E-B2DAA1E8B1B6}

Install image filters:

  • OS Edition | Not equal to | Ultimate

Applicability: Driver packages matching client hardware

The only client with access to these drivers is the client with the specified UUID, and only if that client selects an image other than a Windows Vista Ultimate image. The applicability setting indicates that, for those clients that have access to the driver group, Windows Deployment Services will only install packages that match the client’s hardware.

Hardware filters: none

Install image filters:

  • OS Version | Equal to | 6.0.6001.18000

  • Language | Not equal to | en-us

Applicability: All packages in the group

Only clients that select a non-English (United States) Windows Vista with SP1 image will have access to these drivers. The applicability setting indicates that, for those clients that have access to the driver group, Windows Deployment Services will install all of the driver packages in this group—even those packages for which the client does not have hardware.

Additional references

  • Deploying Driver Packages

  • Driver and Package Attributes


Driver and Package Attributes

After you have driver packages on your server, you can delete them from the server, enable or disable them, or add a selection of them to a driver group.

  • To delete, enable, or disable driver packages, right-click the Drivers node, and click the task you want to perform.

  • To add packages to a group, right-click the driver group and click Add Driver Packages to this Group.

This topic contains information about the attributes that you can search on in order to perform these tasks. For instructions on how to configure these attributes in order to deploy driver packages, see Deploying Driver Packages.

  • Driver package attributes

  • Driver file attributes

Driver package attributes

The following attributes apply to the entire driver package. A driver package consists of a set of software components that are required for a device to be supported by Windows—for example, the driver files (typically with the .sys file name extension) and the installation files. For more information about driver packages, see http://go.microsoft.com/fwlink/?LinkId=143447.

Attribute Type Accepted Values Description and Examples

Package ID

GUID in the form {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

The GUID that is randomly generated when a driver package is added to the Windows Deployment Services server. To find this number for a package, click the driver group that the package is in (or the All Packages node), right-click the package and click Properties. The Package ID is listed on the General tab. For example: {DD098D20-1850-4FC8-8E35-EA24A1BEFF5E}.

Package Name

String

The name of the package on the server. By default, the name is InfFilename [arch]. To determine this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the Package Name column.

Package Enabled

Yes|No

Specifies whether or not the package is enabled on the server. Disabled packages are not available to clients. To view this value, click the driver group that the package is in (or the All Packages node), right-click the package and click Properties. The Status is listed on the General tab.

Package Date Added

Date

The date the package was added to the Windows Deployment Services server. To locate this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the Date Added column. If you are managing servers in different time zones, note that this date is the local time for the server and not the Coordinated Universal Time (UTC).

Package Inf Filename

String

The name of the .inf file associated with the driver package. To locate this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the File Name column. You must specify the name including the .inf extension.

Package Class

String or GUID

A valid class name or class GUID. For a list of class names and GUIDs, see System-Supplied Device Setup Classes (http://go.microsoft.com/fwlink/?LinkId=143448). To locate this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the Class Name and Class GUID columns. For example, you can specify either Net or {4D36E972-E325-11CE-BFC1-08002BE10318}.

Package Provider

String

The company that provided the driver package as stated in the package .inf file. To locate this value, click the driver group that the package is in (or the All Packages node), right-click the driver package, and click Properties. The Provider is listed on the General tab. For example: SigmaTel or Microsoft.

Package Architecture

X86|x64|ia64

The architecture of the package. To locate this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the Architecture column.

Package Locale

String in the form XX-XX

The locale for the package. Although it is rare, some .inf package files indicate that a package is only valid for a specific locale. In these cases, you can search for the locale using this attribute. To locate this value, click the driver group that the package is in (or the All Packages node), right-click the driver package, and click Properties. The Locale is listed on the General tab.

The language is in the format <language>-<COUNTRY/REGION>, where <language> is the lowercase ISO 639 language code and <COUNTRY/REGION> is the uppercase ISO 3166-1 country/region identifier. The valid language specifications are listed in the Culture Name column on the National Language Support (NLS) information page (http://go.microsoft.com/fwlink/?LinkId=86010). For example, en-US, ar-SA, and de-DE.

Package Signed

Yes|No

Specifies whether the driver package has a signature file. Note that Windows Deployment Services does not determine whether the signature is trusted on the Windows Deployment Services server, just whether it is a valid signature file. To locate this value, click the driver group that the package is in (or the All Packages node), right-click the driver package, and click Properties. Is package signed is listed on the General tab.

Package Date Published

Date

The date the package was released by the manufacturer as listed in the .inf file. To locate this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the Package Date column.

Package Version

String

The version of the package as specified in the .inf file. To locate this value, click the driver group that the package is in (or the All Packages node), locate the driver package, and view the Version column. For example: 2.1.2.

Driver file attributes

The following attributes (except for Driver Group Name) are for the individual drivers within the driver packages. To view a list of the drivers, right-click a driver package, click Properties, and select the Drivers tab.

Attribute Type Accepted Values Description and Examples

Driver Description

String

The description of the driver from the .inf file. To view a driver’s description, click the driver group that the package is in (or the All Packages node), right-click the driver package, and click Properties. The drivers and descriptions are listed on the Drivers tab.

Driver Manufacturer

String

The manufacturer of the driver as indicated in the package .inf file. To view a driver’s manufacturer, click the driver group that the package is in (or the All Packages node), right-click the driver package, and click Properties. The drivers and manufacturers are listed on the Drivers tab.

Driver Hardware ID

String

Driver Hardware IDs, Driver Compatible IDs, and Driver Exclude ID s are vendor-defined device identification strings that Setup uses to match a device to an .inf file. These IDs are Plug and Play IDs that refer to the driver packages. For example, if a driver is valid for a specific network adapter, the device ID of the network card will be a Driver Hardware ID for the driver. If the driver is generic and works on any version of the network card, then the corresponding device IDs will be listed as Driver Compatible IDs. Lastly, if there is one version of the card that this driver is not valid for, then the device ID for that card will be listed as an Driver Exclude ID (this is rare).

To locate these values, click the driver group that the package is in (or the All Packages node), right-click the driver package, and click Properties. The IDs are listed on the Drivers tab under PnP IDs. Driver Hardware IDs have an asterisk (*) before the ID, Driver Compatible IDs have a plus sign (+) before the ID, and Driver Exclude IDs have a minus sign (-).

Driver Compatible ID

String

See “Driver Hardware ID”.

Driver Exclude ID

String

See “Driver Hardware ID”.

Driver Group Name

String

The name of the driver group on the server that the package is in. You can use this attribute to restrict the search to one or more of the driver groups. To view the groups that a driver package is in, locate the package in the All Packages node, right-click the package, click Properties, and view the Group Membership tab.

Additional references

  • Deploying Driver Packages

  • Driver Group Filters