Learn Active Directory - Adding Additional Domain Controllers

#Introduction

In episode 5 you successfully built the first domain controller (DC) in a new forest — one server at the center of authentication, DNS, and policy for the entire ad.example.com domain. But a single DC is a single point of failure: if that server dies, nothing validates logins, nothing answers LDAP queries, and the whole Windows network is effectively paralyzed. Episode 6 answers that problem by adding additional DCs so Active Directory becomes resilient.

In this episode you'll learn: why multiple DCs are mandatory, how to promote a second server with Install-WindowsFeature and Install-ADDSDomainController, the role of the global catalog, DNS configuration after adding a DC, verifying replication with dcdiag and repadmin, DC placement strategies, and how to demote a DC cleanly.

#Why One DC Is Not Enough

#Fault Tolerance

Picture a single-engine airplane. The engine could be extremely reliable — but the moment it fails mid-flight, there's no backup. A single DC is exactly that: the entire domain depends on one server. By adding a second DC, failed connections to one server are automatically redirected to another DC. Authentication keeps running even when one DC is under maintenance or down.

#Load Distribution

The more users, the heavier the authentication and directory query load. A single DC serving thousands of users quickly heats up: high CPU, slow LDAP, queued logins. With multiple DCs, the load is shared — some logins are handled by the first DC, others by the second. The result is lower login latency and no single-server bottleneck.

#Geographic Distribution

If your company has offices in Jakarta and Surabaya, users in Surabaya shouldn't have to authenticate across the WAN to Jakarta on every login. By placing a DC at each site, users are served by the nearest DC. This isn't just about convenience — it's about speed, reliability, and meeting SLAs.

#Fast Recovery

A DC isn't a replacement for backups, but a DC is a living backup. When one DC is permanently damaged, another DC still holds the same data copy and users don't notice a thing. Replication happens almost in real time, so maximum data loss is only a few minutes — far faster than restoring from a backup.

#Preparation Before Promotion

Before the second server is promoted, make sure the following is in place:

• Static IP address — a DC must never use DHCP; the address must stay fixed.
• DNS pointing to an existing DC — the new server must be able to find DCs via SRV records. Point its DNS server at the first DC (or use a conditional forwarder), not at a router or public DNS.
• Time synchronization — use the same NTP source so Kerberos doesn't reject requests due to clock skew.
• Domain administrator credentials — promotion requires Domain Admins rights.

Without this preparation, promotion often fails with confusing errors like a domain controller could not be located — which is really rooted in misdirected DNS.

#Installing the AD DS Role

The first step is installing the Active Directory Domain Services role on the new server. Run it in an administrator PowerShell session:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

-IncludeManagementTools also installs consoles like ADUC and DNS Manager that you'll use in later episodes. After the role is installed, the server is still a regular member server — not yet a DC. That transformation happens at the promotion stage.

#Promoting to a Domain Controller

Promoting an additional DC is done with the Install-ADDSDomainController cmdlet. The difference from episode 5: this time we're not creating a new forest, but joining an existing domain:

$password = ConvertTo-SecureString -String "P@ssw0rd" -AsPlainText -Force
 
