Share via

How Domain Controllers and Global Catalogs Work

  • Article

Applies To: Windows Server 2008

In This Topic

  • How Joining a Computer to a Domain Works

  • How Domain Controllers and Global Catalogs Are Used

  • How BINLSVC Communicates with Domain Controllers

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.

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

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

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

  4. BINLSVC resets the client computer account in AD DS. For nonprestaged computers, this is the computer account created in step 3.

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

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() (https://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 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.