This chapter highlights some common issues that you may encounter when using Windows Deployment Services including the following:
Performing PXE Boots on Client Computers
I am unable to perform PXE boots on client computers.
The most common causes for this issue are:
- A boot image has not been added to the
server. Use the management tools to add the Boot.wim from the
Windows Server 2008 media to the server. For instructions, see
the Windows Deployment Services Getting Started
- The services for Windows Deployment Services
have not been started. To fix this, run WDSUTIL
/start-server to start all services. Examine the output of the
command and the Windows Application event log for error messages
indicating service start-up failures.
- The necessary firewall ports are not open on
the server. Ensure that the proper ports are open to enable the
client to connect to the Windows Deployment Services server. For
more information, see Network Ports
- The answer policy is not configured
correctly. For example, the server is not configured to answer
clients, or it is configured to answer only known clients and the
client is not prestaged. To fix this, reconfigure the policy. For
example, run WDSUTIL /set-server /answerRequests:all. For
instructions, How to Manage Client
- The computer is marked as approved in the
Auto-Add database, but a computer account representing the computer
does not exist in Active Directory Domain Services (AD DS). To fix
this, purge the database using the steps in Prestaging Client
- The computer is marked as rejected in the
Auto-Add database. After a computer has been marked as rejected,
the computer will not be able to PXE boot. You can clear the entry
in the Auto-Add database by deleting all pending computer records
(by running WDSUTIL /delete-AutoAddDevices
/DeviceType:RejectedDevices) or enabling the record to be
purged automatically (according to the default cleanup interval).
For instructions, see the Auto-Add Database section of How to Manage Client
- Client boot requests are not getting routed
correctly to the Windows Deployment Services server. To ensure that
the IP Helper router is updated and that the Dynamic Host Control
Protocol (DHCP) option configuration has been completed correctly,
see "Methods of Directing a Client to the Appropriate NBP" in
- The client has been prestaged and a network
boot program (NBP) has been defined; however, the NBP does not
exist on the server. Examine the output from WDSUTIL /get-device
/Device:<device name> to determine the name and path of
the NBP. Then check that location on the Windows Deployment
Services server to ensure that the file exists. If it does not
exist, run WDSUTIL /Set-device to direct the client to a
- DHCP and Windows Deployment Services are
running on the same physical computer, but the settings associated
with this configuration have not been defined. To configure this,
see the DHCP section of How to Manage Your
Server. For more information, see Configuring
When I perform a PXE boot and select a boot image, I see a command prompt.
If you do not see the UI from Setup.exe when you boot into a boot image, the boot image probably does not contain the Windows Deployment Services client (which is basically Setup.exe and supporting files for Windows Deployment Services). One common cause of this is if you created an image of Windows PE by using the Windows AIK instead of using the Boot.wim file from the Windows Vista or Windows Server 2008 DVDs. To fix this, upload the Boot.wim file located in the Sources directory of Windows Server 2008 DVD. This image contains the Windows Deployment Services client and Windows PE.
The client computer fails to get an IP address when I try to PXE boot.
The most common causes of this problem are:
- There is a problem with the network.
- There is a problem with DHCP.
To resolve these issues, check Event Viewer for events and errors, and then refer to the DHCP Infrastructure troubleshooting documentation (http://go.microsoft.com/fwlink/?LinkId=108014) for steps you can use to resolve the problem. If you are using a non-Microsoft DHCP server, contact the manufacturer for troubleshooting information.
The client computer obtains an IP address but then fails to download a NBP.
You may have a problem with the network or the configuration of the Windows Deployment Services server. A common cause is if a client is on a different subnet from the Windows Deployment Services server and you have not configured the server to get the PXE signal through the router. To fix this, see the "Updating the IP Helper Tables" section in Managing Network Boot Programs.
I don't see the hard drive of the client computer on the disk configuration page of Setup.
The most common cause of this problem is that the client computer does not have the correct storage driver from the hardware manufacturer. To fix this, do one of the following:
- Add the driver to the image by using the
tools in the Windows AIK.
- Click Add Driver on the disk
configuration page, and then specify the driver.
My computer loads the boot image, but it cannot access an install image.
The boot image may not contain the correct network driver for the client computer. To resolve this, on the client computer, press SHIFT+F10 to open a command prompt and run IPConfig. If an IP address and subnet mask are not reported in the output, this indicates that networking has not been started and it is likely that a network driver is not present. To fix this, add the driver from the hardware manufacturer to the image by using the tools in the Windows AIK.
I created an unattend file, but when installation completes, my client computer is not joined to the domain.
There are two common causes for this issue:
- The image unattend file is not formatted
properly. To verify that your file is correctly formatted, see
Domain Join and Sample Unattend
- The client computer does not have permissions
to join a domain. To resolve this, check for an error in
\Windows\panther\setupact.log under domainjoininformation,
and grant the appropriate permissions. For more information, see
Install images do not appear on the image selection page.
The most common causes of this problem are:
- The account whose credentials were entered on
the credential screen of Windows Deployment Services client does
not have permissions to read the install .wim file. These images
are located at
Group>. For more information, see Required
- The architecture of the client computer (x86,
Itanium, x64) does not match the architecture type of the install
image. A client booting into an x86-based boot image will only be
able to view x86-based install images on the image selection
- You may have an incompatible hardware
abstraction layer (HAL) type. To deploy an image to this computer,
you will need an image that has the correct HAL type — that is, an
image that was captured from a computer that has the same HAL type
as this computer.
Troubleshooting x64-Based Client Computers
My x64-based client computer does not have any x64-based images on the boot image selection page.
Many x64-based system BIOS do not accurately identify the computer as x64 during the boot process. If Windows Deployment Services does not recognize the computer as x64, only x86 images will be shown. Run WDSUTIL /set-server /architecturediscovery:yes to force the Windows Deployment Services server to recognize x64 computers.
My x64-based client computer is detected as x64, but it fails to boot to the default image.
If an x64-based computer performs a PXE boot but does not find an x64-based image, it will be unable to complete the boot process. Ensure that your Windows Deployment Services server has the x64-based version of Boot.wim. Alternatively, you can force all x64 clients to only receive x86 boot files by configuring the default boot program—for example, configure Pxeboot.com from \RemoteInstall\boot\x86. For more information, see Managing Network Boot Programs.
Performing Management Operations
I can't approve a pending computer.
The two most common causes of this issue are the following:
- You do not have the correct permissions in AD
DS for the computer. Each computer requires a computer certificate.
For more information, see Required
- The computer name is not valid. For example,
the name might be too long, or it might contain characters that are
I approved a pending computer and then deleted the computer account that was created in AD DS during the process. Now the server will not answer my client computer.
Deleting a prestaged computer that was added to AD DS by using the approval process for pending computer involves two steps:
- Remove the computer account from AD DS.
- Remove the record in the Auto-Add
Failing to remove the record in the database will cause the client to remain in Wdsnbp.com, and it will not proceed with booting from the network. This occurs because the record in the Auto-Add database shows the computer as approved, but a prestaged computer in AD DS will not be found (because the computer was deleted).
This scenario is identical to a case where there is AD DS replication latency. For example, the server will not permit the client to proceed past Wdsnbp.com until a prestaged computer appears in AD DS.
For more information, see Prestaging Client Computers.
I received the error: "0x2: File not found" when trying to manage a remote Windows Deployment Services server.
You may have received this error if you are trying to manage a Windows Deployment Services server running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2003.This scenario is not supported. You can only manage Windows Deployment Services servers running Windows Server 2008 from a Windows Deployment Services server running Windows Server 2008. For more information, see Managing a Complex Environment.
Creating Custom Install Images
When using Image Capture Wizard to create a custom image, the volume that contains my image is not selectable.
There are two common reasons for this problem:
- Cause 1: The boot image does not contain
the proper drivers for the computer’s hard disk drive
controller. To troubleshoot this, when the Image Capture Wizard
first starts, press SHIFT+F10 to open a command prompt. Run
Diskpart, and then run lis disk. Select each disk
(for example, sel dis 0 and sel dis 1), and then type
lis vol to list each volume. Ensure that the volume that
contains the offline Sysprep image is viewable. If it is not, you
need to add the driver for your mass-storage controller to Windows
PE so that it can detect the local disk that contains the offline
Sysprep image. To do this, use one of the following procedures:
To inject drivers into a boot image, and use the boot image to create a capture image:
Add a boot image to your server.
Mark the image as offline (disabled).
Mount the image by using ImageX and Mountrw (included in the Windows AIK).
Insert all of the drivers that use PEIMG.exe into the boot image.
Mark the image as online (enabled).
Create the capture image using this boot image.
To load the driver yourself in Windows PE:
Boot into the capture image.
Press SHIFT+F10 to access a command prompt.
Use Drvload.exe to load the driver.
Confirm that you have access to the local disk that contains the offline image.
Press ALT+TAB to return to the capture wizard and continue the process.
- Cause 2: The volume does not contain an
image that was prepared using Sysprep.
To determine whether the offline image has been prepared using Sysprep:
Run regedit to load the offline system hive.
In HKEY_LOCAL_MACHINE\System, create a new key called Test.
Import the offline system hive from C:\windows\system32\config\system (assuming the offline operating system is located on C:\) into the empty Test key.
Examine the two registry keys in the imported system hive that are checked by the wizard:
- Ensure that
- Ensure that
HKEY_LOCAL_MACHINE\System\Setup\SystemSetupInProgress is set
- Ensure that HKEY_LOCAL_MACHINE\System\Setup\CloneTag exists
- The Generalize check box was not
selected when Sysprep was run.
- After Sysprep completed, the computer was
specialized before the Image Capture Wizard was started. This can
happen if you installed Windows Vista, ran Sysprep, rebooted
the computer, and then failed to signal the PXE boot in time so
that the computer starts to boot and the specialization process
runs. You realized your mistake, restarted the computer, and
signaled the PXE boot. Then you booted into Windows PE and start
the image capture wizard. In this scenario, the wizard will not
show the volume because the offline image is no longer
The finish button is not enabled on the final page of the image capture wizard.
This occurs when a name and location for the .wim file is not specified. You must specify this information even if you are uploading the resulting image to a Windows Deployment Services server. The Image Capture Wizard creates a local copy of the image first, to ensure that transient networking conditions will not interfere with the image capture process.
You can specify a location for the .wim file that is on the same volume that is being captured (this will not interfere with the capture process). By default, this local image is not deleted at the conclusion of the image capture process. To delete the file, specify the appropriate unattended installation setting. For more information, see Automating the Image Capture Wizard.
My multicast transmissions are running very slowly.
One typical cause of this issue occurs in environments that contain computers with different hardware configurations and architectures. In this case, some clients can run multicast transmissions faster than others. Because each transmission can be run only as fast as the slowest client, the entire transmission will be slow if there is one slow client. To resolve this issue, first determine the client that is holding back the transmission (this is called the master client). To do this, view the output of the following command: WDSUTIL /Get-AllMulticastTransmissions /Show:Clients. Next, disconnect the master client using WDSUTIL /disconnect-client /ID:<ID>, where ID is the client ID (which you can get using the /get-transmission option).
Disconnecting the master client will force it to run the transmission by using the Server Message Block (SMB) protocol, and the other clients' multicast performance should speed up. If they do not speed up, there is a problem with the client's hardware (for example, a slow hard drive) or a network problem. Also, see Example Multicast Scripts for an example script that will automatically disconnect slow master clients.
After enabling multicasting, there is excessive traffic on the network.
One common cause of this is if Internet Group Membership Protocol (IGMP) snooping is not enabled on all devices. IGMP snooping enables your network hardware to forward multicast packets only to those devices that are requesting data. If IGMP snooping is turned off, multicast packets are treated as broadcast packets, and will be sent to every device in the subnet. In cases where you cannot enable IGMP snooping, you can adjust the multicast packet time-to-live (TTL), which is 32 by default. You can change this by modifying the registry key of the network profile at:
32 is sufficient for most network topologies, but if your environment does not support snooping, you can use this setting to somewhat mitigate that.