Partager via

Windows Deployment Services: Frequently Asked Questions

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

In this topic:

General

  • What happened to RIS?

  • What happened to the Single Instance Store?

  • Can I use Windows Deployment Services (especially multicasting) with virtual computers?

Boot and Install Images

  • What is the difference between install images and boot images?

  • What is the Legacy Images node in the MMC snap-in?

  • How do I maintain my boot and install images?

  • How do I replicate images?

Configuration

  • What permissions do I need to configure?

  • Why do I need two unattend files?

  • Can I protect my users by requiring them to log in before they have a chance to reformat their hard drives?

Diagnostics

  • What logs should I look at to troubleshoot issues?

  • How do I turn on logging?

Domain Join and Computer Naming

  • How do I join a computer to a domain?

  • How do I set up computer naming?

  • When I am joining clients to a domain, can I avoid creating a local user account on the computer?

General

What happened to RIS?

Windows Deployment Services is the updated and redesigned version of Remote Installation Services (RIS). Windows Deployment Services includes several modifications to RIS features. There are also modifications in Windows Server 2008 from the Windows Deployment Services update that you can install on computers running Windows Server 2003. These modifications are described in the following table.

Changes from RIS Changes from Windows Deployment Services on Windows Server 2003
  • The ability to deploy Windows Vista and Windows Server 2008

  • Windows PE is the boot operating system

  • Image-based installation, using the Windows image (.wim) file

  • The ability to transmit data and images by using multicast transmissions (see How to Create Multicast Transmissions)

  • The ability to transmit data and images by using multicast namespaces on a stand-alone server (when you install Using Transport Server)

  • An extensible and higher-performing PXE server

  • A new boot menu format for selecting boot images

  • A new GUI that you can use to select and deploy images and to manage Windows Deployment Services servers and clients
  • The ability to transmit data and images by using multicast transmissions (see How to Create Multicast Transmissions)

  • The ability to transmit data and images by using multicast namespaces on a stand-alone server (when you install Using Transport Server)

  • No support for RISETUP images or OSChooser screens

  • An enhanced TFTP server

  • The ability to boot from the network on x64-based computers with Extensible Firmware Interface (EFI)

  • Metric reporting for installations (see Logging and Tracing)

What happened to the Single Instance Store?

Windows Deployment Services does not use the Single Instance Store functionality that was used in RIS. Instead, Windows Deployment Services uses a method by which file resources are shared across each image group (and therefore single-instanced) and the metadata of each image resides in a separate .wim file. The image store takes the concept of split .wim images a step further by creating a split media set consisting of two files:

  • An "empty" .wim file that contains only the definition of the image

  • A Res.rwm file that contains all the file resources for all images in the image group. The data within Res.rwm is single-instanced and compressed; therefore, the Single Instance Store service is no longer needed. In fact, with Windows Deployment Services, the storage size on disk for images within an image group is greatly reduced, and it is more efficient than the storage mechanism used in RIS.

Can I use Windows Deployment Services (especially multicasting) with virtual computers?

Windows Deployment Services should work on virtual computers. Note, however, that the performance will often be degraded, particularly during the Trivial File Transfer Protocol (TFTP) download phase. This phase is very resource-intensive and may fail if insufficient resources are available on the host computer.

Boot and Install Images

What is the difference between install images and boot images?

Install images are the operating system images that you deploy to the client computer. Boot images are the images that you boot a client computer into to perform an operating system installation. Boot images contain Windows PE and the Windows Deployment Services client (the client is essentially Windows Vista Setup.exe and its supporting files for Windows Deployment Services). You can use the standard boot images that are included on the Windows Vista or Windows Server 2008 media (located at \Sources\boot.wim) without modification. However, the Boot.wim that you use must match or be newer than the operating system of the install image. For example, if you are installing Windows Vista, you must use the boot image from the Windows Server 2008 media; you cannot use the Boot.wim from the Windows Vista media. You can also create custom boot images. For more information, see Creating Images.

What is the Legacy Images node in the MMC?

