Most Active Directory writes are multi-master. Five operations are deliberately single-master, and the Global Catalog supplies forest-wide search and universal-group information. They are important—but moving every role at the first warning can create a second problem.

Know the roles

Two roles exist once per forest:

  • Schema Master: authorises schema changes.
  • Domain Naming Master: controls addition/removal of domains and application partitions.

Three exist in every domain:

  • PDC Emulator: priority password-change handling, time hierarchy, policy editing affinity and several compatibility/administrative behaviours.
  • RID Master: allocates RID pools used to create unique security identifiers.
  • Infrastructure Master: maintains certain cross-domain references, with reduced work where every DC is a GC or Recycle Bin changes the update model.

A short outage of some roles does not immediately stop all sign-ins. Diagnose the actual failed operation and holder health before moving anything.

Place for reliability and recovery

Microsoft recommends consistently available role holders in reliable network locations and identified standby DCs. Record a preferred holder and standby for forest roles and each domain’s roles.

Consider:

  • DC health, patching and backup;
  • DNS and Global Catalog availability;
  • network/site reliability;
  • time-source design for the forest-root PDC Emulator;
  • operational load; and
  • who can perform role-specific changes.

For a single-domain forest, Microsoft recommends making all DCs Global Catalog servers. In multi-domain forests, GC placement follows logon, application and WAN requirements. The Infrastructure Master caveat matters when not every DC is a GC; record the actual forest design rather than applying an old slogan.

Transfer during planned work

A transfer asks the current healthy holder to hand the role to another DC. Use it for maintenance, demotion or deliberate placement changes.

Before transfer:

  1. confirm the current holder from more than one read path;
  2. prove bidirectional replication and time/DNS health between old and new holders;
  3. verify the target is writable, supported, correctly sited and backed up;
  4. identify applications/dependencies, especially PDC time and GC use; and
  5. capture before-state and rollback plan.

Transfer one coherent role set in the approved window and read back the owner from multiple DCs after replication.

Seize only when the old holder will not return

Seizure assigns a role without cooperation from the old holder. It is for a permanently failed or unrecoverable DC, not a temporarily unreachable server.

Before seizure, establish:

  • the original holder cannot be restored in time or safely reconnected;
  • its services and network access are contained;
  • the target DC is healthy and current;
  • the business impact justifies the action; and
  • the former holder will be rebuilt or demoted/metadata-cleaned before any return.

Never power the former holder back on unchanged after seizure. Two machines believing they own critical state can create duplicate or inconsistent operations, especially around RID issuance.

Use Microsoft’s current PowerShell or ntdsutil procedure for the installed Windows Server versions. Avoid a generic copied command that moves every role to whichever DC name was easiest to type.

Validate each role by its work

Role ownership read-back is necessary, not sufficient.

  • PDC Emulator: verify time hierarchy, urgent password-change behaviour and policy-management paths.
  • RID Master: inspect RID health/events and prove controlled creation of synthetic security principals without exhausting pools.
  • Infrastructure Master: verify cross-domain reference behaviour for the actual GC/Recycle Bin design.
  • Domain Naming Master: validate directory health; test domain/partition change only in a lab, not as production proof.
  • Schema Master: validate ownership/replication; never make a production schema change solely to test it.

For GC changes, verify advertising, DNS locator records, forest-wide queries, universal-group logon behaviour and dependent applications from affected sites before removing the old GC.

Finish the failed-controller work

If the move followed permanent failure, complete metadata and DNS cleanup, remove obsolete replication/DFSR references and reconcile backups, monitoring, time, DHCP/DNS and application dependencies. Confirm all DCs agree on role holders.

The goal is not to collect five role names on one server. It is to keep singular directory operations and forest-wide lookup reliably available, with a known standby and a recovery path that does not revive the failed owner.