When customers install Microsoft Active Directory Domain Services (AD DS) in Windows Server 2008 or Server 2008 R2, a couple of issues sometimes come up. One issue involves installation; another is about Microsoft's recommendations for running domain controllers (DCs) as virtual machines (VMs).

These issues might be familiar to experienced administrators. But if you're a less-experienced administrator who needs to replace DCs that run Windows Server 2003 with those that run Server 2008 R2, this article will shed some light on these issues and can help you avoid problems.

Adprep-Related Errors

Adprep is a utility that you run to prepare an existing Active Directory (AD) environment for the first DC that runs a newer OS, such as Server 2008 R2. If you have an AD environment in which all DCs run Server 2008 or Windows 2003, and you want to add the first DC that runs Server 2008 R2, then you need to run certain Adprep commands:

1. Run adprep /forestprep on the schema master.

2. Run adprep /domainprep on each domain's infrastructure master.

3. If you plan to install a read-only DC (RODC -- new in Server 2008), then you also need to run adprep /rodcprep for every domain that will have an RODC.

The article "The Adprep Process" tells more about this process, which is straightforward enough. Still, administrators often have questions:

  • What exactly does Adprep do?
  • What is the process for making sure that any necessary Adprep commands run successfully?
  • How do I work around any errors?
The Microsoft article " Running Adprep.exe" explains all that and more: the utility's general purpose, the process for running the necessary commands, and how to validate the utility's success. (If you want to review the exact changes that Adprep operations make to prepare an existing AD, see the Microsoft articles " Windows Server 2008: Appendix of Changes to Adprep.exe to Support AD DS"   and " Windows Server 2008 R2: Appendix of Changes to Adprep.exe to Support AD DS." )

When running Adprep, plan for these important factors:

  • Credentials -- Prepare to specify the necessary credentials for each Adprep command. Depending on the command, you might need to supply credentials for an account that is a member of the Schema Admins, Enterprise Admins, or Domain Admins group.
  • Access to Flexible Single-Master Operation roles (FSMOs) -- You need to run Adprep on the Schema Master of the forest and on the Infrastructure Master in the domain in which you're installing the new DC. Note that you need either to run the command from the new OS DVD on the Operations Master, or to copy the Adprep utility and its folder contents from the DVD before running it. (See the sidebar "An Adprep Caveat" for a warning about isolating the Schema Master.) Be aware that Server 2008 R2 includes both 32- and 64-bit versions of Adprep (in the \support\adprep folder of the OS disk). The 64-bit version runs by default. If you're running Adprep on a 32-bit system, be sure to use Adprep32.exe instead.
  • Replication -- Make sure that replication is working throughout the forest. Take a look at "Troubleshooting Active Directory Replication" and "Active Directory Replication In Depth."  for more information about troubleshooting AD replication.

If you can prepare for these potential issues and follow the process that the previously mentioned articles describe, you should have no trouble. In some cases, though, you might see one of these errors during an Adprep operation:

The overall Server 2008 or Server 2008 R2 upgrade process is described in the Microsoft article "Upgrade Domain Controllers: Microsoft Support Quick Start for Adding Windows Server 2008 or Windows Server 2008 R2 Domain Controllers to Existing Domains."

DNS Delegation Error

After Adprep completes successfully, you can install the first DC that runs Server 2008 or Server 2008 R2 into your existing AD. If you choose to install the DNS server role during the DC installation, you might see this warning, which Figure 1 shows:



Figure 1: DNS delegation error
Figure 1: DNS delegation error

 

 "A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found or it does not run Windows DNS server. If you are integrating with an existing DNS infrastructure, you should manually create a delegation to this DNS server in the parent zone to ensure reliable name resolution from outside the domain 'treyresearch5.net.' Otherwise, no action is required."

Before Server 2008, many customer problems with AD installations were caused by underlying problems with the DNS infrastructure, such as missing or incorrect DNS delegation records. One of Microsoft's goals for improving AD DS installation in Server 2008 was to help customers initially configure the correct DNS infrastructure and then to help them maintain that configuration.

To that end, the AD DS installation wizard (Dcpromo) in Server 2008 and later automatically tries to create a DNS delegation when you create a new forest. The DNS delegation helps to ensure that clients from other domains can resolve host names in the domain of the new DC. If you aren't concerned about the ability of people in other domains or on the Internet to resolve DNS name queries for computer names in the local domain, you can disregard the message that Dcpromo uses to create this DNS delegation; simply click Yes when the message appears.

