Bijgewerkt: mei 2008
Van toepassing op: Windows Server 2008
This chapter highlights some common issues that you may encounter when using Windows Deployment Services including the following:
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 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 Gebruikte netwerkpoorten.
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, Clientcomputers beheren.
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 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 settings associated with this configuration have not been defined. To configure this, see the DHCP section of Uw server beheren.
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, upload the Boot.wim file located in the Sources directory of Windows Server 2008 or Windows Server 2008 R2 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 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 (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 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.
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, you can either add the driver to the image, or 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.
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 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 Vereiste machtigingen.
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>. For more information, see Vereiste machtigingen.
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.
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-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.
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 network 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 network boot files. 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 Vereiste machtigingen.
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.
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.
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.
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.
- 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 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.
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 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.