Add a Second Domain Controller (Windows Server)

Before you begin: prerequisites

Because the new server will hold a full copy of your directory, get the fundamentals right first:

• A supported Windows Server installation (Standard or Datacenter), patched and rebooted, ideally at the same build as your existing DC.
• A static IP address on the same network as, and able to reach, the existing domain controller. Domain controllers should never use a DHCP-assigned address.
• Preferred DNS pointed at an existing domain controller. Set the new server's DNS to your current DC's IP before promotion, so it can find the domain. This is the step people forget.
• Domain membership and credentials. Join the server to the existing domain first, and have an account that is a member of Domain Admins (adding the first DC to a new domain in a forest also needs Enterprise Admins).
• Healthy time sync. The new server's clock must be within a few minutes of the existing DC — Kerberos rejects large time differences.

Step 1 — Install the AD DS role

You can do this with Server Manager or with one line of PowerShell — Microsoft Learn documents both routes for installing AD DS.

Using Server Manager

1. Open Server Manager on the new server and choose Manage → Add Roles and Features.
2. Keep Role-based or feature-based installation and select the local server.
3. On the Server Roles page, tick Active Directory Domain Services and click Add Features when prompted for the management tools.
4. Click Next through the remaining pages, then Install. No reboot is needed yet.

Using PowerShell

Open an elevated PowerShell window and run:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Step 2 — Promote as an additional domain controller

Installing the role does not join the directory by itself. The promotion step is what makes this server a domain controller.

1. In Server Manager, click the yellow notification flag near the top right and choose Promote this server to a domain controller.
2. On the Deployment Configuration page, select Add a domain controller to an existing domain. Confirm the domain name and, if needed, click Change to supply credentials of a Domain Admins account, as set out in Microsoft's replica domain controller deployment reference.
3. On Domain Controller Options, keep Domain Name System (DNS) server and Global Catalog (GC) selected, choose the correct site from the list, and set a Directory Services Restore Mode (DSRM) password. Store that password somewhere safe.
4. Step through DNS Options (a delegation warning here is normal and safe to continue past) and Additional Options, where you can choose which DC to replicate from — leaving it on Any domain controller is fine in a single-site network.
5. Accept or change the database, log and SYSVOL paths, let the prerequisite check run, then click Install. The server configures itself, replicates the directory, and reboots automatically.

Prefer to script it? The equivalent command promotes the server into an existing domain and installs DNS:

Install-ADDSDomainController -DomainName "corp.example.com" -InstallDns -Credential (Get-Credential)

You are prompted for the domain credentials and the DSRM (SafeMode) password, and the server reboots when it finishes. By default the new controller is a Global Catalog; add -NoGlobalCatalog only if you deliberately do not want that, per the Install-ADDSDomainController cmdlet reference.

Step 3 — Verify DNS, SYSVOL and Global Catalog

After the reboot, sign in with a domain admin account and do a few quick sanity checks on the new controller:

• DNS records: open DNS Manager and confirm the new server's zones match the existing DC, including the _msdcs service records that let clients locate controllers.
• SYSVOL and NETLOGON shares: run net share and confirm both SYSVOL and NETLOGON are published — they must exist for Group Policy and logon scripts to work.
• Global Catalog: in Active Directory Sites and Services, expand the server's NTDS Settings and confirm the Global Catalog box is ticked.

Step 4 — Verify replication health

The real test is that the two controllers are exchanging changes. From an elevated prompt on either DC, start with a summary — the Microsoft Learn repadmin /replsummary reference describes it as identifying domain controllers that are failing inbound or outbound replication:

repadmin /replsummary

This lists each domain controller with its largest replication delta and any failures — you want zero errors. For per-partition detail showing the last successful and last attempted replication, run:

repadmin /showrepl

Then run the health test suite:

dcdiag

Add /v for verbose output when you need to dig into a specific failure. A clean dcdiag, healthy repadmin, published SYSVOL and NETLOGON shares, and valid DNS service records together mean the new domain controller is fully in service.

Where to go next

With two controllers running, point some clients' secondary DNS at the new server so they fail over automatically, and from now on patch and reboot your controllers one at a time. If clients later report they cannot reach the domain, work through the trust relationship between this workstation and the primary domain failed, and if you are still shaping DNS for the domain see setting up DNS on Windows Server. For more background, browse the wider Windows Server section.

Frequently asked

Why should I add a second domain controller?

A single domain controller is a single point of failure. If it is offline for updates, fails, or is being rebuilt, users cannot authenticate, DNS lookups for the domain break, and Group Policy stops applying. A second domain controller provides redundancy so the domain keeps working when one server is down, and it spreads the authentication and DNS load. For anything beyond a lab you should run at least two.

Do I create a new forest when adding a second DC?

No. Creating a new forest is only for the very first domain controller on a brand-new network. To add a second DC you install the AD DS role and then, in the promotion wizard, choose Add a domain controller to an existing domain. The new server replicates a copy of the existing directory rather than starting a fresh one, so both controllers serve the same domain.

Should the second domain controller also run DNS and be a Global Catalog?

In almost all small and medium environments, yes. Running DNS on the second DC means name resolution survives if the first server is down, and Active Directory-integrated DNS zones replicate automatically between them. Making it a Global Catalog lets it answer forest-wide lookups and logons locally. Both options are selected by default in the promotion wizard, and leaving them on is the sensible choice for a two-DC domain.

How do I check that replication is working?

After the new domain controller reboots, open an elevated prompt and run repadmin /replsummary for a quick overview of inbound and outbound replication across all DCs, and repadmin /showrepl for per-partition detail. Then run dcdiag, or dcdiag /v for verbose output, to run a battery of health tests. A newly created object on one DC that appears on the other within a few minutes is the practical confirmation that replication is healthy.