Raise AD Functional Level Safely: Forest and Domain

Functional levels tell Active Directory which features it is allowed to use, and they are only raised once every domain controller runs an operating system that supports the new level. Many environments sit at Windows Server 2008 R2 or 2012 R2 level years after the last old DC was retired, which blocks features such as Privileged Access Management, Kerberos AES-only policies and, on Windows Server 2025, the new database page size. Raising the level is a one-line operation, but it is effectively irreversible, so the preparation matters more than the command.

Short answer: Confirm every DC in the domain runs Windows Server 2016 or later with Get-ADDomainController -Filter * | Select Name, OperatingSystem, confirm replication is clean, take a system state backup of two DCs, then run Set-ADDomainMode -Identity corp.example.com -DomainMode Windows2016Domain on the PDC emulator and, once every domain is done, Set-ADForestMode -Identity corp.example.com -ForestMode Windows2016Forest on the Schema Master. Windows Server 2025 adds a 2025 level that requires every DC to be 2025.

Understand which levels exist

Windows Server 2016 introduced the last functional level for several years; Windows Server 2019 and 2022 did not add new ones, so a domain running only 2019 or 2022 DCs tops out at the 2016 level. Windows Server 2025 introduces a new forest and domain level (Windows2025Domain / Windows2025Forest) that enables the 32 KB database page format and requires every DC in scope to be 2025. The functional level of a domain must be at least the forest level, and you cannot raise the forest until every domain in it has been raised first.

Check the current state:

Get-ADDomain | Select-Object DomainMode
Get-ADForest | Select-Object ForestMode, Domains
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem, Site

The OperatingSystem column is the gate. Any DC listed with an older version must be demoted or upgraded first, and any DC that has been offline long enough to be missing from the list should be checked with repadmin /showrepl to be sure it does not still exist as metadata.

Pre-flight checks

Do these on the day of the change, not the week before:

• Replication: repadmin /replsummary and dcdiag /e /test:replications must show no failures on any DC.
• FSMO holders: netdom query fsmo confirms the PDC emulator and Schema Master are online and reachable; the level change is written on those two DCs.
• SYSVOL: dfsrmig /getglobalstate should read “Eliminated”. FRS is not supported at 2016 level or above.
• Backups: take a system state backup of the PDC emulator and one other DC with wbadmin start systemstatebackup -backupTarget:E: and confirm repadmin /showbackup reflects it.
• Applications: check for anything that still relies on NTLMv1 or DES Kerberos; raising the level does not disable them directly, but it is the moment auditors will expect them gone.

Raise the domain level, then the forest

Run on the PDC emulator, as a Domain Admin for the domain level and an Enterprise Admin for the forest:

Set-ADDomainMode -Identity "corp.example.com" -DomainMode Windows2016Domain -Confirm:$false
Get-ADDomain | Select-Object DomainMode

Repeat for each child domain, then raise the forest:

Set-ADForestMode -Identity "corp.example.com" -ForestMode Windows2016Forest -Confirm:$false
Get-ADForest | Select-Object ForestMode

The same operation exists in the consoles: Active Directory Users and Computers » right-click the domain » Raise Domain Functional Level, and Active Directory Domains and Trusts » right-click the root node » Raise Forest Functional Level. The change replicates like any other attribute; wait for it to reach every DC before enabling features that depend on it. If you are going to the 2025 level, use Windows2025Domain and Windows2025Forest, and expect the command to refuse if any DC is not 2025.

What changes after the raise

Very little happens immediately; the raise is a permission slip rather than a switch. Features you can now enable include the Active Directory Recycle Bin (2008 R2+, see enable the Active Directory Recycle Bin), fine-grained password policies, DFSR SYSVOL, the Protected Users group and authentication policies (2012 R2+), and Privileged Access Management with the optional feature Enable-ADOptionalFeature 'Privileged Access Management Feature' (2016+). Once PAM is enabled it cannot be rolled back, which is the one thing that turns a reversible level change into a permanent one.

Verify and know your rollback window

Confirm with Get-ADDomain and Get-ADForest on two different DCs and check the Directory Service log for Event ID 2039 or similar informational entries confirming the new level. Rollback is possible only between 2008 R2 and 2016 levels, only downwards to a level still supported by every DC, and only while no optional feature that depends on the new level has been enabled. The command is the same cmdlet with the lower mode. A common pitfall is raising the level with a stale DC still present in metadata; the operation fails with “the functional level cannot be raised” until the leftover NTDS Settings object is removed as covered in transfer and seize FSMO roles.

Raise AD functional level at a glance

Official documentation: Active Directory Domain Services docs, Windows Server documentation.

Related guides: How to find the source of Active Directory account lockouts (Event ID 4740) · Configure NTP time sync for the PDC emulator and domain clients · Install and promote a Windows Server 2025 domain controller step by step.

Frequently asked questions