The message appears when these three conditions are met:

  • Dcpromo has been configured to install the DNS server role.
  • Too few delegations exist between DNS servers in the immediate parent DNS zone and the subdomain in which you're installing the new DC.
  • The DC that you're installing cannot create a delegation to the DNS subdomain on a DNS server that is authoritative for the parent zone.

Dcpromo tries to create the delegation to ensure that computers in other domains can resolve DNS queries for hosts, including DCs and member computers, in the DNS subdomain.

Dcpromo can automatically create such delegations only on Microsoft DNS servers; the effort will fail if the parent DNS domain zone resides on third-party DNS servers such as BIND.

You can see this error when you install DCs in forest root domains that have two- or three-part names (such as contoso.com or corp.contoso.com) and that are immediately subordinate to top-level Internet domains such as .com, .gov, .biz, .edu, or two-letter country code domains such as .nz and .au. If your AD domain is to be registered on the Internet by the time it is promoted, the logging of this error might indicate that your ISP or DNS hosting provider hasn't yet created the necessary delegation to your AD subdomain.

You might also encounter this error when creating DCs in a forest root domain that is subordinate to an existing corporate intranet namespace. For example, if BIND DNS servers own the internal domain contoso.com, then you'll encounter this error when Dcpromo attempts to create the delegation from contoso.com to the AD forest root domain's corp.contoso.com subdomain.

For Dcpromo to create the delegation on authoritative DNS servers in the parent domain, these conditions must be met:

  • The parent DNS server must run the Microsoft DNS Server service.
  • The Microsoft DNS server in the parent domain must be online and accessible over the network from the DC that you're installing.
  • The user running Dcpromo on the DC that you're installing must have Domain Admins, Enterprise Admins, or DNS Admin credentials in the parent DNS zone.

Given that many AD domains aren't registered with an Internet registrar, and that the DNS servers for top-level domains (TLDs) run BIND, you can safely ignore this error message and click Yes to continue the promotion.

When delegations should exist between the parent domain and the subdomain that's being promoted, you can create and validate those delegations before or after the Dcpromo promotion. There's no reason to delay the promotion of a new DC that presents this error. To avoid the error message in future Dcpromo promotions, take one of these actions:

  • Pre-create the delegation on third-party DNS servers in the immediate parent domain.
  • Make sure that DCs that are being promoted have network connectivity and the necessary administrative credentials to create delegations on Microsoft DNS servers that host the parent DNS zone.
  • Specify the /CreateDNSDelegation:No argument in the Dcpromo command line or answer file.

For more information about DNS delegation, see the Microsoft article "Understanding Zone Delegation."  If zone delegation isn't possible in your situation, you might consider other methods for providing name resolution from other domains to the hosts in your domain. For example, the DNS administrator of another domain could configure conditional forwarding, stub zones, or secondary zones to resolve names in your domain. These Microsoft articles explain these concepts in more detail:

· "Understanding Zone Types"

· "Understanding stub zones"

· "Understanding forwarders" (go.microsoft.com/fwlink/?linkid=164778)

Virtual DCs and Update Sequence Number Rollback

Although Microsoft has published guidance and best practices for running DCs as VMs (see "Running Domain Controllers in Hyper-V"), some customers who run virtual DCs have problems with update sequence number (USN) rollback. The problems are often caused by improper restores of the VM. For example, replication errors appear and are determined to be caused by a USN rollback, which was the result of a restored snapshot of the virtual DC.

Only supported backup solutions, such as Windows Server Backup, can be used to restore a DC. Microsoft has recently revised the recommendations for running DCs as VMs, specifically the explanation of USNs and how to prevent USN rollback. These revisions should make the information more concise and clear and help customers avoid problems.

"The Specified User Already Exists" Error

In some cases, AD installation on a workgroup server might fail and return this error on the Summary page: "The operation failed because: The attempt to join this computer to the <target domain> failed. 'The specified user already exists.'" In this situation, the dcpromoui.log file, which is stored in the \%windir%\debug folder, contains the text that Figure 2 shows.

Figure 2: Error text in the dcpromoui.log file
Figure 2: Error text in the dcpromoui.log file

