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.
\nThe 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.
\nMicrosoft 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.
\n\nBuild 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.
\nSchedule 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.
\nFinally, 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.
\n\n