The Legacy Images node in the Windows Deployment Services MMC snap contains any RIS images that were left after an upgrade from a computer running Windows Server 2003. If you did not upgrade your computer, this node will be empty and will be of no use to you.

How do I maintain my boot and install images?

The following procedures cover some of the common tasks that you may want to perform with your images. For more procedures, see How to Manage Images.

To modify and reimport an image

  1. Open the Windows Deployment Services MMC snap-in, right-click the image, and then click Disable. This will allow existing installations to continue, but new clients will not be able to install the image.

  2. Right-click the image, and then click Export Image.

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

  4. Assuming that all installations using it have completed, right-click the image and then click Replace Image. Then browse to the updated version and proceed through the rest of the wizard.

To force an in-place conversion of an RIPREP image

When converting an RIPREP image offline, it is possible to force an in-place conversion of a RIPREP image, which will save time and the amount of disk space that you use during the conversion process. You can do this by using the /InPlace option with the WDSUTIL /Convert-RiprepImage command. It is common for variations of a single RIPREP image (differing only by HAL type) to exist on the same server. You can save time during the conversion process by using the /Overwrite:Append option of the WDSUTIL /Convert-RiprepImage command to take advantage of single-instancing technology within the .wim format. The append operation is much faster than a traditional capture because it avoids compressing and inserting files that already exist in the .wim. Files that are identical between images and that already exist within the .wim file will just have their reference count incremented to indicate that the single file belongs to multiple images within the .wim. The general conversion process is to first convert the first RIPREP image of the set by creating a new .wim file. Then convert the remaining RIPREP images of the set (for the other HAL types) by appending them to the .wim you created previously. For more information, see Creating Images.

To export an image in the store to a standalone .wim

Using the MMC Using WDSUTIL
  1. Right-click a boot or install image, and then click Export Image.

  2. In the dialog box, choose a file name to export the image to.
  • For a boot image, run the command WDSUTIL /Verbose /Progress /Export-Image /Image:<name> /ImageType:Boot /Architecture:{x86|x64|ia64} /DestinationImage /Filepath:<path and filename>.

  • For an install image, run the command WDSUTIL /Verbose /Progress /Export-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name> /DestinationImage /Filepath:<path and filename>.

    • To set these metadata fields on the image, append /Name:<name> or /Description:<description> to the command.

    • To determine behavior when the image specified with /DestinationImage already exists, append /Overwrite:{Yes|No|Append} to the command. Yes will overwrite the image, No will cause an error to occur in the process, and Append will append the new image to the existing .wim file. Note that the Append is available only for install images.

How do I replicate images?

To make a copy of an install image, run the command WDSUTIL /Copy-Image /Image:<name> /ImageType:Install /ImageGroup:<image group name> /DestinationImage /Name:<name> /Filename:<filename> [/Description:<description>].

Configuration

What permissions do I need to configure?

For information about the permissions that you need, see Required Permissions.

Why do I need two unattend files?

Two unattend files are necessary because the Windows Deployment Services client can deploy two image types: images that support the Unattend.xml format (for example, Windows Vista), and images that use the Sysprep.inf file (for example, Windows XP). The two files that you must create to automate Setup are the following:

  • Windows Deployment Services client unattend file. This file uses the Unattend.xml format and is stored on the Windows Deployment Services server in the \WDSClientUnattend folder. It automates the Windows Deployment Services client user interface screens (such as entering credentials, choosing an install image, and configuring the disk).

  • Image unattend file. This file uses either the Unattend.xml or Sysprep.inf format, depending upon the version of the operating system in the image. It is used to configure unattended installation options during Windows Setup and is stored in a subfolder (either $OEM$ structure or \Unattend) in the per-image folder. It automates the remaining phases of Setup (for example, offline servicing, Sysprep specialize, and mini-setup).

For more information, see Performing Unattended Installations. For sample files, see Sample Unattend Files.

Can I protect my users by requiring them to log in before they have a chance to reformat their hard drives?

No permissions are required for the following actions:

  • Booting a client into PXE (no mechanism exists to secure the process of booting from the network).

  • Selecting a boot image (no mechanism exists to secure the boot images that are listed).

