Windows Deployment Services uses Active Directory Domain Services (AD DS) for a variety of reasons. AD DS is its data store, and it contains all of the necessary helper routines. You can prestage a device in AD DS, which means to link a physical computer to a computer account object. By doing this, you can configure properties on the computer account object to control the installation. 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.You can also link physical booting computers to computer account objects in AD DS. For more information, see Prestaging Client Computers.

In This Topic

Supported Environments

Windows Deployment Services supports AD DS environments that contain Windows Server 2000, Windows Server 2003, Windows Server 2008, or environments with any combination of these three operating systems. You will not gain any more 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 in such cases the following caveats apply:

  • A trust relationship must be established between the forest that contains the Windows Deployment Services server and other forests in that environment.

  • The server must be configured to answer all client requests. The server cannot answer only known clients in this configuration. This is because the AD DS search algorithm that is used by 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 Windows Deployment Services will 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 want to control replication latency. You may want to make changes to a particular computer object and have Windows Deployment Services immediately pick up the change (for example, if you modify netbootMachineFilePath to specify a different network boot program).

  • You 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 which domain controller and global catalog Windows Deployment Services will use rather than relying on the discovery algorithms.

  • You 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. For example, 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 stop servicing incoming client requests. This problem will persist (even if you restart Windows Deployment Services) until the domain controller is back online. This problem does not occur if you use the default dynamic discovery method.