ACTIVE DIRECTORY DEEP CORE

Domain Controllers, Global Catalog, FSMO and Replication Deep Core

Learn what a domain controller actually does and why directory resilience depends on more than having two VMs.

Active Directory Deep Core | Chapter 2 of 7

Chapter purpose

Active Directory is a distributed database, but some operations still have special role owners and replication follows network topology.

Historical source context: The supplied reference books describe Windows 2000/2003 and Exchange 2000/2003. They are used for subject breadth and architectural history, not as current production instructions. The material below is rewritten in original wording and modernized with current Microsoft documentation.

Learning objectives

  • Explain writable DC and global catalog functions.
  • Name the five FSMO roles and their scope.
  • Understand KCC-generated replication topology.
  • Plan DC placement without shared failure points.

Why this matters in a real company

If authentication and DNS depend on one server, that server is a business outage waiting to happen. Correct DC placement and replication design make identity services recoverable.

Domain controller services, replication and special roles
Clientssign-in and lookupDomain controllersdirectory replicasKCC/sitesreplication topologyFSMO/GCspecial functionsTrace the dependency chain, then prove each handoff with evidence.

2.1 Domain controllers hold replicated directory data

Writable domain controllers contain a writable copy of the domain directory and participate in replication. Changes made on one DC are replicated to other DCs that host the same partition.

Multiple DCs improve availability only when they do not share the same host, switch, storage and power failure domain.

2.2 Global Catalog and FSMO roles solve different problems

The Global Catalog provides forest-wide lookup using a partial set of attributes from objects across domains. FSMO roles coordinate operations that should have a single authoritative owner.

  • Schema Master: forest-wide schema change coordination.
  • Domain Naming Master: forest domain/partition changes.
  • RID Master: allocates RID pools in a domain.
  • PDC Emulator: important for time, password-change priority and compatibility functions.
  • Infrastructure Master: maintains cross-domain reference information.
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
netdom query fsmo

2.3 Sites and KCC turn the physical network into replication behavior

AD sites represent well-connected IP networks. Subnet objects map client addresses to sites. Microsoft documents the KCC as the built-in process that generates and adjusts replication topology as DCs and sites change.

Manual replication connections should be exceptional. A topology that only works because one administrator manually built every connection is fragile.

2.4 Observe replication before forcing it

Record the failing partner, naming context and error code before using force-sync commands. DNS, time and network faults frequently appear as replication problems.

repadmin /replsummary
repadmin /showrepl
dcdiag /test:replications
Get-ADReplicationFailure -Target * -Scope Forest
DEEPER READING

FSMO transfer, seizure and time hierarchy

A planned FSMO transfer is normal administration. A seizure is an emergency action used when the existing role owner cannot safely return. Before seizing, identify the failed server, role scope, backup state and whether another DC can assume the function without creating conflicting ownership.

The PDC Emulator is especially important operationally because Windows domain time ultimately follows the domain hierarchy toward the PDC Emulator. Time problems can surface as Kerberos and authentication problems, so the time source belongs in the DC runbook alongside FSMO ownership.

Virtualized domain controllers still need physical diversity

Virtualization makes DC deployment easier, but it can hide shared risk. Two DC VMs on one host, one storage array, one PDU and one switch are two operating systems inside one failure domain. Map the physical host, power, network and storage dependencies for each controller.

When adding a new DC, verify DNS registration, site placement, Global Catalog state, replication and SYSVOL/NETLOGON availability. The server being powered on is not proof that it is a healthy domain controller.

WORKED BUSINESS SCENARIO

The VM hosting the PDC Emulator fails

A second DC remains online and users can still sign in, but the PDC Emulator owner is unavailable.

Decision: Confirm which functions are affected and whether the outage justifies a planned role transfer or recovery. Do not seize roles reflexively.

Evidence: Record FSMO ownership, replication health, DNS health, time source and the recovery decision.

PRACTICAL WORK

Hands-on lab

In a two-DC lab, identify FSMO owners, GC state, AD sites and replication partners. Transfer one lab FSMO role and verify it.

Troubleshooting exercise

  1. Users in one site use remote DCs: check subnet-to-site mapping.
  2. Replication fails one direction: test DNS/network/time in that direction.
  3. New DC never receives changes: verify site placement and connection objects.

Field checklist

  • At least two suitable DCs where resilience requires it.
  • FSMO owners documented.
  • Sites/subnets documented.
  • Replication baseline healthy.
  • DCs not all on one failure domain.
  • Emergency role procedure documented.

Current technical references

The supplied PDF books are used as a historical curriculum map. Current implementation guidance is checked against current Microsoft documentation.