In This Topic
How Joining a Computer to a Domain Works
The Windows Deployment Services Pre-Boot Execution Environment (PXE) provider is named BINLSVC. BINLSVC is in charge of communicating with Active Directory. When joining a computer to a domain, BINLSVC performs the following sequence of steps.
- BINLSVC determines that it needs to perform a domain join. For
nonprestaged accounts, the client receives the domain join policy
setting for unknown accounts. For prestaged accounts, the client
receives the value of the JoinDomain registry setting as
configured by /JoinDomain command line option.
- The credentials of the user are entered into the credentials
page, either manually or by using an unattend file. Note that the
remaining steps in this sequence are performed in this user’s
context.
- For nonprestaged accounts, BINLSVC creates a computer object in
Active Directory Domain Services (AD DS), using the settings
from the server (such as the computer naming policy or what
organizational unit (OU) to create the computer account in).
- BINLSVC resets the client computer account in AD DS. For
nonprestaged computers, this is the computer account created in
step 3.
- BINLSVC looks for an image unattend file.
- If the image unattend file exists (and is in
the correct format), the information that is required to perform
the domain join (the computer name, the domain, and the computer
password (for Windows Vista images)) is inserted into the
image unattend file.
- If an image unattend file does not exist, the
template unattend file for the image type is used. The information
required to perform the domain join (the computer name, the domain,
and computer password (for Windows Vista images)) is inserted
into the template unattend file.
- If the image unattend file exists (and is in
the correct format), the information that is required to perform
the domain join (the computer name, the domain, and the computer
password (for Windows Vista images)) is inserted into the
image unattend file.
How Domain Controllers and Global Catalogs Are Used
AD DS topologies are generally organized by domain and by site. A domain is a collection of user objects, computer objects, and other objects. These objects share a common directory database, security policies, and security relationships with other domains. Objects within a domain are only writeable on domain controllers for that domain. A site consists of one or more TCP/IP subnets. The site enables you to configure AD DS access and replication topology to take advantage of the network topology.
The following rules apply to how BINLSVC uses AD DS:
- BINLSVC prefers to use domain controllers
and global catalogs that are available within the same AD DS
site as the PXE server. If local domain controllers and global
catalogs are not available, BINLSVC uses those that are outside of
the local site (preferring those that are available with the lowest
site cost).
- BINLSVC searches the global catalog for
attributes, including netbootGUID and netbootMachineFilePath.
Using a global catalog greatly reduces search times and avoids
unnecessary Lightweight Directory Access Protocol (LDAP)
referrals.
- BINLSVC queries a writeable domain
controller for the domain where the Windows Deployment Services PXE
server resides. . It queries for the following attributes:
netbootAnswerOnlyValidClients, netbootAnswerRequests,
netbootMaxClients, netbootSCPBL, netbootServer
- BINLSVC uses the DSGetDcName() API. It
passes the DS_GC_SERVER_REQUIRED flag whenever it needs to locate a
global catalog. For more information, see DSGetDcName() (http://go.microsoft.com/fwlink/?LinkId=81494).
- BINLSVC searches global catalogs before
searching domain controllers when attempting to locate computer
account objects. By doing this, a single search against
AD DS can find a prestaged computer. If you do not have a
local global catalog, you should have BINLSVC use a local domain
controller rather than connect across a wide area network (WAN) to
a global catalog.
How BINLSVC Communicates with Domain Controllers
In some situations, the Windows Deployment Services server must create computer objects on behalf of the user. To do this, BINLSVC binds to a domain controller from where the computer account is created. For example, if there is a company named Datum Corporation with two domains in a forest — adatum.com and sub.adatum.com — and BINLSVC needs to create a computer account in sub.adatum.com, it will use a domain controller from sub.adatum.com. BINLSVC communicates directly with domain controllers in the following circumstances:
- When using the Auto-Add devices policy to add
computer accounts to AD DS.
- When creating computer objects on behalf of
users.
- When querying for the attributes listed
earlier in this topic that are not part of the partial attribute
set.