Configuring AD DS Integration

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

Using WDSUTIL, you can prestage a computer in Active Directory Domain Services (AD DS), which means to link a physical computer to a computer account object. This allows you to configure properties on the computer account object to control the installation for a 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 boot files. For instructions, see the “Prestage Computers” section in the How to Manage Client Computers topic. For more information about prestaging clients, see Prestaging Client Computers.

In This Topic

  • Supported Environments

  • Configuring Static Domain Controllers and Global Catalog Servers

Supported Environments

Windows Deployment Services supports AD DS environments that contain Windows Server 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, or environments with any combination of these operating systems. You will not gain functionality or features in Windows Deployment Services features by switching to a higher forest functional level. Windows Deployment Services works well in both single-domain and multidomain environments. Windows Deployment Services also works in multiforest environments, but the following caveats apply:

  • You must establish a trust relationship between the forest that contains the Windows Deployment Services server and other forests in the environment.

  • You cannot configure the Windows Deployment Services server to answer only prestaged clients in this configuration. This is because Windows Deployment Services will only be able to locate prestaged computer objects in the same AD DS forest as the Windows Deployment Services server. This also means that all computer account objects that are created by Windows Deployment Services will be created in the forest that contains the Windows Deployment Services server.

Configuring Static Domain Controllers and Global Catalog Servers

In some circumstances, you may want to define the domain controller and global catalog server for Windows Deployment Services to use. You can do this on the Advanced tab of the server’s properties (right-click the server in the MMC snap-in, and click Properties). For example, you may want to this if you:

  • Want to control replication latency. If you make a change to a particular computer object (for example, if you run WDSUTIL /Set-Device /Device:<name> /ReferralServer:<ServerName>), you may want Windows Deployment Services to immediately pick up the change.

  • Do not have a domain controller and global catalog in the same AD DS site as Windows Deployment Services. This configuration is not recommended. However, in this case you may want to control the domain controller and global catalog for Windows Deployment Services to use rather than relying on the default behavior.

  • Need to troubleshoot an issue. For example, if Windows Deployment Services is having problems accessing AD DS, you can use this setting to try to isolate the problem to a specific domain controller or global catalog.

The one notable downside to mapping these servers statically occurs when a domain controller or global catalog fails. If you statically map Windows Deployment Services to use a domain controller, and that domain controller is taken offline, Windows Deployment Services will lose access to the domain controller’s services and will stop servicing client requests. This problem will persist (even if you restart Windows Deployment Services) until the domain controller is back online.