Build a new Windows Server 2025 Active Directory forest
Plan, promote, harden, validate, and back up a new two-controller Windows Server 2025 forest without exposing credentials or treating a VM snapshot as directory recovery.
Create a production-ready forest root whose namespace, compatibility, privileged boundary, DNS, sites, replication, time, security telemetry, and recovery evidence are understood before users or applications depend on it.
- Windows Server 2025
- Active Directory Domain Services 2025
- Windows PowerShell 5.1
- Approved forest design A unique controlled DNS namespace, NetBIOS name, business/security owner, trust and hybrid direction, controller lifecycle, and decommission authority.
- Two clean Windows Server 2025 hosts Patched fixed-address systems on independent failure domains, with healthy supported storage/hypervisor integration and no application roles.
- Tier-0 administration Trusted administrative workstation, separate privileged identities, audited console/out-of-band access, and no general browsing or email on controllers.
- Network and time Approved AD/DNS/management/backup flows, internal DNS bootstrap, stable routing, initial site/subnet plan, and an authoritative organizational time design.
- Recovery Protected system-state destination, DSRM escrow, backup ownership, isolated restore environment, and a written forest recovery and decommission plan.
- Change controls A maintenance window, peer-reviewed commands, service acceptance criteria, rollback boundaries, monitoring, and incident escalation.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A new Windows Server 2025 forest root domain with two writable, DNS-capable global catalog domain controllers in defined Active Directory sites.
- A documented Tier-0 operating boundary, functional-level decision, time hierarchy, DNS dependency, replication topology, acceptance record, and tested system-state backup.
- A repeatable promotion and verification path that keeps DSRM and domain credentials out of command history, process arguments, transcripts, and example output.
- Both controllers advertise LDAP, Kerberos, DNS, global catalog, SYSVOL, and NETLOGON services and replicate every naming context without unresolved errors.
- Clients can discover the appropriate site and controller using DNS SRV records rather than hard-coded host names.
- Operators can distinguish supported demotion, controller recovery, and forest recovery and have a current, protected backup before identity workloads are onboarded.
Architecture
How the parts fit together
The design uses one forest and one root domain. Two clean Windows Server 2025 hosts run AD DS and Microsoft DNS on separate failure domains. AD-integrated directory partitions replicate DNS and identity data, while sites and subnets direct clients toward local services. The PDC emulator is the authoritative domain time root and follows the approved external time design. No general application workloads, browsing, or internet-facing services run on the controllers.
- A domain client queries only approved internal DNS and obtains site-aware SRV records for Kerberos, LDAP, and global catalog.
- The client authenticates to an available controller; changes are committed locally and replicated through the AD topology.
- DNS application partitions, domain data, configuration, schema, and SYSVOL converge between controllers before acceptance.
- Health evidence and system-state backups leave the controllers through controlled management and backup paths, not general internet access.
Assumptions
- This creates a genuinely new forest. It does not migrate an existing directory, reuse a retired namespace, establish trusts, or configure hybrid identity.
- Both servers run fully patched Windows Server 2025 with fixed addresses, stable names, supported firmware/hypervisor integration, healthy storage, and console access.
- The example selects the Windows Server 2025 forest and domain functional level only when every planned domain controller is Windows Server 2025. Mixed-version deployments must select the highest level supported by all controllers.
- Network, DNS namespace, PKI, privileged-access, monitoring, backup, disaster-recovery, and ownership decisions are approved before promotion.
- Commands run from an elevated PowerShell session on the named host. Prompts collect credentials interactively; production values must not be pasted into tickets or shell transcripts.
Key concepts
- Forest
- The top AD DS security and schema boundary. A forest compromise affects trust in every domain, so creating one is an organizational security decision, not only a server-role installation.
- Domain controller
- A server hosting a writable directory database and identity protocols. Controllers are peers for most replication, but flexible single-master operation roles assign selected duties.
- Functional level
- A compatibility contract that controls available AD DS capabilities and the oldest permitted controller generation. Windows Server 2025 level admits only Windows Server 2025 controllers.
- DSRM
- Directory Services Restore Mode is an offline recovery identity on each controller. Its password is sensitive, controller-specific recovery material and is not a routine domain administrator password.
- Global catalog
- A service holding a partial replica of objects across the forest for logon and search. Both controllers are global catalogs in this single-domain design.
- Site and subnet
- AD topology objects mapping IP networks to physical locations so clients select nearby controllers and replication can follow designed links.
- SYSVOL
- The replicated tree containing Group Policy and logon files. A controller is not accepted until DFSR completes initial synchronization and SYSVOL/NETLOGON are shared.
- System state
- A supported backup set containing AD DS and other critical system components. It participates in controller and forest recovery but does not replace a tested full recovery plan.
Before you copy
Values used in this guide
{{adDomainFqdn}}Approved routable or delegated internal forest root DNS name; avoid an unowned public suffix and single-label names.
Example: corp.example.com{{adNetbios}}Approved short domain label, unique in the environment and at most 15 characters for broad compatibility.
Example: CORP{{dcOneFqdn}}Fully qualified name of the first domain controller.
Example: dc01.corp.example.com{{dcTwoFqdn}}Fully qualified name of the second domain controller.
Example: dc02.corp.example.com{{adSiteName}}Initial Active Directory site for the server subnet.
Example: HQ-WAW{{adSubnet}}CIDR network mapped to the initial AD site.
Example: 10.20.0.0/24{{backupTarget}}Approved system-state destination represented as a drive target for wbadmin; protect it outside the controller's failure domain.
Example: E:Security and production boundaries
- Administer controllers only from trusted privileged-access devices with separate Tier-0 identities. Do not browse the web, read email, or install general agents on a controller.
- Keep DSRM, recovery, backup, and domain credentials in approved secret-management and break-glass processes. Interactive prompts prevent casual command-history leakage but do not replace session security.
- Restrict controller network paths to documented AD, DNS, time, management, monitoring, and backup flows. A blanket firewall disable is not a diagnostic step.
- A compromised writable controller can invalidate trust in the forest. Preserve security telemetry and invoke the identity incident and forest-recovery plan rather than merely rebuilding one VM.
Stop before continuing if
- Stop before promotion if the namespace, ownership, functional level, privileged model, console recovery, backup destination, or decommission plan is undecided.
- Stop if either host uses dynamic addressing, public DNS, shared application workloads, unsupported storage/snapshots, or an untrusted administrative path.
- Stop before promoting DC02 unless DC01 passes DNS, SYSVOL, advertising, services, replication baseline, and event-log review.
- Stop onboarding users and services if dcdiag, repadmin, DNS SRV, time, SYSVOL/NETLOGON, or system-state backup acceptance is incomplete.
- Stop any rollback that proposes deleting directory files, removing the AD DS role from a promoted server, or reverting a VM snapshot.
decision
Approve the forest boundary, namespace, and functional level
Record the forest owner, business purpose, DNS namespace, short name, data residency, controller lifecycle, trust/hybrid direction, and decommission authority. Use the Windows Server 2025 functional level only when all planned controllers are Windows Server 2025; otherwise select the highest interoperable level before any promotion.
Why this step matters
A forest is a durable security, schema, configuration, and administrative boundary. Renaming, merging, or deleting it later is not an ordinary server change, while a functional-level decision constrains controller versions.
What to understand
Use a DNS suffix the organization controls and can delegate. Avoid single-label domains and names that collide with public or existing private namespaces.
Document whether this is a dedicated resource forest, corporate identity forest, lab, or migration target and who can authorize schema, trust, and recovery operations.
The Win2025 level provides Windows Server 2025 features but excludes older controllers; compatibility outranks novelty.
System changes
- This step changes governance records only. The displayed PowerShell emits the chosen values for a peer-reviewed change record and makes no directory change.
Syntax explained
adDomainFqdn- The canonical DNS and Kerberos realm basis for the new forest root domain.
adNetbios- The short domain label used by legacy DOMAIN\user syntax and compatibility paths.
Win2025- The documented Windows Server 2025 forest/domain functional level, suitable only for Windows Server 2025 controllers.
Values stay on this page and are never sent or saved.
'{{adDomainFqdn}}','{{adNetbios}}','Win2025' | ForEach-Object { $_ }corp.example.com CORP Win2025 Architecture decision: ADR-AD-001 approved Forest owner: Identity Operations Recovery owner: Infrastructure Resilience
Checkpoint: Verify this layer before continuing
Continue whenThe approved record has unique names, accountable owners, supported controller versions, recovery authority, and an explicit nonproduction rehearsal.
Stop whenStop if any namespace is unowned, overlaps another environment, violates naming policy, or if older controllers may be required.
If this step fails
Reviewers cannot agree whether the directory is authoritative or temporary.
Likely causeThe business boundary, migration plan, or ownership model is incomplete.
List systems expected to join, authenticate, publish DNS, or synchronize identities.Identify who can approve schema, trusts, privileged roles, and forest recovery.
ResolutionResolve governance and lifecycle decisions in an architecture review before provisioning controllers.
Security notes
- Treat namespace and forest topology as sensitive infrastructure information in public documentation.
Alternatives
- For temporary testing, create an isolated disposable lab forest with no production trust or data.
Stop conditions
- Stop if any namespace is unowned, overlaps another environment, violates naming policy, or if older controllers may be required.
verification
Validate clean hosts, static networking, time, storage, and recovery access
On each unpromoted Windows Server 2025 host, verify fixed addressing, stable host name, approved DNS bootstrap, correct UTC/time source, current patches, healthy volumes, no pending role conflict, separate failure domains, and working console access. Capture evidence before installing AD DS.
Why this step matters
AD DS binds identity to host name, address, DNS, time, storage, and recovery paths. Correcting these after promotion is riskier and can create silent replication or authentication defects.
What to understand
Place the two controllers on independent compute/storage and maintenance boundaries; redundancy on one failed host or array is cosmetic.
Use static addresses and stable names. The first forest controller may bootstrap to itself as DNS during promotion, while the second must initially use the healthy first controller.
Keep the time source and virtualization integration design explicit. Kerberos depends on bounded clock skew.
System changes
- The commands read operating-system, interface, time, and volume state. They do not expose passwords, but internal addresses and host names should remain within the change record.
Syntax explained
Get-ComputerInfo- Confirms supported product, build, and computer identity before promotion.
Get-NetIPConfiguration- Shows address, gateway, interface, and DNS client state for peer review.
w32tm /query /status- Reports current time synchronization source and health without changing configuration.
Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber,CsName; Get-NetIPConfiguration; Get-TimeZone; w32tm /query /status; Get-Volume | Select-Object DriveLetter,FileSystem,HealthStatus,SizeRemainingWindowsProductName : Windows Server 2025 Datacenter WindowsVersion : 24H2 OsBuildNumber : 26100 CsName : DC01 IPv4Address : 10.20.0.10 IPv4DefaultGateway : 10.20.0.1 TimeZone : (UTC) Coordinated Universal Time Leap Indicator : 0(no warning) Source : time-gateway.corp.example DriveLetter FileSystem HealthStatus SizeRemaining C NTFS Healthy 96.4 GB
Checkpoint: Verify this layer before continuing
Continue whenBoth hosts are current Windows Server 2025 systems with healthy fixed networking, time, storage, out-of-band access, and independent failure domains.
Stop whenStop for DHCP addressing, unresolved time warning, unsupported build/hypervisor, storage errors, missing console access, or shared single points of failure.
If this step fails
The server reports a public DNS resolver or APIPA address.
Likely causeNetwork bootstrap was copied from a general-purpose server rather than the directory design.
Review Get-DnsClientServerAddress and the interface metric.Resolve the planned internal namespace explicitly against the bootstrap resolver.
ResolutionAssign the approved fixed address and internal bootstrap DNS, then repeat connectivity and time checks before installing roles.
Security notes
- Do not reuse a server that hosted untrusted applications; controllers should start from a hardened clean image.
- Protect console and hypervisor administration at the same trust level as domain administration.
Alternatives
- Use physical controllers when virtual platform trust or failure isolation cannot meet the identity boundary.
Stop conditions
- Stop for DHCP addressing, unresolved time warning, unsupported build/hypervisor, storage errors, missing console access, or shared single points of failure.
command
Install AD DS management binaries without promoting
Install the AD Domain Services role and management tools on DC01, inspect the feature result, and restart only if the feature manager explicitly requires it. Role installation stages binaries; it does not yet create a forest or make the host a controller.
Why this step matters
Separating binary installation from promotion creates a reviewable checkpoint: tools become available, but the irreversible directory boundary is not created until prerequisites pass.
What to understand
Use the in-box role and ADDSDeployment module that match Windows Server 2025 rather than downloading third-party promotion scripts.
Management tools provide Test-ADDSForestInstallation, deployment cmdlets, Active Directory cmdlets, dcdiag, and operational consoles.
A restart request must be honored before promotion so a pending component state does not contaminate prerequisite results.
System changes
- Adds the AD-Domain-Services role binaries and RSAT management components to DC01. It does not create NTDS.dit, SYSVOL, a domain, or directory credentials.
Syntax explained
AD-Domain-Services- The Windows Server role containing AD DS components.
-IncludeManagementTools- Adds supported PowerShell modules, command-line diagnostics, and consoles used for deployment and verification.
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools; Get-WindowsFeature AD-Domain-Services,RSAT-AD-Tools | Select-Object Name,InstallStateSuccess Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Active Directory Domain Services, ...}
Name InstallState
---- ------------
AD-Domain-Services Installed
RSAT-AD-Tools InstalledCheckpoint: Verify this layer before continuing
Continue whenFeature state is Installed, the command reports Success, and any required restart is completed before the next step.
Stop whenStop if feature installation fails, requests an unplanned source, reports a pending restart, or endpoint protection flags the image.
If this step fails
Install-WindowsFeature cannot find source files.
Likely causeThe server image lacks the matching component payload or its servicing source is unreachable.
Inspect DISM /Online /Cleanup-Image /CheckHealth and CBS logs.Verify the approved Windows Server 2025 feature source and servicing policy.
ResolutionRepair the component store or provide the matching trusted feature source; do not copy binaries from another build.
Security notes
- Do not add browsers, office tools, or unrelated management agents while preparing a controller.
Alternatives
- Use Server Manager to install the same in-box role if PowerShell execution policy or change procedure requires the GUI.
Stop conditions
- Stop if feature installation fails, requests an unplanned source, reports a pending restart, or endpoint protection flags the image.
verification
Run forest promotion prerequisite checks with an interactive DSRM secret
Create the promotion argument map, obtain the DSRM password as SecureString, and run Test-ADDSForestInstallation. Do not use SkipPreChecks, do not place a plaintext password in the script, and do not proceed on warnings until each is understood.
Why this step matters
The deployment module can test naming, permissions, network, DNS, storage, and role prerequisites before committing a new directory. A SecureString prompt keeps recovery material out of literal command text and examples.
What to understand
Use a unique, escrowed DSRM password for each controller according to recovery policy. DSRM is local recovery material, not the domain Administrator credential.
Explicit functional-level values make the compatibility decision visible. Omit them only when the documented defaults are deliberately accepted.
Save the sanitized test output with the change, but remove internal details before sharing outside the authorized audience.
System changes
- The test performs discovery and validation but does not install the forest. The SecureString remains in the PowerShell process until the session ends or the variable is removed.
Syntax explained
Test-ADDSForestInstallation- Runs the prerequisite checks for a new forest without performing promotion.
-DomainMode/-ForestMode Win2025- Select the Windows Server 2025 compatibility level for both domain and forest.
-InstallDns- Plans installation and configuration of Microsoft DNS with the first controller.
-SafeModeAdministratorPassword- Supplies the interactively collected DSRM SecureString without exposing the password as a literal.
Values stay on this page and are never sent or saved.
$dsrm = Read-Host 'Enter the unique DC01 DSRM password' -AsSecureString; try { $forest = @{ DomainName='{{adDomainFqdn}}'; DomainNetbiosName='{{adNetbios}}'; DomainMode='Win2025'; ForestMode='Win2025'; InstallDns=$true; SafeModeAdministratorPassword=$dsrm }; Test-ADDSForestInstallation @forest -ErrorAction Stop } finally { Remove-Variable dsrm,forest -ErrorAction SilentlyContinue }Message ------- Prerequisite checks completed. The operation is ready to proceed. No blocking prerequisite failures were found. Proposed domain: corp.example.com Proposed NetBIOS name: CORP Forest mode: Win2025 Domain mode: Win2025 DNS server installation: True
Checkpoint: Verify this layer before continuing
Continue whenThe prerequisite result is ready with no blocking findings, names and levels exactly match the approved record, and the DSRM secret is escrowed without plaintext exposure.
Stop whenStop on any warning or mismatch, any request to skip checks, or evidence that the secret was transcribed, logged, or reused.
If this step fails
The test warns that DNS delegation cannot be created.
Likely causeThe parent DNS zone is external, unavailable, or not intended to host an automatic delegation.
Confirm whether the forest root is a delegated child and who owns the parent zone.Resolve the proposed delegation and inspect the approved DNS architecture.
ResolutionCreate an approved parent delegation through its authoritative DNS process when needed, or document why no delegation is required; do not ignore the warning by habit.
Security notes
- Disable transcript capture or ensure the secure prompt cannot be intercepted by untrusted session tooling.
- Remove $dsrm after the deployment step and close the privileged session.
Alternatives
- Allow Install-ADDSForest to prompt for DSRM directly when the change procedure does not require a reusable argument map.
Stop conditions
- Stop on any warning or mismatch, any request to skip checks, or evidence that the secret was transcribed, logged, or reused.
command
Create the Windows Server 2025 forest and reboot DC01
Compare every explicit argument with the accepted prerequisite-test record, then invoke Install-ADDSForest from a trusted console. Let the cmdlet collect and confirm the DSRM password through its secure prompt, keep automatic prechecks enabled, and allow the normal reboot. This is the boundary-creating operation: after commit, treat the server and its hypervisor, backup, and administrators as Tier 0.
Why this step matters
Install-ADDSForest commits the new security boundary, creates the directory database and SYSVOL, installs/configures DNS, makes DC01 a global catalog, assigns FSMO roles, and restarts into domain-controller operation.
What to understand
Compare the explicit namespace and functional-level arguments with the saved prerequisite result immediately before approval. The command is self-contained, so it does not depend on variables from an earlier copied block.
Do not use -SkipPreChecks. The built-in precheck immediately before commit catches changes since the earlier test.
Keep console access throughout reboot because DNS, network, storage, or boot failure can make remote management unavailable.
System changes
- Creates the forest, root domain, AD database, schema/configuration/domain partitions, SYSVOL, DNS application partitions and zones, domain accounts, global catalog, FSMO ownership, and controller service registrations.
Syntax explained
Install-ADDSForest- Creates the forest and securely prompts for the DSRM password because no password literal is supplied.
-Force:$false- Preserves confirmation behavior instead of automatically accepting prompts.
Values stay on this page and are never sent or saved.
Install-ADDSForest -DomainName '{{adDomainFqdn}}' -DomainNetbiosName '{{adNetbios}}' -DomainMode Win2025 -ForestMode Win2025 -InstallDns -Force:$falseWARNING: The target server will be configured as a domain controller and restarted when this operation is complete. Operation result: Success Forest root domain: corp.example.com Domain controller: DC01 DNS installed: True Restart initiated: True
Checkpoint: Verify this layer before continuing
Continue whenDC01 restarts, accepts domain-controller logon through the approved console, and AD DS, DNS, DFSR, Kerberos KDC, and Netlogon start without unresolved critical events.
Stop whenStop if the command parameters differ from approval, prechecks fail, console is unavailable, promotion reports failure, or the host reboots into recovery/error.
If this step fails
The installation succeeds but remote login fails after restart.
Likely causeDNS or interface changes altered reachability, the login context changed to the new domain, or required management flows are blocked.
Use console access and verify IP configuration, routes, firewall profile, services, and login domain.Inspect promotion and System logs before changing network controls.
ResolutionRepair the precise network/service issue from the console, retain restrictive policy, and complete local acceptance before re-enabling remote administration.
Security notes
- From this point the host contains forest-wide credential material. Restrict administrators, backup operators, hypervisor operators, monitoring, and endpoint tooling accordingly.
- Never publish DCPROMO logs without reviewing internal names and failure detail.
Alternatives
- If the business still needs an abort path, stop before this step and preserve the unpromoted server snapshot/image; after commit use supported demotion or recovery, not role-file deletion.
Stop conditions
- Stop if the command parameters differ from approval, prechecks fail, console is unavailable, promotion reports failure, or the host reboots into recovery/error.
verification
Accept DC01 services, DNS records, SYSVOL, and forest metadata
After reboot, verify the forest/domain mode, FSMO holders, controller flags, required shares, services, DNS service-location records, and event logs. Run focused dcdiag tests locally before using DC01 as a replication source.
Why this step matters
A successful promotion message is not acceptance. AD clients depend on service advertisement, DNS SRV records, directory roles, SYSVOL, Netlogon, and consistent metadata, any of which can fail separately.
What to understand
Confirm the reported forest/domain levels instead of assuming the parameters were applied.
NETLOGON and SYSVOL shares prove essential publication, while dcdiag evaluates service registration and core dependencies.
Review Directory Service, DNS Server, DFS Replication, System, and Security events from boot through acceptance; a single green command does not erase critical events.
System changes
- These checks read directory, shares, DNS, and service health. The first controller remains the only writable copy, so no client onboarding occurs yet.
Syntax explained
Get-ADForest/Get-ADDomain- Shows functional modes, namespace, and initial FSMO placement.
Get-ADDomainController- Confirms controller site, global catalog status, and roles.
Resolve-DnsName -Type SRV- Queries the service-location record used for controller discovery.
dcdiag /test:*- Runs focused advertising, service, SYSVOL, and DNS diagnostics on DC01.
Values stay on this page and are never sent or saved.
Get-ADForest | Select-Object Name,ForestMode,SchemaMaster,DomainNamingMaster; Get-ADDomain | Select-Object DNSRoot,DomainMode,PDCEmulator,RIDMaster,InfrastructureMaster; Get-ADDomainController -Identity '{{dcOneFqdn}}' | Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles; net share; Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.{{adDomainFqdn}}; dcdiag /s:{{dcOneFqdn}} /test:advertising /test:services /test:sysvolcheck /test:dns /vName : corp.example.com ForestMode : Windows2025Forest SchemaMaster : dc01.corp.example.com DNSRoot : corp.example.com DomainMode : Windows2025Domain PDCEmulator : dc01.corp.example.com HostName : dc01.corp.example.com Site : Default-First-Site-Name IsGlobalCatalog : True Shares : NETLOGON, SYSVOL _ldap._tcp.dc._msdcs.corp.example.com SRV 0 100 389 dc01.corp.example.com Advertising : passed Services : passed SysVolCheck : passed DNS : passed
Checkpoint: Verify this layer before continuing
Continue whenFunctional modes, roles, global catalog, SYSVOL/NETLOGON, SRV records, services, dcdiag, and event review are all healthy.
Stop whenStop before creating sites or DC02 if any share, service, role, record, diagnostic test, or critical event remains unexplained.
If this step fails
The SRV query returns no records although DNS service is running.
Likely causeNetlogon has not registered records, the query targets the wrong suffix/server, or the zone/delegation is incomplete.
Inspect ipconfig /all, Get-DnsServerZone, nltest /dsregdns, and Netlogon/DNS events.Query the SOA and _msdcs zone explicitly against DC01.
ResolutionCorrect the zone/DNS client dependency and trigger supported registration, then repeat dcdiag DNS and SRV queries before promotion of another controller.
Security notes
- Acceptance output contains topology information; store it with restricted change evidence.
Alternatives
- Use Server Manager and Active Directory Administrative Center for a second independent visual review, while retaining command evidence.
Stop conditions
- Stop before creating sites or DC02 if any share, service, role, record, diagnostic test, or critical event remains unexplained.
command
Define the initial site and subnet before adding DC02
Rename the default site to the approved location when it is still unused, or create a new site, then map the authoritative client/controller subnet. Site names describe physical network topology, not departments; every production subnet should have a deliberate mapping.
Why this step matters
Site/subnet topology drives controller location and the replication graph. Defining it before adding DC02 ensures both controllers and clients advertise and discover services in the intended location.
What to understand
Rename the default site only in a new forest before other automation depends on its distinguished name.
Subnet objects use network CIDR, not an individual host address. Overlapping or missing subnets create ambiguous or default-site placement.
Future sites also need reviewed site links, costs, schedules, and bridgehead/network behavior; this single-site guide does not invent WAN topology.
System changes
- Renames or creates an AD replication site object and creates one subnet object in the Configuration partition. The change replicates to all controllers once DC02 exists.
Syntax explained
Rename-ADObject- Changes the default site's directory object name while the forest is new.
New-ADReplicationSubnet -Name- Creates the authoritative CIDR-to-site mapping.
-Site- Associates the network with the approved replication site.
Values stay on this page and are never sent or saved.
$defaultSite = Get-ADReplicationSite -Identity 'Default-First-Site-Name' -ErrorAction SilentlyContinue; if ($defaultSite) { Rename-ADObject -Identity $defaultSite.DistinguishedName -NewName '{{adSiteName}}' }; if (-not (Get-ADReplicationSubnet -Identity '{{adSubnet}}' -ErrorAction SilentlyContinue)) { New-ADReplicationSubnet -Name '{{adSubnet}}' -Site '{{adSiteName}}' -Location 'Primary datacenter' }; Get-ADReplicationSite -Filter *; Get-ADReplicationSubnet -Filter * | Select-Object Name,Site,LocationName ---- HQ-WAW Name Site Location ---- ---- -------- 10.20.0.0/24 CN=HQ-WAW,CN=Sites,CN=Configuration,... Primary datacenter
Checkpoint: Verify this layer before continuing
Continue whenThe intended site exists once, the subnet is nonoverlapping and mapped to it, and representative addresses resolve to the expected site design.
Stop whenStop if the subnet overlaps, covers routed locations with different latency, or if existing automation depends on the default site name.
If this step fails
New-ADReplicationSubnet reports that the object already exists.
Likely causeA previous design created the same or overlapping CIDR in the Configuration partition.
List all subnets with Get-ADReplicationSubnet and compare network ranges.Review site ownership and network source-of-truth before changing the object.
ResolutionCorrect the authoritative mapping through change control; do not create a more-specific workaround without understanding client routing.
Security notes
- Site topology reveals network layout and should be access-controlled as infrastructure data.
Alternatives
- Keep the default site name temporarily if dependencies exist, then perform a separately tested rename migration.
Stop conditions
- Stop if the subnet overlaps, covers routed locations with different latency, or if existing automation depends on the default site name.
command
Promote DC02 as a DNS-capable global catalog replica
Point DC02 at DC01 for DNS, install the AD DS role, obtain domain promotion credentials and a unique DSRM password interactively, run the prerequisite test, and promote into the approved site. Do not select a replication source until DC01 is healthy and reachable.
Why this step matters
A second writable controller removes the first server as a single point of identity, DNS, SYSVOL, and maintenance failure and proves that the new forest can replicate before clients depend on it.
What to understand
DC02 initially uses DC01 as DNS so it can locate the domain. After both DNS replicas pass acceptance, adapter preference can be designed to avoid single-server dependency.
Get-Credential and Read-Host -AsSecureString avoid literal secrets. Use a delegated promotion identity if the organization supports one and never print the credential object.
An explicit healthy replication source makes initial data provenance visible; it is not a reason to ignore topology after promotion.
System changes
- Installs AD DS binaries on DC02, creates a controller computer account and NTDS settings, replicates forest/domain/application partitions and SYSVOL, installs DNS, enables global catalog, and reboots.
Syntax explained
Test-ADDSDomainControllerInstallation- Validates additional-controller prerequisites without promotion.
-ReplicationSourceDC- Chooses the healthy controller used for initial replication.
-SiteName- Places DC02 in the approved AD site during promotion.
-NoGlobalCatalog:$false- Ensures the new writable controller is also a global catalog.
Values stay on this page and are never sent or saved.
$previousPreference = $ErrorActionPreference; $ErrorActionPreference = 'Stop'; $credential = Get-Credential -Message 'Enter the approved domain promotion identity'; $dsrm = Read-Host 'Enter the unique DC02 DSRM password' -AsSecureString; try { Install-WindowsFeature AD-Domain-Services -IncludeManagementTools; $replica = @{ DomainName='{{adDomainFqdn}}'; Credential=$credential; SafeModeAdministratorPassword=$dsrm; InstallDns=$true; SiteName='{{adSiteName}}'; ReplicationSourceDC='{{dcOneFqdn}}'; NoGlobalCatalog=$false }; Test-ADDSDomainControllerInstallation @replica; Install-ADDSDomainController @replica -Force:$false } finally { Remove-Variable credential,dsrm,replica -ErrorAction SilentlyContinue; $ErrorActionPreference = $previousPreference; Remove-Variable previousPreference -ErrorAction SilentlyContinue }Feature installation: Success Prerequisite checks completed: ready Source domain controller: dc01.corp.example.com Target site: HQ-WAW DNS server: True Global catalog: True Domain controller promotion: Success Restart initiated: True
Checkpoint: Verify this layer before continuing
Continue whenDC02 reboots, shares SYSVOL/NETLOGON, advertises as a DNS/global catalog controller in the correct site, and completes initial replication.
Stop whenStop if DC01 health degraded, DNS/time/ports fail, prerequisites warn, secrets appear in logs, or initial synchronization does not complete.
If this step fails
Promotion stalls during initial replication.
Likely causeDC01 cannot supply one naming context, DFSR is unhealthy, RPC is blocked, or the candidate loses DNS/time connectivity.
Preserve promotion and replication logs from both servers.Run repadmin /showrepl on DC01 and verify DNS/time/approved AD connectivity from DC02.
ResolutionRepair source health or connectivity, then resume only through supported promotion behavior; if necessary, perform supported demotion/metadata cleanup before retrying a clean candidate.
Security notes
- Use separate DSRM passwords and escrow records. Do not use Domain Admin credentials for unrelated administration after promotion.
- Place DC02 on a genuinely independent failure domain and protect its hypervisor/console equally.
Alternatives
- Add a controller in a second site when disaster-recovery objectives require geographic rather than only local redundancy.
Stop conditions
- Stop if DC01 health degraded, DNS/time/ports fail, prerequisites warn, secrets appear in logs, or initial synchronization does not complete.
verification
Prove replication, DNS, SYSVOL, controller location, and time hierarchy
Run forest-wide diagnostics after DC02 initial synchronization. Verify every naming context in both directions, DNS records from both servers, SYSVOL/NETLOGON, site-aware controller discovery, FSMO roles, and time. Test from a representative member/client network without changing its production configuration.
Why this step matters
Redundancy exists only when directory partitions, DNS, SYSVOL, discovery, and time all work across the pair. A server that is merely powered on can silently serve stale or incomplete identity data.
What to understand
repadmin largest delta and failure counts show replication recency and errors; retain the CSV for comparison without exposing it publicly.
dcdiag /e /c is intentionally comprehensive and can be noisy. Every failure must be understood rather than hidden by filtering.
nltest from the actual subnet proves site mapping and locator behavior, while w32tm confirms the PDC-rooted time design.
System changes
- The commands are diagnostic and do not force replication or alter roles. They may create temporary diagnostic files only if output redirection is added by the operator.
Syntax explained
repadmin /replsummary- Summarizes inbound/outbound replication failure count and maximum observed delta.
repadmin /showrepl * /csv- Produces per-partner, per-naming-context evidence suitable for controlled analysis.
dcdiag /e /c /v- Tests every controller with comprehensive verbose checks.
nltest /dsgetdc /force- Requests fresh controller location rather than relying on cached discovery.
Values stay on this page and are never sent or saved.
repadmin /replsummary; repadmin /showrepl * /csv; dcdiag /e /c /v; dcdiag /test:dns /e /v; Get-ADDomainController -Filter * | Select-Object HostName,Site,IsGlobalCatalog,IPv4Address; nltest /dsgetdc:{{adDomainFqdn}} /force; w32tm /monitorReplication Summary Start Time: 2026-07-28 15:00:00 Source DSA largest delta fails/total %% error DC01 00m:42s 0 / 10 0 DC02 00m:37s 0 / 10 0 Destination DSA largest delta fails/total %% error DC01 00m:37s 0 / 10 0 DC02 00m:42s 0 / 10 0 dcdiag enterprise tests: passed dcdiag DNS tests: passed DC01 HQ-WAW GlobalCatalog=True 10.20.0.10 DC02 HQ-WAW GlobalCatalog=True 10.20.0.11 Client site: HQ-WAW Time offset DC01/DC02: 0.021s
Checkpoint: Verify this layer before continuing
Continue whenAll naming contexts replicate with zero errors, diagnostics pass, both controllers advertise DNS/GC/SYSVOL, clients select the intended site, and time offset is within policy.
Stop whenStop onboarding if any error, excessive delta, missing share/record, wrong site, stale partner, duplicate SPN, or time warning remains.
If this step fails
repadmin reports zero failures but one largest delta is unexpectedly old.
Likely causeThe partition has no recent changes, the schedule/topology is wrong, or replication has stalled without a current failure.
Inspect /showrepl for each naming context and last success.Create only an approved harmless test object in a lab OU when change evidence is required, then observe convergence and remove it.
ResolutionCorrect topology/schedule or the stalled partner, prove fresh bidirectional convergence, and document why the previous summary appeared healthy.
Security notes
- Diagnostic output contains controller names, addresses, sites, directory paths, and sometimes object identifiers; protect it as security-sensitive operational evidence.
Alternatives
- Use Microsoft monitoring or an enterprise identity health platform for continuous evidence after this point-in-time acceptance.
Stop conditions
- Stop onboarding if any error, excessive delta, missing share/record, wrong site, stale partner, duplicate SPN, or time warning remains.
config
Establish secure controller operations and authoritative time
Apply the approved Windows Server 2025 domain-controller security baseline, restrict interactive and network administration, configure auditing/monitoring, and make the PDC emulator follow the authoritative organizational time source while other domain systems follow the hierarchy. Stage policy and test authentication before broad enforcement.
Why this step matters
Controllers are the forest's highest-value systems. Baseline hardening, privileged-path separation, audit forwarding, and reliable time protect the authentication service after functional acceptance.
What to understand
Apply Microsoft security baselines through versioned policy and a canary controller; compare deviations required by business protocols rather than disabling controls globally.
The forest-root PDC emulator is the time authority for the domain hierarchy and should use the approved organizational/external source; avoid competing hypervisor synchronization.
Monitor directory, DNS, DFSR, Kerberos, Netlogon, time, replication, privileged changes, backup, and endpoint security from a protected collection path.
System changes
- The shown commands only inventory roles, time, and services. The associated change deploys security policy, time configuration, auditing, and monitoring through the organization's controlled configuration system.
Syntax explained
(Get-ADDomain).PDCEmulator- Identifies the current domain time-root role holder rather than assuming DC01 forever.
w32tm /query- Displays effective time configuration and current synchronization state.
Get-Service- Confirms essential controller services and configured startup behavior.
$pdc = (Get-ADDomain).PDCEmulator; $pdc; w32tm /query /configuration; w32tm /query /status; Get-Service NTDS,DNS,Kdc,Netlogon,DFSR | Select-Object Name,Status,StartTypedc01.corp.example.com [TimeProviders] NtpClient (Local) Type: NTP Source: time-gateway.corp.example Stratum: 3 Name Status StartType NTDS Running Automatic DNS Running Automatic Kdc Running Automatic Netlogon Running Automatic DFSR Running Automatic Security baseline: DC-2025-v1 staged Critical audit forwarding: healthy
Checkpoint: Verify this layer before continuing
Continue whenThe PDC uses the approved time source, peers follow domain hierarchy, baseline exceptions are documented, critical logs reach protected monitoring, and test authentication remains healthy.
Stop whenStop policy rollout on authentication, LDAP, SMB/SYSVOL, DNS, replication, monitoring, or time regression, or any unexplained baseline exception.
If this step fails
A baseline setting breaks a legacy application bind.
Likely causeThe application depends on unsigned LDAP, weak TLS, NTLM, obsolete SMB, or undocumented service-account behavior.
Capture the exact protocol and controller event on a canary path.Inventory application owner, version, authentication method, and supported remediation.
ResolutionRestore the narrow previous setting on the canary under time-bounded exception, upgrade or reconfigure the application, and retest before broad enforcement.
Security notes
- Do not make domain controllers general management jump boxes.
- Restrict event access because authentication and directory audit data can reveal users, hosts, and security posture.
Alternatives
- Use a separate hardened monitoring collector and privileged access workstation so general tools do not execute on controllers.
Stop conditions
- Stop policy rollout on authentication, LDAP, SMB/SYSVOL, DNS, replication, monitoring, or time regression, or any unexplained baseline exception.
verification
Create and validate a supported system-state recovery point
Install Windows Server Backup if required, create a system-state backup of a healthy controller to the approved protected target, retain logs and catalog evidence, and schedule an isolated restore rehearsal. A successful backup command is not a recovery proof, and VM snapshots do not replace this process.
Why this step matters
A new forest is not production-ready until its identity data can be recovered from a trusted point. System-state backup captures supported controller components, but recovery still requires documented sequencing, protected credentials, and rehearsal.
What to understand
Back up a healthy writable controller regularly and retain copies outside the controller, hypervisor, site, and administrative failure domain according to policy.
Review wbadmin and VSS event logs, catalog the version, protect encryption keys and recovery credentials, and monitor age/capacity.
Rehearse authoritative and nonauthoritative recovery only in an isolated network using the Microsoft forest recovery process; never connect a restored test controller to production.
System changes
- Installs Windows Server Backup and writes a system-state backup plus catalog metadata to the approved target. It can consume significant I/O, storage, and backup privileges.
Syntax explained
Windows-Server-Backup- Adds the supported in-box backup capability used by wbadmin.
start systemstatebackup- Creates a VSS-aware backup of critical system state including AD DS on a controller.
-backuptarget- Chooses the approved protected destination; the example is a drive target, not an instruction to store the only copy locally.
-quiet- Runs without a confirmation prompt after the command and target have already been reviewed.
Values stay on this page and are never sent or saved.
Install-WindowsFeature Windows-Server-Backup; wbadmin start systemstatebackup -backuptarget:{{backupTarget}} -quiet; wbadmin get versionsSuccess Restart Needed Exit Code Feature Result
True No Success {Windows Server Backup}
Starting to back up the system state [2026-07-28 17:00]...
The backup of the system state successfully completed [2026-07-28 17:24].
Version identifier: 07/28/2026-15:00
Can recover: System State
Backup target: Protected volume E:
Restore rehearsal ticket: DR-AD-2026-03 scheduledCheckpoint: Verify this layer before continuing
Continue whenwbadmin reports successful system-state completion, get versions lists a recoverable catalog entry, monitoring tracks age, and an isolated restore rehearsal is scheduled and owned.
Stop whenStop acceptance if backup or VSS errors exist, the target shares a failure/security domain, recovery secrets are missing, or no isolated rehearsal can be performed.
If this step fails
The backup completes but no version appears in the catalog.
Likely causeThe target/catalog path is unavailable, the backup was pruned, or the operation did not include recoverable system state.
Inspect wbadmin get status/get versions and Windows Backup events.Verify target access, free space, retention, and VSS writer state without modifying the only copy.
ResolutionCreate a new supported backup to a healthy protected target and validate its catalog before relying on retention or removing older known-good copies.
Security notes
- Backup operators and repositories can extract directory secrets; secure them at Tier 0, encrypt them, and audit restore access.
- Never publish backup paths, catalogs, or recovery credentials in examples or tickets.
Alternatives
- Use an enterprise VSS-aware backup product that explicitly supports Windows Server 2025 AD DS and tested forest recovery, while retaining equivalent evidence.
Stop conditions
- Stop acceptance if backup or VSS errors exist, the target shares a failure/security domain, recovery secrets are missing, or no isolated rehearsal can be performed.
Finish line
Verification checklist
Get-ADForest | Select-Object Name,ForestMode; Get-ADDomain | Select-Object DNSRoot,DomainModeThe namespace matches approval and both modes are Windows Server 2025 when the all-2025 compatibility assumption is true.Get-ADDomainController -Filter * | Sort-Object HostName | Select-Object HostName,Site,IsGlobalCatalog,IPv4AddressDC01 and DC02 are writable global catalogs in the intended site with their approved fixed addresses.repadmin /replsummary; dcdiag /e /c; dcdiag /test:dns /e /vEvery naming context and controller passes with zero unresolved replication, DNS, advertising, services, or SYSVOL failures.nltest /dsgetdc:{{adDomainFqdn}} /force; Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.{{adDomainFqdn}}Fresh discovery selects an available controller in the correct site and both controllers appear in authoritative SRV data.wbadmin get versionsA recent protected version lists System State as recoverable and has a scheduled isolated restore rehearsal.Recovery guidance
Common problems and safe checks
Test-ADDSForestInstallation reports a DNS name, NetBIOS name, prerequisite, or network configuration failure.
Likely causeThe candidate name is invalid or already delegated, the server has a dynamic address, its primary suffix conflicts with the design, a reboot is pending, or prerequisite ports and storage are unavailable.
Save the complete prerequisite report and inspect Get-NetIPConfiguration, Resolve-DnsName, Get-PendingReboot evidence from the approved maintenance process, and free space on the planned database, log, and SYSVOL volumes.Confirm the chosen forest namespace and NetBIOS label against the authoritative naming record; do not discover a production name by probing or attempting promotion.
ResolutionCorrect the documented prerequisite rather than skipping prechecks. Repeat Test-ADDSForestInstallation until every blocking finding is removed and the generated plan matches the approved architecture.
The first domain controller restarts but AD DS, SYSVOL, NETLOGON, or the DNS zone is unavailable.
Likely causePromotion did not complete, the server booted with an incorrect address or DNS client setting, storage is inaccessible, or AD DS/DFSR/DNS logged a startup failure.
Use the console or approved out-of-band channel, inspect Server Manager and the Directory Service, DFS Replication, DNS Server, and System logs, and run Get-Service NTDS,DNS,DFSR,Netlogon.Read C:\Windows\debug\DCPROMO.LOG and DCPROMOUI.LOG without publishing credentials, internal addresses, or directory names outside the incident boundary.
ResolutionKeep the server isolated from client use, repair the specific boot, storage, address, or promotion error, and use the supported demotion/cleanup path if promotion did not commit cleanly. Never remove AD DS binaries or delete NTDS files manually.
The additional domain controller cannot locate the domain.
Likely causeIts DNS client points to a public resolver, the AD-integrated zone or SRV records are incomplete, routing/firewall rules block AD ports, or time differs enough to break Kerberos.
Resolve the domain SOA and _ldap._tcp.dc._msdcs SRV record explicitly against the first domain controller.Run Test-NetConnection for the approved AD flows, w32tm /query /status, nltest /dsgetdc, and dcdiag /test:dns on the existing controller.
ResolutionPoint the candidate only at authoritative internal DNS, correct time and approved connectivity, verify healthy SRV registration, and rerun the prerequisite test before attempting promotion again.
repadmin reports RPC unavailable, target principal name incorrect, or access denied.
Likely causeDNS maps a controller to the wrong address, clocks diverge, a firewall blocks RPC, duplicate SPNs exist, secure-channel state is broken, or replication credentials/topology are invalid.
Run repadmin /showrepl and /replsummary, Resolve-DnsName for both DCs, w32tm /monitor, and dcdiag /test:replications without resetting passwords or SPNs.Inspect Directory Service and Kerberos events and use setspn -X only as a read-only duplicate check.
ResolutionRepair name resolution, time, approved ports, or the duplicate identity according to the exact event and Microsoft procedure. Do not use broad firewall disabling or force synchronization across unresolved divergence.
SYSVOL and NETLOGON are not shared on the new controller.
Likely causeInitial DFSR synchronization is incomplete or failed, the replication partner is unhealthy, storage permissions are wrong, or the controller advertised before SYSVOL became ready.
Run net share, dcdiag /test:sysvolcheck /test:advertising, repadmin /showrepl, and inspect DFS Replication events including the initial-sync state.Verify that the source controller has healthy SYSVOL and NETLOGON shares before attributing the problem to the new controller.
ResolutionRestore healthy AD and DFSR replication and allow initial synchronization to complete. Use Microsoft-supported DFSR recovery guidance for a confirmed failure; never set undocumented registry flags copied from an unrelated incident.
Clients authenticate against an unexpected or distant domain controller.
Likely causeAD Sites and Services lacks the client subnet, the subnet maps to the wrong site, site-link topology is incomplete, or DNS records have not converged.
Use nltest /dsgetsite and /dsgetdc from a representative client and compare its address with Get-ADReplicationSubnet.Review site, subnet, and site-link objects and query site-specific SRV records against both DNS servers.
ResolutionCreate or correct the authoritative subnet mapping and site topology, allow replication and registration to converge, then retest clients without hard-coding a controller.
Kerberos authentication intermittently fails after deployment.
Likely causeThe PDC emulator or an upstream time source is incorrect, virtualization time competes with domain hierarchy, DNS returns stale addresses, or SPNs are duplicated.
Identify the PDC emulator with Get-ADDomain, then collect w32tm /query /configuration, /status, and /monitor output from both controllers and a client.Inspect Kerberos events, klist output, DNS A/SRV answers, and setspn -X without purging tickets until evidence is captured.
ResolutionCorrect the authoritative time hierarchy and DNS/SPN defect, wait for policy and replication, then renew test tickets in a controlled session. Do not weaken Kerberos or enable NTLM as a blanket workaround.
dcdiag reports advertising, services, or DNS failures only on one controller.
Likely causeThe controller has a local service, interface, firewall, DNS registration, or replication problem even though the other controller masks it for clients.
Run dcdiag /s against each controller separately, compare service state, ipconfig /all, registered records, event logs, and replication metadata.Temporarily direct a synthetic test client to each DNS server separately; do not change broad production DHCP options while diagnosing.
ResolutionRepair the unhealthy node and prove all tests locally before restoring it to normal client preference. Redundancy is not a reason to accept a silently broken controller.
System-state backup fails or completes without a usable recovery artifact.
Likely causeWindows Server Backup is missing, the target is unavailable or shares a failure domain, VSS writers are unhealthy, capacity is insufficient, or the backup was never tested.
Run wbadmin get status and get versions, vssadmin list writers, inspect backup events, and confirm that the destination is protected and access-controlled.Verify the backup catalog, retention, encryption, and documented recovery credentials without mounting or altering the only backup copy.
ResolutionRepair the VSS writer or destination, create a fresh supported backup, copy it according to the recovery policy, and perform an isolated restore rehearsal before declaring the forest recoverable.
A controller was reverted to a hypervisor snapshot or cloned incorrectly.
Likely causeAn operator treated a VM checkpoint as an AD backup, the platform lacks a reliable VM-Generation ID implementation, or a copied disk was started outside the supported cloning workflow.
Isolate the affected VM, preserve hypervisor and Directory Service events, compare invocation ID and replication health, and determine exactly which state transition occurred.Confirm whether supported VM-Generation ID safeguards activated; do not reconnect a questionable duplicate while investigating.
ResolutionEscalate as an identity incident and follow supported AD DS recovery, demotion, or forest-recovery guidance. A snapshot is not a substitute for system-state or full-server backup.
A privileged administrator credential may have been exposed on a domain controller.
Likely causeA general-purpose account or management agent was used on a Tier-0 system, interactive browsing occurred on the DC, or logs/scripts captured a secret.
Restrict access, preserve security and identity telemetry, identify the affected principal and sessions, and inspect privileged group and directory changes from a trusted administrative host.Do not paste sensitive command history, event payloads, or directory exports into external analysis systems.
ResolutionTreat domain-controller compromise as a forest-trust event: contain, rotate through the approved credential and KRBTGT recovery process when applicable, validate known-good backups, and follow the organization's incident plan.
The proposed rollback requires deleting the forest or restoring a snapshot.
Likely causeThe deployment was allowed to serve clients before acceptance, recovery boundaries were not documented, or the team is trying to reverse a distributed directory as if it were a stateless package.
Identify whether any principals, policies, trusts, applications, certificates, or clients now depend on the forest and whether both controllers are healthy.Review the approved demotion and forest recovery plan, backups, and ownership before any destructive action.
ResolutionStop. Keep a healthy forest available, remove only a failed additional controller through supported demotion when safe, or invoke the approved forest-recovery/decommission program. Never improvise deletion of NTDS, SYSVOL, DNS, or metadata.
Reference
Frequently asked questions
Should every new forest use the Windows Server 2025 functional level?
Only if every present and planned domain controller supports it. Microsoft documents that Windows Server 2025 functional level accepts Windows Server 2025 controllers; a mixed fleet requires a compatible lower level.
Is a hypervisor snapshot a rollback?
No. VM-Generation ID adds safeguards on supported platforms, but Microsoft still recommends VSS-aware backups and supported AD recovery. A snapshot is not a forest recovery strategy.
Recovery
Rollback
There is no safe instant rollback for a forest after identities or applications use it. Before promotion, discard the unpromoted host. During DC02 rollout, keep healthy DC01 and use supported demotion/metadata cleanup only after evidence review. For forest-wide loss or compromise, invoke Microsoft's forest recovery process using known-good backups; never delete NTDS/SYSVOL, remove role binaries, or revert arbitrary snapshots.
- Before AD-05, cancel the change, remove only staged role binaries if desired, and preserve the architecture findings; no forest exists yet.
- If DC01 promotion fails, isolate it, preserve DCPROMO and event evidence, and follow the supported failed-promotion/demotion procedure before reusing its name or address.
- If DC02 is unhealthy while DC01 remains accepted, stop client use of DC02 and perform supported demotion. Clean metadata only when normal demotion is impossible and documented prerequisites are met.
- Do not demote the last healthy controller, transfer/seize FSMO roles casually, delete DNS application partitions, or remove SYSVOL while dependencies exist.
- For corruption or compromise, isolate affected systems, choose a trusted backup point, and execute the official forest recovery plan in the documented domain order.
- Reintroduce rebuilt controllers and services only after DNS, replication, SYSVOL, time, security, and backup acceptance passes again.
Evidence