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 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 /answerRequests: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, 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 Computers.
  
  
• 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 Managing Network Boot Programs.
  
  
• 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 different NBP.
  
  
• 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 DHCP.
  
  

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

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.

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.
  
  

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.

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 Automating the Domain Join and Sample Unattend Files.
  
  
• 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 Required Permissions.
  
  

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 \\<WDSServer>\RemoteInstall\Images\<Image Group>. For more information, see Required Permissions.
  
  
• 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 page.
  
  
• 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.
  
  

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.

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.

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

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.

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:

  1. Add a boot image to your server.

  2. Mark the image as offline (disabled).

  3. Mount the image by using ImageX and Mountrw (included in the Windows AIK).

  4. Insert all of the drivers that use PEIMG.exe into the boot image.

  5. Mark the image as online (enabled).

  6. Create the capture image using this boot image.

  To load the driver yourself in Windows PE:

  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.
  
  

  To determine whether the offline image has been 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 of the registry keys are 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 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 generalized.
    
    
  To resolve either of these, boot into the image, run Sysprep again, and then perform the capture process again.
  
  

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.

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.

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multicast\Profiles\

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