Common Problems
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 |
|
Performing Management Operations |
|
Multicasting |
|
Performing Network Boots on Client Computers
I am unable to perform network 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 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.
When I perform a network 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 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 client computer fails to get an IP address when I try to network boot.
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 (https://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 network boot program.
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.
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.
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 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.
My x64-based client computer does not have any x64-based images on the boot image selection page.
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.
I received an error dialog saying "Windows could not update registry data in the installation." when deploying Windows Vista.
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.
(Windows Server 2008 R2 only) When I network boot my EFI machine, I see a black screen or a trap error.
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).
(Windows Server 2008 R2 only) For an EFI computer, I configured bootmgfw.efi and a referral server and the network boot failed.
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).
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..
The computer name is not valid. For example, the name might be too long, or it might contain characters that are not valid.
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 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 Wdsnbp.com until a prestaged computer appears in AD DS.
For more information, see Prestaging Client Computers.
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 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:
To inject drivers into a boot image, and use the boot image to create a capture image:
Add a boot image to your server.
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.
Create a capture image using this updated 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 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.
Multicasting
My multicast transmissions are running very slowly.
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.
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 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.