Common Problems

Updated: May 24, 2013

Applies To: Windows Server 2008, Windows Server 2008 R2

This chapter highlights some common issues that you may encounter when using Windows Deployment Services including the following:


Type Issues

Performing Network Boots on Client Computers

  • I am unable to perform network boots on client computers.

  • When I perform a network boot and select a boot image, I see a command prompt.

  • The client computer fails to get an IP address when I try to network boot.

  • The client computer obtains an IP address but then fails to download a network boot program.

  • My computer loads the boot image, but it cannot access an install image.

  • Install images do not appear on the image selection page.

  • My x64-based client computer does not have any x64-based images on the boot image selection page.

  • I received an error dialog saying "Windows could not update registry data in the installation." when deploying Windows Vista.

  • (Windows Server 2008 R2 only) When I network boot my EFI machine, I see a black screen or a trap error.

  • (Windows Server 2008 R2 only) For an EFI computer, I configured bootmgfw.efi and a referral server and the network boot failed.

Performing Management Operations

  • I can't approve a pending computer.

  • 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.

  • When using the Image Capture Wizard to create a custom image, the volume that contains my image is not selectable.


  • My multicast transmissions are running very slowly.

  • After enabling multicasting, there is excessive traffic on the network.

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 product DVD to the server. For instructions, see the Windows Deployment Services Getting Started Guide.

  • 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 Used.

  • 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 /AnswerClients:all. For instructions, How to Manage Client Computers.

  • 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 Computers topic.

  • The computer is marked as rejected in the Auto-Add database. After a computer has been marked as rejected, it will not be able to network boot. You can clear the entry in the Auto-Add database by deleting all pending computer records by running WDSUTIL /delete-AutoAddDevices /DeviceType:RejectedDevices.

  • Client boot requests are not getting routed correctly to the Windows Deployment Services server. To ensure that the router is correctly configured, see "Methods of Directing a Client to the Appropriate Network Boot Program" in Managing Network Boot Programs.

  • DHCP and Windows Deployment Services are running on the same physical computer, but the server is not configured appropriately. To specify the correct settings for this configuration, see the DHCP section of How to Manage Your Server.

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 product DVD. To fix this, use the Boot.wim file located in the Sources directory of the Windows Server product DVD instead. This image contains the Windows Deployment Services client and Windows PE.

The most common causes of this problem are that there is a problem with the network, or with DHCP. To resolve these issues, check Event Viewer for events and errors, and then refer to the DHCP Infrastructure troubleshooting documentation ( for steps you can use to resolve the problem. If you are using a non-Microsoft DHCP server, contact the manufacturer for troubleshooting information.

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 network signal through the router. To fix this, see the "Configuring Your Router to Forward Broadcasts" section in Managing Network Boot Programs.

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.

The most common causes of this problem are:

  • The account whose credentials were entered on the credential screen does not have permissions to read the install.wim file on the server at \\<WDSServer>\RemoteInstall\Images\<Image Group>.

  • The architecture of the client computer (x86, Itanium, x64) does not match the architecture type of the install image.

  • For images released prior to Windows Vista, you may have an incompatible hardware abstraction layer (HAL) type. In this case, 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.

The system BIOS on many x64-based computers does not accurately identify the computer as x64-based during the boot process. If Windows Deployment Services does not recognize the computer as x64-based, only x86-based images will be shown. Run WDSUTIL /set-server /architecturediscovery:yes to force the Windows Deployment Services server to recognize x64-based computers.

The cause of this error is that you cannot install the initial release of Windows Vista (the version that does not have SP1 integrated into the operating system) using a newer boot image (for example, using a boot image from Windows Vista with SP1 or Windows 7). To workaround this issue, use the boot image that is included on the Windows Vista product DVD to deploy the initial release of Windows Vista.

The cause of this issue is that you have set your boot program to Wdsmgfw.efi. This is not supported because when you network boot an EFI computer, the Wdsmgfw.efi boot program is automatically downloaded prior to the boot program that an administrator specifies. If you specify Wdsmgfw.efi as your boot program, this will cause the computer to boot in an infinite loop. To correct this, either do not specify a boot program (to require a key press) or use Bootmgfw.efi (if you want the installation to continue without a key press).

For EFI computers, you cannot configure both 1) a referral server and 2) .n12 like behavior (where the computer does not require a key press). However, referral servers are supported when a key press is required (which is the default when no boot program is specified).

The two most common causes of this issue are the following:

  • You do not have the correct permissions in AD DS for the computer..

  • The computer name is not valid. For example, the name might be too long, or it might contain characters that are not valid.

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 database.

Failing to remove the record in the database will cause the client to fail because the Auto-Add database shows the computer as approved, but an account 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 until a prestaged computer appears in AD DS.

For more information, see Prestaging Client Computers.

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 list 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:

    1. Add a boot image to your server.

    2. Do one of the following:

      • Windows Server 2008: Mark the image as offline (disabled) and use the tools included in the Windows AIK to insert the necessary drivers to the image. Then mark the image as online (enabled).

      • Windows Server 2008 R2: In the Windows Deployment Services MMC snap-in, right-click the boot image, and click Add Driver Packages to Image.

    3. Create a capture image using this updated boot image.

    1. Boot into the capture image.

    2. Press SHIFT+F10 to access a command prompt.

    3. Use Drvload.exe to load the driver.

    4. Confirm that you have access to the local disk that contains the offline image.

    5. 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.

    1. Run regedit to load the offline system hive.

    2. In HKEY_LOCAL_MACHINE\System, create a new key called Test.

    3. 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.

    4. Examine the two registry keys in the imported system hive that are checked by the wizard:

      • Ensure that HKEY_LOCAL_MACHINE\System\Setup\CloneTag exists

      • Ensure that HKEY_LOCAL_MACHINE\System\Setup\SystemSetupInProgress is set to 1.

    If either registry key is not set correctly, there are two likely causes:

    • 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 ran Sysprep, rebooted the computer, and then failed to signal the network 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 network 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 generalized.

    To resolve either of these, boot into the image, run Sysprep again, and then perform the capture process again.

One typical cause of this 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.

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 computers that are requesting data. If IGMP snooping is turned off, multicast packets are treated as broadcast packets, and will be sent to every computer 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 one of the following registry keys:

Windows Server 2008: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multicast\Profiles\

Windows Server 2008 R2: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Protocol

32 is sufficient for most network topologies, but if your environment does not support snooping, you can use this setting to somewhat mitigate that.

Community Additions