Functional level work begins with blocker discovery, not with the raise command.

Raising domain or forest functional levels is irreversible in practice for most environments, so every remaining legacy controller, application dependency, and trust assumption must be discovered before the change window.

Runbook note: Treat the raise decision as a governance gate: no functional-level change should proceed without application owner signoff, legacy-controller verification, and a documented rollback posture for adjacent services.

• Confirm every domain controller in the forest meets the minimum version requirements and that no staging, lab, or disconnected site still hosts an older controller.
• Inventory applications that depend on legacy LDAP behavior, old management tooling, or domain mode assumptions that were never retested after earlier upgrades.
• Review trust relationships, third-party identity sync tools, and line-of-business platforms that embed schema or capability assumptions.
• Collect executive stop criteria in case production validation exposes an application blocker that was missed in precheck review.

Command path:

• Get-ADForest | Select ForestMode,Domains
• Get-ADDomainController -Filter * | Select HostName,OperatingSystem
• Get-ADTrust -Filter *
• dcdiag /e /test:Advertising /test:Services

GUI path: Active Directory Domains and Trusts, Active Directory Users and Computers, and application owner inventories used for compatibility signoff.

Define exactly what must pass before the raise window opens.

A functional-level raise should have its own validation matrix covering authentication, management tooling, trusts, and application flows that historically depended on older directory behavior.

• Create a representative pilot list covering admin tools, service accounts, LDAP-backed applications, certificate enrollment, and cross-forest access.
• Decide how long compatibility evidence must remain clean after raising a test domain or lab before production is approved.
• Require application owners to test both normal operations and recovery tasks such as password resets, group membership changes, and delegated admin actions.
• Freeze schema extensions, identity cleanups, and trust redesign work during the same change window so failures remain attributable.

Command path:

• Get-ADOptionalFeature -Filter *
• repadmin /replsummary
• nltest /domain_trusts
• gpresult /r

GUI path: Change-control records, Active Directory Administrative Center, and trust-management consoles used to coordinate signoff.

The environment has to be clean before capability is raised.

Do not use a functional-level change to push through existing health debt. Replication, SYSVOL, DNS, and time-service issues need to be resolved first or post-change troubleshooting becomes ambiguous.

• Resolve replication failures, lingering warnings, stale domain-controller objects, and unresolved DNS registration issues before the raise.
• Verify SYSVOL state, DFSR health, secure-channel behavior, and GPO application from multiple sites.
• Confirm backups and recovery documentation are current so adjacent directory problems can be handled quickly if they surface afterward.
• Record the exact pre-change forest and domain mode values as part of the implementation evidence.

Command path:

• repadmin /showrepl * /csv
• dcdiag /e /c /v
• dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:HF-DC25-01 /rmem:HF-DC25-02
• Get-ADDomain | Select DomainMode

GUI path: Event Viewer, DFS Management, Group Policy Management, and AD Sites and Services for prechange health proof.

Sequence matters because the forest gate depends on domain readiness.

Raise each domain only after its controllers and applications pass, then raise the forest when every domain is complete. Keep the change quiet and observable rather than combining it with adjacent modernization tasks.

• Raise the domain functional level in one domain at a time if the forest spans multiple administrative or application boundaries.
• Validate admin consoles, trust operations, LDAP application binds, and password-management workflows immediately after each domain raise.
• Raise the forest level only after every domain has completed successfully and replication has converged.
• Document optional features you intend to enable later rather than bundling them into the same window.

Command path:

• Set-ADDomainMode -Identity corp.example.com -DomainMode Windows2016Domain
• Set-ADForestMode -Identity corp.example.com -ForestMode Windows2016Forest
• Get-ADDomain | Select DomainMode
• Get-ADForest | Select ForestMode

GUI path: Active Directory Domains and Trusts > right-click domain > Raise Domain Functional Level, then right-click Active Directory Domains and Trusts > Raise Forest Functional Level.

Prove the raise changed capability without breaking operations.

The first post-raise work is verification, not celebration. Applications, trusts, delegated admin flows, and backup or restore procedures all need clean evidence before the project can move on.

• Retest representative application paths, service-account operations, domain joins, and delegated administration tasks across at least two sites.
• Confirm replication remains healthy and that no delayed warnings appear in Directory Service, DFSR, or DNS logs.
• Enable optional directory features only after the environment has had a stable post-raise soak period.
• Publish the new capability baseline and any retired legacy tooling assumptions to the operations team.

Command path:

• repadmin /replsummary
• dcdiag /e /test:KnowsofRoleHolders /test:RidManager
• Get-WinEvent -LogName "Directory Service" -MaxEvents 100
• Enable-ADOptionalFeature -Identity "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target corp.example.com

GUI path: Event Viewer, Active Directory Administrative Center, and application validation runbooks used for final signoff.