• Creating Computer Account Objects in AD DS
  
  
• Benefits
  
  
• Enabling the Auto-Add Policy
  
  
• Purging the Auto-Add Database
  
  

You can use Windows Deployment Services to link physical computers to computer account objects in Active Directory Domain Servers (AD DS). This is called prestaging the client. Prestaged clients are also called known computers. This allows you to then configure properties on the computer account to control the installation for the client. For example, you can configure the network boot program and the unattend file that the client should receive, as well as the server from which the client should download the network boot program. You can create a computer account object and associate it with a physical computer using the following methods:

• Using WDSUTIL. You can prestage client computers before they have attempted a network boot, by running WDSUTIL /Add-Device /Device:<name> /ID:<ID>. You cannot prestage computers by using the Windows Deployment Services MMC snap-in, but you can set the Auto-Add policy and approve or reject pending computers.
  
  
• Using the Active Directory Users and Computers snap-in. You can prestage client computers before they have attempted a network boot using AD DS. For instructions, see the section "To prestage a client computer" in How to Manage Client Computers.
  
  
• Enabling the Auto-Add policy. If you enable this policy, when you approve the installation for an unknown client, the installation will proceed and a computer account will be created in AD DS for the client. For more information, see Enabling the Auto-Add Policy
  
  
• Using Windows Deployment Services as part of the image installation. By default, all operating system installations using Windows Deployment Services result in a client computer that is joined to a domain. You can disable this functionality using the Client tab of the server’s properties page.
  
  

Prestaging clients provides three main benefits:

• An additional layer of security. You can configure Windows Deployment Services to answer only prestaged clients, therefore ensuring that clients that are not prestaged will not be able to boot from the network.
  
  
• Additional flexibility. Prestaging clients increases flexibility by enabling you to control the following:
  
  
  • The computer account name and location within AD DS.
    
    
  • Which Pre-Boot Execution Environment (PXE) server should service the client.
    
    
  • Which network boot program (NBP) the client should receive.
    
    
  • Other advanced options — for example, what boot image a client will receive or what Windows Deployment Services client unattend file the client should use.
    
    
• The ability for multiple PXE servers to service the same network segment. You can do this by restricting the server to answer only a particular set of clients. Note that the prestaged client must be in the same forest as the Windows Deployment Services server (trusted forests do not work).
  
  

When the Auto-Add policy is enabled, administrative approval is required before unknown clients (clients that are not prestaged) can install an image. To enable this policy, run WDSUTIL /Set-Server /AutoAddPolicy /Policy:AdminApproval. You can also enable it using the PXE Response settings tab of the server’s properties page.

If you enable this policy, when an unknown computer attempts to boot against the server, the computer will appear in the Pending Devices node of the MMC snap-in. The computer will remain in this pending queue until you approve or reject it, the time-out is reached, or the user cancels the attempt. If you approve the computer, the computer will continue booting from the network, and a computer account object will be created in AD DS to represent the physical computer. If you reject the computer, the network boot will abort, the computer will boot from the next item in the boot order, and a computer account will not be created. If you do not enable this policy, Windows Deployment Services will not create a computer account for unknown clients. It will, however, still answer clients according to the settings on the server.

The Auto-Add policy applies only when the Windows Deployment Services server is set to answer all clients, and Windows Deployment Services does not find a prestaged computer account for a booting computer. In all other cases, this policy will not be in effect. Also note that this policy does not pertain to computers that use Extensible Firmware Interface (EFI).

Note

If you are creating computer accounts against a non-English domain controller and you are using the default user property, you must set the Auto-Add settings to use a different account that does not contain extended characters. If the account contains a non-standard character (any character outside [A-Z, a-z, 0-9, \, -, and so on]), such as German's "Domänen-Admins", then Auto-Add will fail. To change this value, see the help at the command prompt for WDSUTIL /set-server /AutoAddSettings.

All computers in the pending queue are represented as an entry in the Auto-Add database. This temporary storage location serves three purposes:

• To provide the management utilities with a list of all pending computers on a server.
  
  
• To serve as an audit trail by recording what computers have been approved or rejected.
  
  
• To reduce the size of AD DS and keep old computer account objects out of the AD DS.
  
  

Records in the database are purged either manually or on a schedule. The default schedule purges unapproved and rejected computers from the database every 24 hours. If a computer was accidentally rejected, you can remove the computer by using one of the following methods:

• Wait for the default cleanup to occur, and then boot the computer again.
  
  
• Purge records from the pending table by running the command WDSUTIL /Delete-AutoAddDevices /DeviceType:<ApprovedDevices|RejectedDevices>.
  
  

By default, computers with an approved status will be deleted every 30 days. In addition, to delete a prestaged computer that was added to AD DS by using the approval process, you must perform two steps. First, you must delete the computer from AD DS. Second, you must delete the computer's record in the Auto-Add database. Failing to purge the database will cause the client to be stuck in Wdsnbp.com and 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 never be found (because the computer was deleted). In this situation, the server will hold the client at Wdsnbp.com until a prestaged computer appears in AD DS.

To reset the Auto-Add database completely

1. Stop the WDSServer service (run WDSUTIL /stop-server).

2. Create a Temporary folder in the \RemoteInstall\Mgmt folder.

3. Move all existing files in the Mgmt folder to the Temporary folder.

4. Restart the WDSServer service (run WDSUTIL /start-server).