Frequently Asked Questions for Windows Deployment Services
| • | What happened to RIS? |
| • | What happened to the Single Instance Store? |
| • | Can I use Windows Deployment Services (especially multicasting) with virtual computers? |
| • | What is the difference between install images and boot images? |
| • | What is the Legacy Images node in the MMC? |
| • | How do I maintain my boot and install images? |
| • | Can I have multiple Windows Deployment Services servers on the network? |
| • | 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? |
| • | What logs should I look at to troubleshoot issues? |
| • | How do I turn on logging? |
| • | How do I replicate images? |
| • | How do I join a computer to a domain? |
| • | How do I set up computer naming? |
| • | How do I use WDSMCast to transmit other types of files? |
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 Chapter 12: Multicasting with Deployment Server) |
| • | The ability to transmit data and images by using multicast namespaces on a stand-alone server (when you install Chapter 14: 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 Chapter 12: Multicasting with Deployment Server) |
| • | The ability to transmit data and images by using multicast namespaces on a stand-alone server (when you install Chapter 14: Transport Server) |
| • | No support for RISETUP images or OSChooser screens |
| • | An enhanced TFTP server (see Chapter 3: Server Components and Chapter 4: PXE Boot) |
| • | The ability to boot from the network on x64-based computers with Extensible Firmware Interface (EFI) (see Chapter 4: PXE Boot) |
| • | Metric reporting for installations (see Appendix B: Logging, Tracing, and Diagnostics) |
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 Window 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 Chapter 6: Working with 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. |
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 Chapter 6: Working with Images.
To export an image in the store to a standalone .wim
| Using the MMC | Using WDSUTIL |
| • | 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>.
|
Configuration
Can I have multiple Windows Deployment Services servers on the network?
Yes. For more information, see Chapter 13: Managing a Complex Environment.
What permissions do I need to configure?
For information about the permissions that you need, see Appendix C: 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: Windows Vista images that support the Unattend.xml format, and Windows XP and Windows Server 2003 images, which use the Sysprep.inf file. 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 Chapter 8: Performing Unattended Installations.
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 Appendix C: 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 Appendix B: Logging, Tracing, and Diagnostics.
How do I turn on logging?
For information about how to turn on logging, see Appendix B: Logging, Tracing, and Diagnostics.
Common Tasks
The following section contains an assortment of common tasks. For a more extensive list, see Chapter 10: How to Perform Common Tasks.
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>].
How do I join a computer to a domain?
For detailed information about this topic, see the “Domain Join and Computer Naming” section in Chapter 8: 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 Chapter 8: Performing Unattended Installations.
| Using the MMC | Using WDSUTIL |
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 |
How do I use WDSMCast to transmit other types of files?
The following steps outline the general process for using WDSMCast to transmit data.
| 1. | Install the Transport Server role service. |
For more information about this procedure, see Chapter 14: Transport Server.