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
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.