Active Directory installation stalls at the "Creating the NTDS settings object" stage

Applies to: Windows Server 2012 DatacenterWindows Server 2012 Standard


After you start Active Directory installation in Windows Server 2012 by using Server Manager or the AddsDeployment Windows PowerShell module, the installation stalls at the stage at which you receive the following message: 

Creating the NTDS Settings object for this Active Directory Domain Controller on the remote AD DC

Regardless of how long you wait, the installation never proceeds beyond this point. Additionally, when you examine the Directory Services event logs, you see the following repeated events:

Event 1

Event 2

Event 3


This issue occurs for one or more of the following reasons:
  • The server's built-in Administrator account has the same password as the built-in domain Administrator account.
  • The NetBIOS domain prefix or UPN were not provided as credentials for installation. Instead, only the user name "Administrator" was provided. 


To resolve this issue, follow these steps:
  1. Restart the server on which Active Directory could not be installed.
  2. Use Dsa.msc or Dsac.exe on an existing domain controller to delete the failed server's computer account. (The domain controller will not yet be a domain controller object but only a member server.) Then, let Active Directory replication converge.
  3. On the failed server, forcibly remove the server from the domain by using the System Properties Control Panel item or netdom.exe.
  4. On the failed server, remove the Active Directory Domain Services (AD DS) role by using Server Manager or Uninstall-WindowsFeature.
  5. Restart the failed server.
  6. Install the AD DS role, and then try the promotion again. When you do this, make sure that you provide promotion credentials in the form "domain\user" or "user@domain.tld."

More Information

This is a code defect in Windows Server 2012.

If you set different passwords on the two Administrator accounts but do not provide the domain, you receive a bad password error.

We do not recommend that you use the built-in Administrator for domain administration. Instead, we recommend that you create a new domain user for each administrator in the environment. Then, the actions of administrators can be audited individually.

We strongly discourage you from using matching Administrator passwords on member servers and the domain Administrator account. Local passwords are more easily compromised than AD DS accounts, and knowledge of the matching Administrator passwords grants full enterprise administrative access.