Install-ADDSDomainController `
    -DomainName "ad.example.com" `
    -SiteName "Jakarta-Site" `
    -InstallDns:$true `
    -GlobalCatalog:$true `
    -Credential (Get-Credential) `
    -SafeModeAdministratorPassword $password `
    -NoRebootOnCompletion

Explanation of the key parameters:

• -DomainName — the target domain name; the server will join this domain.
• -SiteName — the AD site where this DC lives; affects replication and client placement (episode 3).
• -InstallDns:$true — installs DNS and creates AD-integrated zones (recommended to always enable).
• -GlobalCatalog:$true — makes this DC a GC server (covered below).
• -SafeModeAdministratorPassword — the DSRM password, required for system repair.

If you prefer the GUI, open Server Manager > Add roles and features, select AD DS, then on the notification choose Promote this server to a domain controller. In the wizard, select Add a domain controller to an existing domain and fill in the same credentials and options. The GUI and PowerShell produce identical configuration — PowerShell is just faster to repeat and automate.

After the server reboots, it will pull a copy of the AD database via replication from an existing DC. Don't worry if the process takes a few minutes — that's normal for the first copy.

#Global Catalog

A Global Catalog (GC) is a server that stores a partial copy (partial attribute set) of every object across the entire forest. The GC serves two important needs:

• Login with a UPN — e.g. budi.santoso@ad.example.com cross-domain logins need a GC.
• Universal group membership — determining a user's access across all domains.

The first DC automatically becomes a GC. Every additional DC is also made a GC by default in the promotion wizard — and that's the right choice for small-to-medium scale. With GCs on many DCs, cross-domain queries don't need to travel far; every site has a local GC. Unless you have a strong reason (e.g. hundreds of DCs), leave every DC as a GC.

#DNS After Adding a DC

As soon as the new DC is live, it registers its own SRV records in the AD-integrated zone — clients and other DCs will find it automatically via the domain controller locator process. However, for DNS resolution outside the AD zone (e.g. public names), every DC needs a forwarder. If not configured, the DC will try to use root hints and queries can be slow or fail in isolated environments:

Add-DnsServerForwarder -IPAddress 8.8.8.8 -PassThru
Get-DnsServerForwarder

Make sure the forwarder configuration is consistent across all DCs — e.g. via a script or configuration management tool — so resolution behavior doesn't differ between servers.

#DC Placement Strategy

Some common DC placement principles in production:

• At least one DC per site — every physical location needs a local DC so authentication doesn't cross the WAN.
• Multiple DCs in hub sites — headquarters holds 2 or more DCs for redundancy and load.
• RODCs for branch offices — small branches without a local admin can use a Read-Only Domain Controller, which doesn't store sensitive credentials. Details are covered in episode 19.
• GCs near users — place GCs in sites that need fast cross-domain queries.

Remember: DCs are the most sensitive assets on the network. The fewer places DCs live, the easier they are to secure. Don't add DCs without a real need.

#Verifying Replication and Health

Once the new DC is online, don't take it on faith — verify with standard tools:

dcdiag /c

dcdiag /c runs a series of tests: connectivity, DNS, replication, services, and more. All tests should report passed. For replication, repadmin gives a more specific view:

repadmin /replsummary
repadmin /showrepl

repadmin /replsummary shows a summary of how all DCs replicate against each other — a largest delta that keeps growing indicates a replication problem. repadmin /showrepl shows each DC's replication partners and when they last synced successfully. Run both routinely — silently failing replication is one of the AD problems most often noticed too late.

#Demoting a DC Cleanly

There are times when a DC must be retired. The correct process is graceful demotion — not just powering off the machine:

Uninstall-ADDSDomainController -RemoveApplicationPartitions -SafeModeAdministratorPassword $password

A proper demotion will: move any FSMO roles this DC holds, remove its metadata from AD, and clean up DNS. If a DC is badly damaged and can't boot, you must do a manual metadata cleanup — removing the DC's leftover objects from AD with ntdsutil or Remove-ADDomainController. Also make sure no FSMO roles are left behind before decommissioning the last DC in a domain. This discipline is part of what saves you from troublesome "zombie DCs" later.

#Conclusion

In episode 6 you learned that multiple DCs aren't a luxury but a necessity: fault tolerance, load distribution, geographic service, and fast recovery. You promoted an additional DC with Install-WindowsFeature AD-Domain-Services and Install-ADDSDomainController, understood the global catalog, configured DNS forwarders, verified with dcdiag and repadmin, and demoted a DC cleanly.

Key takeaways:

• A single DC is a single point of failure — at least two DCs per domain.
• Every DC is a global catalog by default; make sure GCs are near users.
• Replication must be verified with dcdiag and repadmin routinely.
• Demotion must be clean, not just powering off the machine.

Now your directory is resilient. In the next episode, we populate the directory with objects: Active Directory Users and Computers — creating users, groups, and OUs, understanding account properties, logon hours, and user account control. See you in episode 7!