This error most often indicates that the server you're promoting has the same host name as another DC. Follow these steps to fix the issue:

1. If you're replacing a previously demoted DC with a new DC of the same name, make sure to remove the old DC's metadata. In Server 2008 and later, AD snap-ins provide a simplified way to remove DC metadata. If necessary, you can also use the legacy method: Ntdsutil.

2. If Dcpromo continues to fail with this error, review the dcpromoui.log file to identify the name of the source DC (aka the helper DC) that the new replica DC is using for replication. Search the file for the section that begins at callout A in Figure 3. The name of the source DC appears in the output at callout B.

Figure 3: Searching dcpromoui.log for the helper DC name
Figure 3: Searching dcpromoui.log for the helper DC name 

3. Verify that the source DC has inbound replicated the removal of the DC metadata (i.e., the conflicting DC machine account and NTDS Settings objects). If the DC machine account still exists, then determine the reason:

  • simple replication latency, such as a DC that is several hops away from the DC that originated the metadata-cleanup operation
  • an inbound replication failure on the helper DC or on the source DC from which the helper DC receives changes
  • a helper DC in a "lag site" that has been intentionally configured to inbound replicate changes to AD in a delayed fashion
The error can have other root causes aside from a conflicting machine account. These Microsoft articles discuss these other possible causes:

Sometimes Dcpromo fails while trying to create the NTDS Settings object for the DC. In this case, several errors might display a similar message; the extended error information will help to identify the root cause. Look for text such as "The operation failed because..." or "Active Directory could not create the NTDS Settings object...."

For example, Dcpromo can fail with this on-screen error: "The operation failed because: Active Directory could not create the NTDS Settings object for this domain controller <NTDS Settings object DN path> on the remote domain controller <fully qualified computer name of source DC>. Ensure the provided network credentials have sufficient permissions.<%Extended error string%>". Be aware that the boilerplate text "Ensure the provided network credentials have sufficient permissions" can be misleading; the failure to create the NTDS Settings object isn't necessarily caused by insufficient credentials. Table 1 lists possible extended error strings for this error message.

Another common cause of AD installation failure is not granting the Administrators group the Enable computer and user accounts to be trusted for delegation user right. This right is a Group Policy setting that is enabled for the Administrators group by default in the Default Domain Controllers Policy.

When a DC is selected as a replication partner during the promotion of a replica DC, the selected DC requires access to resources on the computer that you're promoting. If the Enable computer and user accounts to be trusted for delegation user right is not granted to the Administrators security group, then each access request for a resource fails with the "Access denied" error that Figure 4 shows.

 

 Figure 4: Access denied error
Figure 4: Access denied error

To resolve the error, use Group Policy Management Console (GPMC) and the Group Policy Results tool (Gpresult) to verify that the Administrators group is granted the Enable computer and user accounts to be trusted for delegation user right in the Default Domain Controllers Policy. The path in Group Policy Editor is \Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\ Enable computer and user accounts to be trusted for delegation.

After a DC is running Server 2008 R2, you can run the AD DS Best Practices Analyzer (BPA) to catch this kind of policy-setting misconfiguration. The appropriate BPA rule isn't included in the original set of rules but is part of a supplementary set of rules that's delivered via Windows Update. This rule will be applied to a DC that runs Server 2008 R2.

When you run the AD DS BPA, another rule from the same supplementary set can help prevent a couple of common Group Policy setting misconfigurations that are root causes of DC replication failure: not granting the Access this computer from the network user right to the Administrators, Enterprise Domain Controllers, or Authenticated Users security groups, or having the Enterprise Domain Controllers, Everyone, Administrators, or Authenticated Users security groups in the settings of the Deny access to this computer from network user right. Any DC that tries to replicate from a DC with one of the aforementioned policy settings might fail. Users and computers might also experience failure to apply Group Policy Objects (GPOs).

To resolve that error, follow the steps in the BPA to verify that the DCs have this user right granted to the appropriate security principals. You can use the GPMC and Gpresult settings in Table 2 to verify that Group Policy reflects the correct settings.

Better Troubleshooting

The good news is that the new Windows PowerShell cmdlets for AD DS installation and replication management in the Windows Server 8 address these issues. In the meantime, explaining these issues will hopefully help administrators who need to install and troubleshoot DCs that run Server 2008 R2 to be better informed and less hindered.