Domain controllers are servers that host an Active Directory domain and provide authentication and directory services to clients. A domain controller (DC) can only be authoritative (i.e., it can only process authentication requests) for a single domain, but it can store partial read-only copies of objects in other domains in the forest if it is enabled as a global catalog server. All domain controllers in a forest also host a copy of the Configuration and Schema naming contexts (NCs), which are replicated to all domain controllers in a forest.
Active Directory domain controllers are fully multimaster in nature, meaning that updates to the directory (with a few exceptions, which we’ll discuss next) can originate on any domain controller in a forest. However, some tasks are sufficiently sensitive in nature that they cannot be distributed to all DCs, due to the potential of significant issues arising from more than one DC performing the same update simultaneously. For example, if two different domain controllers made conflicting updates to the schema, the impact could be severe and could result in data loss or an unusable directory. For this reason, Active Directory uses Flexible Single Master Operation (FSMO, pronounced “fiz-mo”) roles. For each FSMO role, only one domain controller acts as the role owner and performs the tasks associated with the role. These roles are termed “single master” because only a single DC can hold a FSMO role at any one time, but they are “flexible” because a single physical server can host multiple FSMOs, and a FSMO role can be transferred from one DC to another, largely without repercussion. In each Active Directory forest there are two FSMO roles that are unique across an entire forest and three FSMO roles that appear within each domain. So, in the case of a forest containing three domains, there would be two forest-wide FSMO role holders and nine domain-wide FSMO role holders, three for each of the three domains. See Finding the FSMO Role Holders for more information on FSMO roles.
In Windows Server 2008, Microsoft introduced the Read-Only Domain Controller, or RODC, to improve security for organizations that need to deploy DCs in branch offices or other remote locations where the physical or logical security of the DC might not be completely assured. An RODC will receive replication updates from writable DCs in the same domain, but domain controllers will not replicate from an RODC. See Promoting a Server to a Read-Only Domain Controller for more information on RODCs.
Each domain controller is represented in Active Directory by
several objects; the two main ones are a computer object and an nTDSDSA object. The computer object is necessary because a domain
controller needs to be represented as a security principal just like any
other type of computer in Active Directory. The default location in a
domain for domain controller computer
objects is the Domain Controllers
organizational unit (OU) at the root of the domain. They can be moved to
a different OU, but it is highly recommended that you don’t move them.
One of the reasons not to move them is because any DCs that you move
outside the domain controller’s OU will not receive the same Group
Policy Object settings as those within the OU, which can lead to
unpredictable behavior on your network. Table 3-1 contains some
useful attributes of domain controller computer objects.
Table 3-1. Attributes of domain controller computer objects
Attribute | Description |
|---|---|
| Fully qualified DNS name of the DC. |
| Contains the old DNS name of a renamed DC. |
| Contains the old NetBIOS name of a renamed DC. |
| Text description of the operating system running on the DC. |
| Service pack version installed on the DC. |
| Numeric version of the operating system installed on the DC. |
| NetBIOS-style name of the DC. |
| DN of the DC’s |
| List of SPNs supported by the DC. |
Domain controllers are also represented by
several objects under the Sites
container in the Configuration NC. The Sites container stores objects that are needed
to create a site topology, including site, subnet, sitelink, and server objects. The site topology is necessary
so that domain controllers can replicate data efficiently around the
network as well as localize authentication traffic. See Chapter 11 for more information on sites and
replication.
Each domain controller has an nTDSDSA object that is subordinate to the
domain controller’s server object in
the site it is a member of. For example, if the DC1 domain controller
were part of the RTP site, its nTDSDSA object would be located here:
cn=NTDS Settings,cn=DC1,cn=RTP,cn=sites,cn=configuration,dc=adatum,dc=com
Table 3-2 lists
some of the interesting attributes that are stored with nTDSDSA objects.
Table 3-2. Attributes of domain controller nTDSDSA objects
Attribute | Description |
|---|---|
| List of DNs for the naming contexts the DC is authoritative for. This does not include application partitions. |
| List of DNs for the naming contexts the DC has a partial read-only copy of. |
| The DN of the domain the DC is authoritative for. |
| List of DNs for the naming contexts (domain, configuration, and schema) and application partitions the DC is authoritative for. |
| If the low-order bit of this attribute is set, the domain controller stores a copy of the global catalog. |
| GUID that is assigned to
the Active Directory database itself when the first domain
controller is initially installed. When the first DC is
initially installed, the |
RODCs also maintain a number of RODC-specific attributes, primarily relating to the Password Replication Policy (PRP) that is configured for each RODC in an Active Directory forest. As discussed previously, writable DCs will store an entire copy of the Domain NC on the hard drive of each DC, which creates a significant liability if the physical or logical security of one of these DCs is compromised. By contrast, an RODC will store most information from the Domain NC, but by default will not store passwords and other security secrets for any Active Directory user account. (A default RODC will contain only secrets for the local Administrator and the local krbtgt accounts, both of which are required for the RODC to function.) An Active Directory administrator can configure a Password Replication Policy for a single RODC or for all RODCs in a domain that will specify the following:
Users and computers whose password secrets are permitted to be cached on individual RODCs or on all RODCs in a domain
Users and computers whose password secrets are never permitted to be cached on individual RODCs, or on all RODCs in a domain
In order to maintain this information, each RODC contains a number of attributes relating to the Password Replication Policy. Each RODC will also maintain information pertaining to which user and computer accounts’ password secrets have actually been cached by a particular RODC, instead of merely being permitted to do so.
Table 3-3 lists
some of the interesting attributes pertaining to Password Replication
Policy that are stored within an RODC’s computer object.
Table 3-3. Interesting attributes of a Read-Only Domain Controller
Attribute | Description |
|---|---|
| Accounts that are allowed to be cached on the RODC. |
| Accounts that are not allowed to be cached on the RODC. |
| A forward link indicating a list of RODCs through which a user has successfully authenticated to a full DC. |
| A backlink indicating a list of accounts that have successfully authenticated to a full DC through the RODC. |
You want to promote a server to a domain controller. You may need to promote a server to a domain controller to initially create a domain in an Active Directory forest, or to add additional domain controllers to a domain for load balancing and fault tolerance.
The following process will promote a server as an additional domain controller in an existing domain. On a Windows Server 2012 computer:
Add the Active Directory Domain Services role. After the role installation, a notification will appear within Server Manager.
Click Notifications and then click “Promote this server to a domain controller.”
Select the “Add a domain controller to an existing domain” option. Specify the desired domain and credentials (or accept the default values if appropriate) and then click Next.
Select the desired domain controller options: “Domain Name System (DNS) server,” “Global Catalog (GC),” and/or “Read only domain controller (RODC).”
Type a Directory Services Restore Mode (DSRM) password and then click Next.
Select the desired additional options: install from media—if installing from media—and replication from a specific domain controller. Then click Next.
Specify the desired database, logfiles, and SYSVOL paths and then click Next.
Review all of the options and then click Next.
After a successful prerequisite check, click Install to complete the promotion. Note that the server will automatically reboot after completing the promotion process.
Promoting a server to a domain controller is the process where the server becomes authoritative for an Active Directory domain. When you initiate the promotion, a wizard interface walks you through a series of screens that collect information about the forest and domain into which to promote the server. There are several options for promoting a server to domain controller status:
Promoting into a new forest (see Creating a Forest)
Promoting into a new domain tree or child domain (see Creating a Domain)
Promoting into an existing domain
A server can also be promoted by using PowerShell. See the following section for links to some recipes with PowerShell steps for domain controller promotion.
Creating a Forest for creating a new forest; Creating a Domain for creating a new domain; Promoting a Server to a Read-Only Domain Controller; Automating the Promotion or Demotion of a Domain Controller
You want to promote a server to an RODC in a Windows Server 2012 domain.
Note
This recipe requires that at least one writable Windows Server 2008 or newer domain controller is present in the domain.
First, add the Active Directory Domain Services role using Server Manager.
Click “Promote this server to a domain controller” in the notification area.
Verify that the “Add a domain controller to an existing domain” option is selected.
Type the domain name and domain credentials and then click Next.
Select the “Read only domain controller (RODC)” option, enter the Directory Services Restore Mode (DSRM) password, and then click Next.
Select a user account for delegation. Verify the accounts that are allowed to replicate passwords and the accounts that are denied from replicating passwords. Click Next.
Select a domain controller to replicate from and then click Next.
Verify the AD DS database locations and then click Next.
Review the summary and then click Next.
After the prerequisites have been verified, click Install to begin the promotion.
The server will automatically restart after replication is complete.
In order to add a Read-Only Domain Controller to an Active Directory domain, the domain must be running at the Windows Server 2003 or later domain functional mode, and at least one writable Windows Server 2008 or later domain controller must be available, since an RODC will only accept replication traffic from a 2008 or later writable DC.
To further customize the behavior of an RODC installation, you can select the Advanced installation option, which will allow you to install an RODC using IFM media, as well as customizing the Password Replication Policy. You can also automate RODC installation by using an unattend.txt file as described in a later recipe.
You can also use the Install-ADDSDomainController PowerShell cmdlet
to promote a server as an RODC.
You want to perform a two-stage promotion of a server to an RODC in a Windows Server 2012 domain.
Note
This recipe requires that at least one writable Windows Server 2008 or later domain controller is present in the domain.
The first stage of the two-stage installation process is performed from a writable Windows Server 2012 domain controller, using the following steps.
Note
The server designated for configuration as an RODC must be joined to a workgroup prior to the start of this process; if the computer is joined to the domain as a member server, these steps will fail. The server must also be configured with the same name that you will specify in the following steps.
From Active Directory Users and Computers, right-click the
Domain ControllersOU and then click “Pre-create Read only Domain Controller account.”When the Active Directory Domain Services Installation Wizard appears, click Next to begin.
Specify the account credentials or accept the default settings by using the currently logged on user credentials, and then click Next.
Enter the desired computer name of the RODC and then click Next.
Select the site location for the RODC and then click Next.
Select the additional options for DNS server and global catalog services and then click Next.
Add the user or group that will have local administrative rights to the RODC and then click Next.
Review the selections on the summary screen and then click Next.
After the successful installation of the RODC, click Finish to close the wizard.
The second stage of the RODC installation will be completed from the console of the server that is to be configured as an RODC, using the following steps:
Click “Promote this server to a domain controller” in the Server Manager notification area and then click Next.
Enter the parent domain name and credentials and click Next.
Verify that the “Use existing RODC account” option is selected. Enter a password for DSRM and then click Next.
Specify a DC to replicate from and then click Next.
Specify the locations for the database, logfiles, and SYSVOL, and then click Next.
Review the options and then click Next.
After the prerequisites have been successfully checked, click Install to begin promotion.
The server will automatically reboot after completion.
When deploying RODCs to remote locations, you have the ability to perform a two-stage installation in which you pre-create the RODC’s domain controller account. Once this first stage is completed, an on-site administrator can complete the installation without requiring elevated rights within Active Directory. This Admin Role Separation feature allows you to configure one or more users or groups as local administrators of an individual RODC, without granting administrative privileges within the Active Directory domain itself.
When pre-creating the RODC computer account, you can select the Advanced installation option to customize the Password Replication Policy for the RODC prior to deployment.
Modifying the Password Replication Policy; Chapters 6 and 7 for more on managing users and groups
You wish to modify the Password Replication Policy on a Read-Only Domain Controller to control which user and computer passwords can and cannot be cached on a particular RODC.
Open Active Directory Users and Computers and then select the built-in
Domain ControllersOU.Locate the desired RODC, right-click it, and then click Properties.
Select the Password Replication Policy tab.
Click Add. Then click the “Allow passwords for the account to replicate to this RODC” option. Click OK.
Enter the user or group that you will cache passwords on the RODC and then click OK.
Click OK to complete the process.
To add a user or group to the “Allowed to Cache” list, use the following syntax:
repadmin /prp add <DomainControllerName> allow "<GroupName>"
To remove a user or group from the “Allowed to Cache” list, use the following syntax:
repadmin /prp delete <DomainControllerName> allow "<GroupName>"
To add a user or group to the “Denied to Cache” list, use the following syntax:
repadmin /prp add <DomainControllerName> deny "<GroupName>"
A separate Password Replication Policy can be maintained individually on each Read-Only Domain Controller; this is implemented by the addition of several attributes on each RODC that control which users’ passwords can and cannot be cached on the RODC in question. It is good practice to manage these attributes using security groups rather than individual users or computers, as this makes for a much more simplified management model. By default, the following domain groups are added to the Password Replication Policy of each RODC in the domain:
msDS-NeverRevealGroupAccount operators
Administrators
Backup operators
Denied RODC Password Replication Group
Server operators
msDS-RevealOnDemandGroupAllowed RODC Password Replication Group
When Windows evaluates the Password Replication Policy, a “Deny” setting would override an “Allow” setting; for example, if a user is a member of two security groups that are configured with contradictory settings. As with most aspects of Windows security, the “Keep It Simple” principle should be followed whenever possible.
You can modify the password caching policy on all RODCs in a single command by using an asterisk (*) in place of the RODC hostname. The asterisk is a wildcard character that represents any hostname. It can be combined with characters before or after. An example is using DC* to represent all RODCs that have a hostname starting with “DC.”
TechNet article on the repadmin command; Chapter 4 for more on searching
and updating Active Directory; Chapters 6 and 7 for more on managing users and
groups
Note
This recipe requires that the server being promoted is running Windows Server 2012.
You want to promote a server to be a new domain controller using a backup from another domain controller as the initial source of the Active Directory database instead of replicating the entire NTDS.DIT file and SYSVOL over the network.
From a DC, run the ntdsutil program.
From ntdsutil, run the following commands:
activate instance ntdsifmcreate sysvol full<PathToSaveData>
Copy the media from the saved located to the new server that will be promoted.
Add the Active Directory Domain Services role. After the role installation, a notification will appear within Server Manager.
Click Notifications and then click “Promote this server to a domain controller.”
Select the “Add a domain controller to an existing domain” option. Specify the desired domain and credentials (or accept the default values if appropriate) and then click Next.
Select the desired domain controller options: “Domain Name System (DNS) server,” “Global Catalog (GC),” and/or “Read only domain controller (RODC).” Note that a full backup is not necessary if you are planning to promote a server to an RODC (instead, you would use
create sysvol RODCrather thancreate sysvol full).Type a Directory Services Restore Mode (DSRM) password and then click Next.
Select the desired additional options, including the Install from Media option. Type the path to the IFM files and then specify the replication from a specific domain controller if desired. Then click Next.
Specify the desired database, logfiles, and SYSVOL paths and then click Next.
Review all of the options and then click Next.
After a successful prerequisite check, click Install to complete the promotion. Note that the server will automatically reboot after completing the promotion process.
The ability to promote a domain controller using the System State backup of another domain controller was first introduced in Windows Server 2003. Without the Install from Media option, a new domain controller has to replicate the entire NTDS.DIT Active Directory database file and SYSVOL folder over a network connection, object by object, from an existing domain controller. For organizations with a sizeable Active Directory DIT file and/or very poor network connectivity to a remote site, replicating the full contents over the network presented challenges. Under these conditions, the promotion process could take a prohibitively long time to complete. With the Install from Media option, the initial domain controller promotion process can be substantially quicker. After you’ve done the initial installation from media, the new domain controller will replicate any changes that have been made to the Active Directory database since the backup media was created.
Note
Be sure that the age of the backup files you are using is significantly less than your AD forest’s tombstone lifetime. If you install a domain controller using backup files that are older than the tombstone lifetime value, you could run into issues with deleted objects being reinjected into the Active Directory database after their tombstone lifetime has expired.
Chapter 16 for more on backing up Active Directory; Modifying the Tombstone Lifetime for a Domain for modifying the tombstone lifetime of a domain; MS KB 216993 (Useful Shelf Life of a System-State Backup of Active Directory)
In Server Manager, click the Manage menu and then click Remove Roles and Features.
Click Next on the “Before you begin” page, if applicable.
Select the destination server that you want to demote and then click Next.
Deselect the Active Directory Domain Services role. In the corresponding pop-up dialog box, click Remove Features to also remove the management tools.
A validation process will display an error indicating that the domain controller must be demoted before the Active Directory Domain Services role can be removed. Click “Demote this domain controller” in the validation box.
Specify credentials to perform the operation or accept the default of the currently logged on user, and then click Next.
Click to select the “Proceed with removal” option and then click Next.
If you want to retain the domain controller metadata, select the option to retain. Click Next.
Type in and confirm a new password for the local Administrator account. Click Next.
Review the options and then click Demote.
Before demoting a domain controller, you first need to ensure that all of the FSMO roles have been transferred to other servers; otherwise, they will be transferred to random domain controllers that may not be optimal for your installation. (Managing FSMO role holders is discussed in Finding the FSMO Role Holders.) Also, if the DC is a global catalog server or running a service such as DNS, WINS, DHCP, and so on, ensure that you have sufficient GCs and other infrastructure servers elsewhere in your forest that can handle the increased load.
It is important to demote a domain controller before decommissioning or rebuilding it so that its associated objects in Active Directory are removed, its SRV locator resource records are dynamically removed, and replication with the other domain controllers is not interrupted. If a domain controller does not successfully demote, or if you do not get the chance to demote it because of some type of hardware failure, see Removing a Domain for removing a domain from Active Directory and Demoting a Domain Controller for instructions on manually removing a domain controller from Active Directory.
Removing a Domain; Demoting a Domain Controller; Removing an Unsuccessfully Demoted Domain Controller for removing an unsuccessfully demoted domain controller; Enabling and Disabling the Global Catalog for disabling the global catalog; Finding the FSMO Role Holders; Transferring a FSMO Role for transferring FSMO roles
You can automate the promotion of a domain controller by using
PowerShell. Use the Install-ADDSDomainController cmdlet, as shown
in the following example:
Import-Module ADDSDeployment Install-ADDSDomainController↵ -CreateDNSDelegation↵ -Credential (Get-Credential)↵ -CriticalReplicationOnly:$false↵ -DatabasePath "D:NTDSDB"↵ -LogPath "E:NTDSLogs"↵ -DomainName "adatum.com"↵ -InstallDNS:$true↵ -SiteName "Default-First-Site-Name"↵ -SYSVOLPath "C:WindowsSYSVOL"↵ -Force:$true
You can automate the demotion of a domain controller by using the
Uninstall-ADDSDomainController
cmdlet. The cmdlet can be run locally, with the only requirement being
to enter a local administrator password, or it can be run against a
remote domain controller as noted in the following section.
The best sources of information about the status of promotion or demotion problems are the Dcpromo.log and Dcpromoui.log files contained in the %SystemRoot%Debug folder on the server. The Dcpromo.log file captures the input entered into dcpromo and logs the information that is displayed as dcpromo progresses. The Dcpromoui.log file is much more detailed and captures discrete actions that occur during dcpromo processing, including any user input. A sample dcpromoui.log file might look something like this:
dcpromoui 404.554 0000 11:09:01.479 opening log file↵ C:Windowsdebugdcpromoui.log dcpromoui 404.554 0001 11:09:01.479↵ C:Windowssystem32wsmprovhost.exe dcpromoui 404.554 0002 11:09:01.479↵ file timestamp 07/25/2012 20:08:53.059 dcpromoui 404.554 0003 11:09:01.479↵ C:Windowssystem32dcpromocmd.dll dcpromoui 404.554 0004 11:09:01.479↵ file timestamp 07/25/2012 20:05:25.050 dcpromoui 404.554 0005 11:09:01.479↵ local time 09/27/2012 11:09:01.479 dcpromoui 404.554 0006 11:09:01.480↵ running Windows NT 6.2 build 9200 (BuildLab:9200.win8_rtm.120725-1247) amd64↵ ... dcpromoui AD0.BD0 087D 20:03:51.337 exitCode = 55 dcpromoui AD0.BD0 087E 20:03:51.337 Enter State::UnbindFromReplicationPartnetDC dcpromoui AD0.BD0 087F 20:03:51.368 closing log
Additionally, dcdiag contains two tests that
can aid in troubleshooting promotion problems. The
dcpromo test reports anything it finds that could
impede the promotion process. The RegisterInDNS
test checks whether the server can register records in DNS. Here is an
example of running both commands to test against the
adatum.com domain (note that the /ReplicaDC parameter is specific to a scenario
where you want to add an additional domain controller to an existing
domain):
> dcdiag /test:dcpromo /DnsDomain:adatum.com /ReplicaDC /test:RegisterInDNS
In most cases, the level of detail provided by Dcpromoui.log should be sufficient to
pinpoint any problems, but you can increase logging if necessary. To
enable the highest level of logging available, set the following
registry value to FF0003: HKLMSoftwareMicrosoftWindowsCurrentVersionAdminDebug.
You can confirm that this mask took effect by running a promotion again,
checking Dcpromoui.log, and
searching for “logging mask.”
If dcdiag does not return sufficient information, the Network Monitor (netmon) program is very handy for getting a detailed understanding of the network traffic that is being generated and any errors that are being returned. Network Monitor is available as a free download from the Microsoft website. Using Network Monitor, you can identify what other servers a DC is communicating with or if it is timing out when attempting to perform certain queries or updates.
MS KB 221254 (Registry Settings for Event Detail in the Dcpromoui.log File); “Active Directory Diagnostic Logging”
You want to verify that a domain controller has been successfully promoted within an Active Directory domain.
Once you’ve installed a domain controller, there are several steps that you can take to ensure that the promotion process has completed successfully. Since Windows Server 2008, dcdiag.exe has been built directly into the AD DS binaries; netdiag.exe is no longer supported. Regardless of the version of the server operating system, dcdiag and netdiag can perform a number of diagnostic tests, including the following:
Verify that all necessary DNS records have been registered and are present on the DNS server.
Check the domain membership for the newly promoted computer.
Confirm that the new DC can communicate with other DCs in the domain.
Confirm that the new DC is replicating with other DCs.
Verify that the new DC can communicate with all of the FSMO role holders.
In addition, you can verify a successful domain controller promotion by verifying that it is responding on TCP ports 389 and 3268, running dcdiag /replsum, confirming that the SYSVOL directory has been shared, as well as checking the Directory Service log in the Event Viewer for any errors or warnings.
You want to manually remove a domain controller from Active Directory if the demotion process was unsuccessful or you are unable to bring a domain controller back online after a hardware or software failure.
Use the following steps to remove a domain controller:
If successful, a message will state that the removal was complete.
However, if you receive an error message, check to see if the
server’s nTDSDSA object
(e.g., cn=NTDSSettings,cn=DC5,cn=Servers,cn=MySite1,cn=Sites,cn=Configuration,dc=adatum,dc=com)
is present. If so, the demotion process may have already removed it, and
it will take time for the change to replicate. If it is still present,
try the ntdsutil procedure again, and if that
doesn’t work, manually remove that object and the parent object (e.g.,
cn=DC5) using ADSI Edit or another
tool. (Deleting Active Directory objects is discussed in Deleting an Object.)
Follow these additional steps to remove all traces of the domain controller:
Delete the CNAME record from DNS for
<GUID>._msdcs.<RootDomainDNSName>, where<GUID>is theobjectGUIDfor the server’snTDSDSAobject as obtained via ADSI Edit or a command-line tool such as AdFind. You’ll need to manually check and delete any associated SRV records. Delete any A and PTR records that exist for the server. When using Microsoft DNS, you can use the DNS MMC snap-in to accomplish these tasks.Delete the computer object for the server under
ou=DomainControllers,<DomainDN>. This can be done using the Active Directory Users and Computers snap-in or PowerShell. (Deleting objects is described in Chapter 4.)Delete the FRS Member object for the computer contained under
cn=DomainSystemVolume (SYSVOL share),cn=file replication service,cn=system,<DomainDN>. This can be done using the Active Directory Users and Computers snap-in when Advanced Features has been selected from the View menu (so theSystemcontainer will be displayed), or with the AdMod tool.Delete the server object associated with the failed domain controller in the Active Directory Sites and Services MMC.
If the domain controller that you are forcibly removing from Active Directory is the last one in an Active Directory domain, you’ll need to manually remove the domain from the forest as well. See Removing an Orphaned Domain for more information on removing orphaned domains.
Here are some additional issues to consider when you forcibly remove a domain controller:
Seize any FSMO roles the DC may have had to another domain controller. (Managing FSMO roles is discussed later in this chapter.)
If the DC was a global catalog server, ensure there is another global catalog server configured in the site that can handle the increased workload.
If the DC was a DNS server, ensure that there is another DNS server that can handle the additional name resolution queries, and be sure that your clients are configured to use the correct name server.
If the DC was the RID FSMO master, check to make sure duplicate SIDs have not been issued (see Finding Duplicate SIDs in a Domain).
Check to see if the DC hosted any application partitions, and if so, consider making another server a replica server for those application partitions (see Performing an Authoritative Restore of an Object or Subtree).
If the (former) domain controller that you forcibly removed is still active or otherwise returns to your network, you should strongly consider reinstalling the operating system to avoid potential conflicts from the server trying to reinsert itself back into Active Directory.
Removing an Orphaned Domain for removing an orphaned domain; Finding Duplicate SIDs in a Domain; Seizing a FSMO Role for seizing FSMO roles; Deleting an Object; Performing an Authoritative Restore of an Object or Subtree
Your first step in renaming a domain controller is as follows,
where <NewName> is a fully qualified
domain name (FQDN):
> netdom computername<CurrentName>/Add:<NewName>
The new name will be automatically replicated throughout Active Directory and DNS. Once you’ve verified that the new name has replicated (which may take some time depending on your replication topology), you can designate it as the domain controller’s primary name as follows, and then reboot the domain controller:
> netdom computername<CurrentName>/MakePrimary:<NewName>
Note
See Chapter 12 for information on verifying Active Directory replication.
Once you’re satisfied that your clients are accessing the domain controller using its new name, you can remove the old computer name using the following syntax:
> netdom computername<NewName>/remove:<OldName>
An option in the netdom utility allows an alternate computer name to be associated with a computer in Active Directory. Once you’ve added a new name, you can then set that name to be the primary name, thereby renaming the computer.
The old name effectively remains with the domain controller until
you remove it, which can be done using the netdom computername
/Remove:<Name> command. You
should reboot the server before removing the old name. The old names are
stored in the msDS-AdditionalDnsHostName and msDS-AdditionalSamAccountName attributes on
the domain controller’s computer
object.
If the domain controller has any version of Microsoft Exchange installed on it, renaming the domain controller is unsupported.
Open the Active Directory Users and Computers snap-in (dsa.msc).
Right-click on the target domain and select Find.
In the Find drop-down box, select Computers.
In the Role drop-down box, select Writable Domain Controllers or Read-Only Domain Controllers.
Click Find Now. The list of domain controllers for the domain will be present in the search results pane.
There are several ways to get a list of domain controllers for a domain. The GUI solution simply uses the built-in “Find” functionality of the Active Directory Users and Computers MMC. The PowerShell solution uses a dedicated cmdlet for getting information about domain controllers.
For yet another solution, see Finding Domain Controllers and Global Catalogs via DNS to find out how to query DNS to get the list of domain controllers for a domain.
Finding Domain Controllers and Global Catalogs via DNS for finding domain controllers via DNS
The following command finds the closest domain controller in the
specified domain (<DomainDNSName>);
that is, a domain controller that is located in the same site or in
the closest site if a local DC is not available. By default, it will
return the closest DC for the computer from which
nltest is being run, but you can optionally use
the /server option to target a
remote host. If you are interested in finding a DC within a particular
site regardless of whether it is the closest DC to you, you can also
optionally specify the /site option to find a domain
controller that belongs to a particular site:
> nltest/dsgetdc:<DomainDNSName>[/site:<SiteName>] [/server:<ClientName>]
The DC locator process defines how clients find the closest domain controller. The process uses the site topology stored in Active Directory to calculate the site a particular client is in. After the client site has been identified, it is a matter of finding a domain controller that is a member of that same site or that is covering for that site.
The Microsoft DsGetDcName
Directory Services API method implements the DC Locator process, but
unfortunately it cannot be used directly from a scripting language, such
as VBScript. The nltest /dsgetdc
command is also a wrapper around the DsGetDcName method, and it is a handy tool
when troubleshooting client issues related to finding an optimal domain
controller.
You can use nltest to return the closest
domain controller that is serving a particular function. Some of the
available functions include a global catalog server (/GC switch), time server (/TIMESERV switch), KDC (/KDC switch), and PDC (/PDC switch). Run nltest /? from a command line for the
complete list.
Domain controllers are represented in the site topology by a
server object and a child nTDSDSA object. Actually, any type of server
can conceivably have a server object;
it is the nTDSDSA object that
differentiates domain controllers from other types of servers. You’ll
often see the nTDSDSA object of a
domain controller used to refer to that domain controller elsewhere in
Active Directory. For example, the fSMORoleOwner attribute that represents the
FSMO owners contains the distinguished name of the nTDSDSA object of the domain controller that
is holding the role.
Finding a domain controller’s site using a GUI solution is time-consuming but can be accomplished by using LDP or Active Directory Sites and Services.
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand the site that contains the domain controller.
Expand the
Serverscontainer.Right-click on the domain controller you want to move and select Move.
In the Move Server box, select the site to which the domain controller will be moved and click OK.
When using DSMove, you must specify the DN of the object you
want to move. In this case, it needs to be the distinguished name of
the server object for the domain
controller. The value for the -newparent option is the distinguished name
of the Servers container you want
to move the domain controller to:
> dsmove "<ServerDN>" -newparent "<NewServersContainerDN>"
For example, the following command would move
dc2 from the Default-First-Site-Name site to the Raleigh
site:
> dsmove "cn=dc2,cn=servers,cn=Default-First-Site-Name,cn=sites,↵ cn=configuration,cn=adatum,dc=com" -newparent↵ "cn=servers,cn=Raleigh,cn=sites,cn=configuration,cn=adatum,dc=com"
You can also move an object using AdMod, as follows:
> admod -b cn=<ServerName>,cn=servers,cn=<OldSite>,cn=sites,↵ cn=configuration,<ForestRootDN>-move cn=servers,cn=<NewSite>,↵ cn=sites,cn=configuration,<ForestRootDN>
When you install a new domain controller, a server object and nTDSDSA object for the domain controller get
added to the site topology. The Knowledge Consistency Checker (KCC) and
Intersite Topology Generator (ISTG) use these objects to determine whom
the domain controller should replicate with.
A domain controller is assigned to the site that has been mapped
to the subnet it is located on. If there is no subnet object that has an address range that
contains the domain controller’s IP address, the server object is added to the Default-First-Site-Name site. If the domain
controller should be in a different site, you’ll then need to manually
move it. It is a good practice to ensure that a subnet object that matches the domain
controller’s subnet is already in Active Directory before promoting the
server into the forest. That way you do not need to worry about moving
it after the fact.
Note
When moving a server object,
remember that it has to be moved to a Servers container within a site, not
directly under the site itself.
In the solution provided, you need to know the current site of the domain controller you want to move. If you do not know the site it is currently in, you can use DSQuery to find it. In fact, you can use DSQuery in combination with DSMove in a single command line:
> for /F "usebackq" %i in ('dsquery server↵
-name"<DomainControllerName>"') do dsmove -newparent "cn=servers,↵
cn=Default-First-Site,cn=sites, cn=configuration,<ForestDN>" %iThis command is long, so we’ll break it up into three parts to
clarify it. The first part contains the for command extension that is built into the
cmd.exe shell. When the /F "usebackq" syntax is specified, it is
typically used to iterate over output from a command and perform
certain functions on the output.
for /F "usebackq" %i in
The next part of the for loop
contains the data to iterate over. In this case, we use DSQuery to
return the distinguished name of the server object for
dc2:
('dsquery server -name "<DomainControllerName>"')The last part executes a command for each result returned from DSQuery. In this case, there should only be one result, so this command will run only once:
do dsmove -newparent "cn=servers,cn=Default-First-↵
Site,cn=sites,cn=configuration,<ForestDN>" %iFinding a Domain Controller’s Site for finding a domain controller’s site; Moving an Object to a Different OU or Container for moving objects to different containers
The following command will display the list of services a domain controller is advertising:
> dcdiag /v /s:<DomainControllerName> /test:advertisingRunning this command on a typical domain controller will produce the following output:
Starting test: Advertising The DC dc1 is advertising itself as a DC and having a DS. The DC dc1 is advertising as an LDAP server The DC dc1 is advertising as having a writable directory The DC dc1 is advertising as a Key Distribution Center The DC dc1 is advertising as a time server The DS dc1 is advertising as a GC.
You can also use nltest to get similar information:
> nltest /server:<DomainControllerName>/dsgetdc:<DomainName>
Running this command on a domain controller in the adatum.com domain will produce the following output:
DC: \dc1.adatum.com
Address: \10.0.0.1
Dom Guid: ac0e4884-cf79-4c9d-8cd9-817e3bfdab54
Dom Name: adatum.com
Forest Name: adatum.com
Dc Site Name: Raleigh
Our Site Name: Raleigh
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN
DNS_FOREST CLOSE_SITENote
In the previous example, GTIMESERV denotes a DC that is a master time
server. WRITABLE denotes a DC that
holds a writable copy of the Active Directory database. Prior to
Windows Server 2008, only NT 4.0 BDCs would not possess this flag.
Since 2008, Read-Only Domain Controllers will also lack the WRITABLE flag.
The dcdiag /test:advertising
command is a wrapper around the DsGetDcName method. DsGetDcName returns a structure called
DOMAIN_CONTROLLER_INFO that contains
the list of services a domain controller provides. Table 3-4 contains the
possible values returned from this call.
Table 3-4. DOMAIN_CONTROLLER_INFO flags
Value | Description |
|---|---|
| Directory server for the domain. |
| Global catalog server for the forest. |
| Kerberos Key Distribution Center for the domain. |
| Primary domain controller of the domain. |
| Time server for the domain. |
| Hosts a writable directory service. |
The following solution requires that the Active Directory Recycle Bin feature has been enabled and that the feature was enabled prior to the deletion of the domain controller computer object.
Launch the Active Directory Administrative Center.
In the left pane, select the domain and then double-click the
Deleted Objectscontainer in the right pane.In the Filter box near the top of the Active Directory Administrative Center, enter the domain controller name to narrow down the displayed objects to the domain controller object.
Right-click the domain controller object and then click Restore.
This command-line solution uses a traditional restoration approach by performing an authoritative restore. To restore the computer account, use the following sequence of commands in Windows Server 2012:
> ntdsutil
> activate instance ntds
> authoritative restore> restore object <DomainControllerDN>
> quit
> exitRestart the domain controller after running these commands.
The PowerShell solution requires that the Active Directory Recycle Bin feature be enabled and that the feature was enabled prior to the deletion of the domain controller computer object. To restore the computer account for a domain controller named DC1, use the following PowerShell command:
Get-ADObject -Filter {Name -eq "dc1" -and ObjectClass -eq "computer"} -IncludeDeletedObjects | Restore-ADObjectThe Active Directory Recycle Bin has greatly simplified the restoration of AD objects. Now, deleted objects can be restored in their entirety without rebooting a domain controller or recovering data from backup media. In addition, the restore process is much faster, literally just minutes.
Without the use of the Active Directory Recycle Bin, when you restore a deleted object within Active Directory you have the option of performing an authoritative or a nonauthoritative restore. In both cases, any changes that have been made to the AD database subsequent to the time that the backup was taken will be replicated back to the restored DC. With an authoritative restore, the version number of the object(s) being restored is incremented so that the restored objects will “win” in the case of any replication collisions. In a case where you want to restore an object that has been inadvertently deleted, you need to perform an authoritative restore to prevent the deletion from repropagating to the restored domain controller. You can mark an entire restore as authoritative, or any subtree of your AD environment down to a single object (in this case, the computer object for the DC that was deleted).
The PowerShell solution uses two filters: one for Name and one for ObjectClass. Although filtering by just the
name will find and restore the object, it may also restore noncomputer
objects as well (e.g., an object in the msDFSR-Member object class will have the
same name). Instead of using two filters, you can also find the
specific object that you want to recover and then recover it directly
by specifying the object GUID.
Chapter 16 for more on recovering and restoring Active Directory
You want to uninstall and reinstall the TCP/IP stack on a domain controller as part of a disaster recovery or troubleshooting operation.
Resetting the TCP/IP stack using netsh will remove all configuration information, including the default gateway and any configured DNS and WINS servers. This procedure might be necessary during a disaster recovery situation where you’re restoring System State data to a server with a dissimilar hardware configuration, for example, as the restore process might corrupt the TCP/IP stack on the destination computer.
In addition to resetting the TCP/IP stack, you can also reset Winsock using the following command:
> netsh winsock reset
Use this command with care, though, as resetting Winsock can cause network applications such as antivirus scanners to malfunction and require reinstallation. A reboot is required to complete the Winsock reset.
To configure a domain controller to sync to an external time provider, set the following Registry keys:
[HKLMSystemCurrentControlSetServicesW32TimeParameters] Type: REG_SZ - "NTP" [HKLMSystemCurrentControlSetServicesW32TimeConfig] AnnounceFlags: REG_DWORD - 10 [HKLMSystemCurrentControlSetServicesW32TimeTimeProviders] NTPServer: REG_DWORD - 1 [HKLM SYSTEMCurrentControlSetServicesW32TimeParameters] NTPServer: REG_SZ -<Peers>[HKLM SYSTEMCurrentControlSetServicesW32TimeTimeProviders NtpClient] SpecialPollInterval: REG_DWORD -<TimeBetweenPollsInSeconds>[HKLM SYSTEMCurrentControlSetServicesW32TimeConfig] MaxPosPhaseCorrection: REG_DWORD -<MaximumForwardOffsetInSeconds>[HKLM SYSTEMCurrentControlSetServicesW32TimeConfig] MaxNegPhaseCorrection: REG_DWORD -<MaximumBackwardOffsetInSeconds>
Note
<Peers> in the preceding code
refers to a space-separated list of FQDNs of external time servers.
Each DNS name must be followed by ,0x1 for the rest of these settings to
take effect.
Once you have made these changes to the Registry, stop and restart the W32time service by issuing the following commands:
> net stop w32time > net start w32time
You should set a reliable time source on the PDC Emulator FSMO for
only the forest root domain. All other domain controllers sync their
time either from that server, from a PDC within their own domain, or
from a designated time server on another domain controller. The list of
external time servers is stored in the Registry under the W32Time
Service Registry key: HKLMSYSTEMCurrentControlSetServicesW32TimeParameters
tpserver.
If you want a domain controller such as the PDC to use an external
time source, you have to set the ntpserver Registry value along with the
type value. The default value for
type on a domain controller is
Nt5DS, which means that the domain
controller will use the Active Directory domain hierarchy to find a time
source. You can override this behavior and have a domain controller
contact a non-DC time source by setting type to NTP.
After setting the time server, the W32Time service should be restarted for the change to take effect. You can check that the server was set properly by running the following command:
> w32tm /query /computer:localhost /configuration
Since the PDC Emulator is the time source for the other domain controllers, you should also make sure that it is advertising the time service, which you can do with the following command:
> nltest /server:<DomainControllerName>/dsgetdc:<DomainDNSName>/TIMESERV
Note
To configure the PDC Emulator to use its own internal clock as a
time source instead of relying on an external clock, modify the
HKLMSYSTEMCurrentControlSetServicesW32TimeConfigAnnounceFlags
DWORD value to contain a value of 0x0A.
The algorithm used by domain controllers to sync time gets quite complex. See the next section for links to additional details on how the Windows time service works.
The following query returns the number of logon requests processed:
> nltest /server:<DomainControllerName> /LOGON_QUERYThis will produce output similar to the following:
Number of attempted logons: 10542526
The nltest /LOGON_QUERY command
is a wrapper around the I_NetLogonControl2 method, and it can be
useful to determine how many logon requests are being processed by a
server. Viewing the results of the command over a period of time and
comparing them against another DC in the same domain can also tell you
if one domain controller is being used significantly more or less than
the others.
You have installed more than 1 GB of memory on your 32-bit domain
controllers and want to enable the /3GB switch so that the LSASS process can use
more memory.
When computers are referred to as 32- or 64-bit computers, it
means they support memory addresses that are 32 or 64 bits long. This is
the total available memory (virtual and real) that can be processed by
the system. Since the days of Windows NT, Microsoft has split memory
allocation in half by giving applications up to 2 GB and the Windows
kernel 2 GB of memory to use (32 bits of address space = 2^32 = 4 GB).
In many cases, administrators would rather allocate more memory to
applications than to the kernel. For this reason, Microsoft developed
the /3GB switch to allow applications
running on 32-bit versions of Windows to use up to 3 GB of memory,
leaving the kernel with 1 GB.
Note
This configuration is not necessary for 64-bit versions of Windows.
Open the Active Directory Sites and Services snap-in (dssite.msc).
Browse to the
nTDSDSAobject (NTDS Settings) underneath theserverobject for the domain controller for which you want to enable or disable the global catalog.Right-click on
NTDS Settingsand select Properties.Under the General tab, check (to enable) or uncheck (to disable) the box beside Global Catalog.
Click OK.
In the following command,
<ServerObjectDN> should be the
server object DN, not the DN of the
nTDSDSA object:
> dsmod server "<ServerObjectDN>" -isgc yes|noFor example, the following command will enable the global catalog on DC1 in the Raleigh site:
> dsmod server "cn=DC1,cn=servers,cn=Raleigh,cn=sites,cn=configuration,dc=adatum,dc=com"↵ -isgc Yes
You can also use AdMod with the following syntax and output to
disable the GC; to enable it, use options::{{.:CLR:1}}:
> adfind -b "cn=NTDS
Settings,cn=dc1,cn=Servers,cn=Raleigh,cn=Sites,cn=Configuration,dc=adatum,dc=com" options -adcsv | admod options::{{.:SET:1}}Note
See Chapter 4 for information on safely modifying bitwise operators.
The first domain controller promoted into a forest is also made a global catalog (GC) server by default. In a single-domain environment, the global catalog server incurs no memory or bandwidth overhead beyond that of a domain controller, so you could configure each DC in a single-domain forest as a GC without any ill effects. In a multidomain environment, however, each global catalog server will require additional disk space to store a partial replica of other domains in the forest, and will require additional network bandwidth to replicate with other GCs. For more details on DC and GC placement planning, see Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).
The global catalog on a domain controller becomes enabled when the
low-order bit on the options
attribute on the nTDSDSA object under
the server object for the domain controller is set to 1; it becomes disabled when it is set to
0. The DN of this object for DC1 in
the Default-First-Site-Name site
looks like this:
cn=NTDSSettings,cn=DC1,cn=Default-First-Site-Name,cn=Sites,cn=Configuration,↵ dc=adatum,dc=com
After enabling the global catalog, it can take some time before
the domain controller can start serving as a global catalog server. The
length of time is based on the amount of data that needs to replicate
and the type of connectivity between the domain controller’s replication
partners. This is also dependent on the Global Catalog Partition
Occupancy setting, which is set in the HKLMSystemCurrentControlSetServicesNTDSParameters
key on the GC itself, which specifies how many directory partitions must
be fully replicated to the GC before it is considered ready; this can
range from no occupancy requirement whatsoever, to requiring that all
partitions be fully synchronized before the GC can begin servicing
requests. After replication is complete, you should see Event 1119 in
the Directory Services log stating the server is advertising itself as a
global catalog. At that point you should also be able to perform LDAP
queries against port 3268 on that server. See Determining Whether Global Catalog Promotion Is Complete for more information on
how to determine whether global catalog promotion is complete.
Determining Whether Global Catalog Promotion Is Complete for determining whether global catalog promotion is complete; “Understanding the Global Catalog”
You want to determine whether a domain controller is a global catalog server. After you initially enable the global catalog on a domain controller, it can take some time for all of the read-only naming contexts to replicate to it, depending on the number of domains, the volume of directory data, and the underlying network topology.
Query the isGlobalCatalogReady
attribute on the RootDSE for the domain controller. A TRUE value means the server is a global
catalog, and a FALSE value indicates
it is not.
For more information on how to query the RootDSE, see Viewing the RootDSE.
You can also check the Directory Services Event Log in the Event Viewer MMC for the presence of Event ID 1119, whose text reads as follows:
"This Windows Domain Controller is now a Global Catalog Server"
To confirm that a domain controller in the adatum.com domain named dc1 is functioning as a global catalog server, use nltest with the following syntax:
> nltest /server:dc1.adatum.com /dsgetdc:adatum.com
If the DC in question is functioning as a GC, you’ll see output similar to the following:
> C:>nltest /dsgetdc:adatum.com > DC: \dc1.adatum.com > Address: \10.0.0.1 > Dom Guid: ac0e4884-cf79-4c9d-8cd9-817e3bfdab54 > Dom Name: adatum.com > Forest Name: adatum.com > Dc Site Name: Raleigh > Our Site Name: Raleigh > Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN > DNS_FOREST CLOSE_SITE > The command completed successfully
Once a server has completed initial replication of the global
catalog, the attribute isGlobalCatalogReady in the RootDSE will be
set to TRUE. Another way to determine
if a domain controller has been at least flagged to become a global
catalog is by checking whether the options attribute on the nTDSDSA object for the server has been set to
1. (Note that this does not
necessarily mean the server is accepting requests as a global catalog.)
An additional query to the RootDSE as described in the Solution or directly to port 3268 (the global catalog
port) could also confirm that the appropriate flag has been
set.
Viewing the RootDSE for viewing the RootDSE
To find the global catalog servers in a forest, you need to query
for NTDS Settings objects that have
the low-order bit of the options
attribute equal to 1 under the
Sites container in the Configuration
naming context. That attribute determines whether a domain controller
should be a global catalog server, but it does not necessarily mean it
is a global catalog server yet. See Determining Whether Global Catalog Promotion Is Complete for more information on
how to tell whether a server marked as a global catalog is ready to
accept requests as one.
Determining Whether Global Catalog Promotion Is Complete for determining whether global catalog promotion is complete
In the left pane, double-click the domain name.
Double-click the Domain Controllers OU.
In the right pane, you can view the Domain Controller Type column to see if a domain controller is a global catalog server.
Global catalog servers will have the appropriate box checked beside Global Catalog.
To find all of the domain controllers in SiteA for the current domain, use the following syntax:
Get-ADDomainController -Filter { Site -eq "SiteA" } | FL NameTo find all GCs in SiteA for the current domain, use the following syntax:
Get-ADDomainController -Filter { Site -eq "SiteA" -and ( IsGlobalCatalog -eq "True" )} | FL NameTo find all global catalogs in SiteA in the entire forest, use the following syntax:
$for = [System.DirectoryServices.ActiveDirectory.Forest]::getCurrentForest()
$dom.FindAllGlobalCatalogs("SiteA")Each domain controller has a server object within the Servers container for the site it is a member
of (e.g., cn=DC1,cn=Servers,cn=MySite,cn=site,cn=configuration,dc=adatum,dc=com).
Since other types of servers can have server objects in a site’s
Servers container, domain controllers
are differentiated by the nTDSDSA
object that is a child of the server
object (e.g., cn=NTDSSettings,cn=DC1,cn=Servers,cn=MySite,cn=site,cn=configuration,dc=adatum,dc=com).
Querying for this nTDSDSA object will
return a list of domain controllers in the site. Locating global catalog
servers consists of the same query, except where the low-order bit of
the options attribute of the nTDSDSA object is equal to 1. Note that this may not be available if
replication has not completed after enabling the GC.
Domain controllers and global catalog servers are represented in
DNS as SRV records. You can query SRV records using
nslookup by setting type=SRV, such as in the following:
> nslookup Default Server: dns01.adatum.com Address: 10.1.2.3 > set type=SRV
You then need to issue the following query to retrieve all writable domain controllers for the specified domain:
> _ldap._tcp.<DomainDNSName>You can issue a similar query to retrieve global catalogs:
> _gc._tcp
You can even find the domain controllers or global catalogs that are in a particular site or that cover a particular site by querying the following:
> _ldap._tcp.<SiteName>._sites > _gc._tcp.<SiteName>._sites
See Finding the Bridgehead Servers for a Site for more information on site coverage.
One of the benefits of Active Directory over its predecessor, Windows NT, is that it relies on DNS for name resolution, which is the standard for name resolution on the Internet and on most TCP/IP-based networks. Active Directory uses DNS to locate servers that serve a particular function, such as a domain controller for a domain, global catalog server, PDC Emulator, or KDC. It also uses the site topology information stored in Active Directory to populate site-specific records for domain controllers.
The DC locator process relies on this information in DNS to direct clients to the most optimal server when logging in. Reliance on DNS makes it easy to troubleshoot problems related to clients finding domain controllers. If you know the site a client is in, you can make a few DNS queries to determine which domain controller they should be using to authenticate.
The resource records that a domain controller registers in DNS can be restricted, if you have a lag site configured, for example, so querying DNS may return only a subset of the actual domain controllers that are available. See Recipes and for more information.
Finding Orphaned Objects; Listing the Replication Partners for a DC; Finding the PDC Emulator FSMO Role Owner via DNS for finding the PDC Emulator via DNS; MS KB 267855 (Problems with Many Domain Controllers with Active Directory Integrated DNS Zones); RFC 2782, “A DNS RR for Specifying the Location of Services (DNS SRV)”
You want a particular domain controller to be used less frequently for client requests, or not at all. This may be necessary if a particular domain controller is overloaded, perhaps due to numerous application requests.
You can modify the Priority or
Weight field in SRV resource records
by modifying the registry on the domain controller. Open
regedit or regedit32 on the
domain controller and browse to the following key: HKLMSYSTEMCurrentControlSetServicesNetlogonParameters.
To configure the priority, add a REG_DWORD with the name LdapSrvPriority. To configure the weight, add
a REG_DWORD with the name LdapSrvWeight.
After you make the change, the %SystemRoot%System32Config etlogon.dns file should be updated and the DDNS updates sent to the DNS server within an hour. You can also restart the NetLogon service to expedite the process.
Each domain controller registers several SRV records that clients
use as part of the DC locator process to find the closest domain
controller. Two fields of the SRV record let clients determine which
server to use when multiple possibilities are returned. The Priority field is used to dictate whether a
specific server or set of servers should always be contacted over others
unless otherwise unavailable. A server with a higher priority (i.e.,
lower Priority field value) will
always be contacted before a server with a lower priority. For example,
if DC1 has an SRV priority of 5 and DC2 has an SRV priority of 10, DC1
will always be used unless it is unavailable.
The Weight field, on the other
hand, determines the percentage of time clients should use a particular
server. You can easily calculate the percentage by dividing the weight
by the sum of all weights for servers with the same priority. If servers
DC1, DC2, and DC3 have weights of 1, 2, and 3, respectively, then DC1
will be contacted one out of six times or (1 / (3 + 2 + 1)), DC2 will be
contacted two out of every six times or 1/3 (2 / (3 + 2 + 1)), and DC3
will be contacted three out of every six times or 1/2 (3 / (3 + 2 + 1)).
Here is an example of how the SRV records look with these
weights:
C:> nslookup -type=SRV _ldap._tcp.dc._msdcs.adatum.com
Server: dns01.adatum.com
Address: 172.16.168.183
_ldap._tcp.dc._msdcs.adatum.com SRV service location:
priority = 0
weight = 1
port = 389
svr hostname = dc1.adatum.com
_ldap._tcp.dc._msdcs.adatum.com SRV service location:
priority = 0
weight = 2
port = 389
svr hostname = dc2.adatum.com
_ldap._tcp.dc._msdcs.datum.com SRV service location:
priority = 0
weight = 3
port = 389
svr hostname = dc3.datum.comIn certain situations, having this capability can come in handy.
For example, the server acting as the PDC FSMO role owner typically
receives more traffic from clients simply because of the nature of tasks
that the PDC FSMO has to handle. If you find a certain server, like the
PDC FSMO, has considerably higher load than the rest of the servers, you
could change the priority or weight of the SRV records so that the
server is used less often during the DC locator process. You can
increase the Priority to eliminate
its use unless all other domain controllers fail, or modify the Weight to reduce how often it will be
used.
You can modify this information manually within the DNS Management
Console, or for multiple DCs using Group Policy Objects in the Computer ConfigurationAdministrative
TemplatesSystemNet LogonDC Locator DNS
Records GPO node.
You want to disable the requirement for a global catalog server to be reachable when a user logs in to a Windows domain.
See Enabling Universal Group Membership Caching for information on enabling universal group caching, which can reduce the need to contact a global catalog server during logon for universal group expansion.
In the following command, you can leave out the /Domain
<DomainDNSName> option to query the
domain you are currently logged in to:
> netdom query fsmo /Domain:<DomainDNSName>To query the owner of an individual FSMO role, you can use the
dsquery server command shown here,
where <Role> can be schema, name, infr, pdc, or rid:
> dsquery server -hasfsmo <Role>Several Active Directory operations are sensitive, such as updating the schema, and therefore need to be restricted to a single domain controller to prevent corruption of the AD database. This is because Active Directory cannot guarantee the proper evaluation of these functions in a situation where they may be invoked from more than one DC. The FSMO mechanism is used to limit these functions to a single DC.
Five designated FSMO roles correspond to these sensitive
functions. A FSMO role can apply either to an entire forest or to a
specific domain. Each role is stored in the fSMORoleOwner attribute on various objects in
Active Directory depending on the role. Table 3-5
contains a list of FSMO roles.
Table 3-5. FSMO roles
Role | Description |
| Domain- or forest-wide? |
|---|---|---|---|
Schema | Processes schema updates. |
| Forest |
Domain Naming | Processes the addition, removal, and renaming of domains. |
| Forest |
Infrastructure | Maintains references to objects in other domains. |
| Domain |
RID | Handles RID pool allocation for the domain controllers in a domain. |
| Domain |
PDC Emulator | Receives preferential password replication, handles user authentication after another DC reports bad password, handles account lockouts. |
| Domain |
You want to transfer a FSMO role to a different domain controller. This may be necessary if you need to take a current FSMO role holder down for maintenance.
Use the same directions as described in Finding the FSMO Role Holders for viewing a specific FSMO, except target (i.e., right-click and select Connect to Domain Controller) the domain controller you want to transfer the FSMO to before selecting Operations Master.
Click the Change button.
Click OK twice.
You should then see a message stating whether the transfer was successful.
The following will transfer the PDC Emulator role to
<NewRoleOwner> (see Discussion section for information on transferring
the other roles):
> ntdsutil roles conn "co t s <NewRoleOwner>" q "transfer PDC" q qThe following command will transfer the PDC Emulator role to a DC named DC1:
Move-ADDirectoryServerOperationMasterRole DC1 -PDCEmulator
The following will transfer the RID Master role to another DC named DC1; this syntax can be used for all FSMO role holders except for the PDC Emulator:
Move-ADDirectoryServerOperationMasterRole DC1 -RIDMaster
The first domain controller in a new forest is assigned the two forest-wide FSMO roles (schema and domain naming). The first domain controller in a new domain gets the other three domain-wide roles. It is very likely you’ll need to move the roles around to different domain controllers at some point. Also, when you need to decommission a domain controller that is currently a FSMO role owner (either permanently or for a significant period of time), you’ll want to transfer the role beforehand.
If you plan to install a hotfix or do some other type of maintenance that only necessitates a quick reboot, you may not want to go to the trouble of transferring the FSMO role. This is because some FSMO roles are more time-critical than others, and some come into use on a far more frequent basis. For example, the PDC Emulator role is used extensively (and therefore should be transferred to a domain controller of equal or better capacity as a best practice), but the Schema Master is needed only when you are extending the schema by installing a new software package, such as Microsoft Exchange. If a FSMO role owner becomes unavailable before you can transfer it, you’ll need to seize the role (see Seizing a FSMO Role).
Any role can be transferred using ntdsutil
by replacing "transfer PDC" in the
solution with one of the following:
"transfer domain naming master""transfer infrastructure master""transfer RID master""transfer schema master"
The FSMO roles can be shortened to simplify the commands to move the roles. Because each role starts with a unique letter, you can transfer them by just referring to them by the first letter of the role name. In addition, you can transfer multiple roles in one command. The following command will transfer all five roles to DC1:
Move-ADDirectoryServerOperationMasterRole DC1 -S,D,I,P,R
Finding the FSMO Role Holders for finding FSMO role holders; Seizing a FSMO Role for seizing a FSMO role; “Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller”
The following will seize the PDC Emulator role to
<NewRoleOwner>:
> ntdsutil roles conn "co t s <NewRoleOwner>" q "seize PDC" q qAny of the other roles can be transferred as well using
ntdsutil by replacing "seize PDC" in the previous solution with
one of the following:
"seize domain naming master""seize infrastructure master""seize RID master""seize schema master"
Seizing a FSMO role should not be taken lightly. The general recommendation is to seize a FSMO role only when you cannot possibly bring the previous role holder back online. One reason that seizing a role is problematic is that you could possibly lose data. For example, let’s say that you extended the schema and immediately after it was extended the Schema FSMO went down. If you could not bring that server back online, those extensions may not have replicated before the server went down. You would need to determine whether any of the schema extensions replicated and, if not, reextend the schema. Other issues can result from losing the RID FSMO, where duplicate RID pools may be allocated. See Finding the FSMO Role Holders for more information.
Finding the FSMO Role Holders for finding FSMO role holders; Transferring a FSMO Role for transferring a FSMO role; “Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller”
The PDC Emulator FSMO role is the only FSMO role that is stored in
DNS. Like many of the other Active Directory−related DNS records, the
PDC record is stored as an SRV record under _ldap._tcp.pdc._msdcs.<DomainDNSName>
where <DomainDNSName> is the domain the
PDC is in. This allows your Active Directory clients to use normal DNS
name resolution to locate the PDC Emulator for their domain.
Finding Domain Controllers and Global Catalogs via DNS for finding domain controllers via DNS