If security is a concern for you, we recommend that you use physical Windows PE media to boot each client computer. The first authentication mechanism for a network installation occurs when the Windows Deployment Services client is running within Windows PE. At this point, users must enter credentials to select an install image. These credentials must be those of a domain account. After a client has been authenticated to the Windows Deployment Services server, the authenticated user must be able to read the Image.wim and Res.rwm files for an image from the RemoteInstall folder. By default, authenticated users have the necessary permissions to do so. For more information, see the "Permissions for Client Installations" section in Required Permissions.

Diagnostics

What logs should I look at to troubleshoot issues?

There are various logs that you can look at to troubleshoot your issues. For a complete list of the logs, see Logging and Tracing.

How do I turn on logging?

For information about how to turn on logging, see Logging and Tracing.

Domain Join and Computer Naming

For a more extensive list of common tasks, see How to Perform Common Tasks.

How do I join a computer to a domain?

For detailed information about this topic, see the "Domain Join and Computer Naming" section in Performing Unattended Installations. To prestage a client computer to join a domain by using WDSUTIL, do one of the following:

  • To enable a user to join the client computer to a domain once, run the command WDSUTIL /Set-Device /Device:<name> /User:<user> /JoinRights:JoinOnly /JoinDomain:Yes /Domain:<domain> /ResetAccount, where:

    <user> is domain\user or user@domain.

    <name> is the name of the device.

    <domain> is the name of the domain.

  • To enable a user to join the client computer to a domain at any time, run the command WDSUTIL /Set-Device /Device:<name> /User:<user> /JoinRights:Full /JoinDomain:Yes /Domain:<domain>.

  • To join the client computer to a domain without granting any user rights, run the command WDSUTIL /Set-Device /Device:<name> /JoinDomain:Yes /Domain:<domain>.

How do I set up computer naming?

To specify a policy for generating client computer names, use one of the following methods. For detailed information about this topic, see the "Domain Join and Computer Naming" section in Performing Unattended Installations.

Using the MMC Using WDSUTIL
  1. Right-click the server name, and then click Properties.

  2. On the Directory Services tab, enter the naming policy in the indicated field.
  1. Open an elevated Command Prompt window.

  2. Run WDSUTIL /Set-Server /NewMachineNamingPolicy:<Policy>

    The policy string works as follows:

    • %First: the user's first name

    • %Last: the user's last name

    • %Username: the user's user name

    • %MAC: the MAC address of the computer

    • %n#: an incremental n-digit number. For example, %2# will add a number to the computer name in the following order: 1,2,3,…99.

    • %0n#: an incremental n-digit number, with zeros added before the digit. For example, %02# will add a number to the computer name in the following order: 01,02,03,…99.

    These values can be combined in any order. A number before a tag string (such as %3First or %5Username) will crop the string to that length. For example:

    %61Username%# equals JohnSmi12

    %2first.%last equals Jo.Smith

When I am joining clients to a domain, can I avoid creating a local user account on the computer?

Yes. To do this, create an image unattend file that adds a domain account to the Administrators group. In addition, you must delete the <LocalAccounts> section if it is present in your unattend file (simply commenting it out will not work). An example file is below. Note that if domain join fails, Windows Deployment Services will not use the unattend file so you will be able to create a local account. For more information about creating unattend files, see Automating Setup.

<?xml version='1.0' encoding='utf-8'?>
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:ms="urn:schemas-microsoft-com:asm.v3" xmlns:wcm="https://schemas.microsoft.com/WMIConfig/2002/State">
    <settings pass="oobeSystem">                                
        <component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="amd64">
            <UserAccounts>
                <AdministratorPassword>
                    <Value>password</Value>
                    <PlainText>true</PlainText>
                </AdministratorPassword>
                <DomainAccounts>
                    <DomainAccountList wcm:action="add">
                        <DomainAccount wcm:action="add">
                            <Group>Administrators</Group> 
                            <Name>DomainAdmin</Name> 
                        </DomainAccount>
                        <Domain>DomainName</Domain> 
                    </DomainAccountList>
                </DomainAccounts>
            </UserAccounts>
        </component>
   </settings>  
</unattend>