Raise Active Directory functional levels only after every domain controller earns the change

Source facts: functional level governs domain-controller compatibility

Microsoft’s AD DS functional-level documentation says forest and domain functional levels determine available Active Directory Domain Services capabilities and which Windows Server versions may run as domain controllers. They do not determine the operating systems allowed on ordinary member servers or workstations.

The current interoperability table draws a consequential boundary. At the Windows Server 2025 forest and domain functional level, Windows Server 2025 is the supported domain-controller operating system. Windows Server 2016, 2019, and 2022 domain controllers can coexist at the Windows Server 2016 functional level, and Microsoft notes that Windows Server 2019 and 2022 did not introduce newer functional levels of their own. A domain functional level may be higher than its forest functional level, but it cannot be lower than the forest functional level.

Microsoft identifies optional 32K database pages as a capability associated with the Windows Server 2025 domain functional level. That feature is not a reason to skip compatibility work: it has its own planning and enablement requirements. Microsoft also states that domains at the Windows Server 2016 functional level must use DFS Replication for SYSVOL. The documented PowerShell controls for raising levels are Set-ADDomainMode and Set-ADForestMode.

A domain-controller operating-system upgrade, schema preparation, adding or replacing a controller, and raising a functional level are related but separate changes. Microsoft’s domain-controller upgrade guidance generally favors adding newer servers as domain controllers, moving roles and dependencies, and demoting older controllers rather than treating the functional-level command as the migration itself.

DSE recommendation: require an identity-service readiness packet

Build one packet for the forest and one for every domain before scheduling the change. The packet should be understandable to the person making the go/no-go decision and useful to the person responding if an application fails later.

1. Inventory the topology. Record every domain, site, subnet, domain controller, global catalog, writable or read-only role, operating-system version, FSMO role, DNS role, replication connection, and time source. Reconcile the inventory with live directory data.
2. Apply the compatibility gate. Compare every domain controller with Microsoft’s table for the intended level. Find offline, isolated, lab-connected, recovery, or forgotten controllers—not just servers that appear in the main management console.
3. Prove directory health. Review replication across every naming context and site, DNS registration and resolution, SYSVOL and NETLOGON availability, DFSR state, time synchronization, event logs, backup status, and monitoring. Resolve unexplained errors before the change.
4. Map consumers. Test applications and appliances that use LDAP, Kerberos, DNS, service accounts, directory searches, federation, certificate services, identity synchronization, or hard-coded domain-controller addresses. Record owners and representative workflows.
5. Prove recovery. Verify system-state protection and perform a documented recovery exercise appropriate to the environment. Identify Directory Services Restore Mode access, authoritative and non-authoritative restore procedures, console access, media, and escalation ownership.
6. Remove old controllers cleanly. Transfer or seize roles only through an approved plan, update dependent systems, demote supportedly, remove stale metadata when required, and confirm replication convergence before declaring the old version absent.

Schedule the domain-level and forest-level raises as explicit changes after the platform migration has stabilized. Capture the before-and-after values, operator, commands or console actions, timestamps, replication results, DNS and sign-in tests, application checks, and monitoring state. Avoid bundling the raise with controller replacement, network work, certificate changes, or identity-sync upgrades unless the combined recovery plan has been deliberately tested.

Finally, distinguish “eligible to raise” from “benefit approved.” The newest functional level should support a documented requirement or lifecycle plan. The safe outcome is a fully understood directory on compatible controllers with verified recovery—not a higher number displayed in an administration tool.

Official references

• Microsoft Learn, Active Directory Domain Services functional levels, October 30, 2025.
• Microsoft Learn, Upgrade domain controllers to a newer version of Windows Server.