Forest and Domain Functional Levels in Active Directory: Theory

Functional levels are the rule book that determines what an Active Directory forest and the domains inside it can actually do. They lock the minimum Windows Server version your domain controllers can run, gate which features are available across the directory, and shape every upgrade plan from the day a domain is created until the last DC running an old OS is retired. They are not visible in the day-to-day — users do not notice them, member servers do not care — but they are the constraint underneath every “can we use this AD feature?” conversation.

This article is the theory companion to the practical “Check Active Directory Forest and Domain Functional Level” walkthrough. It covers what functional levels actually are, the relationship between forest mode and domain mode, the features unlocked at each level, the GUI and PowerShell ways to read the current state, and the pitfalls that bite teams who treat “raise functional level” as a one-click action.

What Functional Levels Actually Are

A functional level is a single integer attribute on either the forest object or a domain object in AD that says “the domain controllers serving this scope must run at least this version of Windows Server, and these features are therefore safe to use.” Two attributes, two scopes:

• Forest functional level — on the forest’s root partition; binds the whole forest. Sets the minimum Windows Server version any DC in any domain in the forest can run.
• Domain functional level — on each domain’s naming context; binds that one domain. Sets the minimum Windows Server version a DC for that specific domain can run.

Both attributes are integers (msDS-Behavior-Version): 0 = Windows 2000, 2 = Windows Server 2003, 3 = Windows Server 2008, 4 = Windows Server 2008 R2, 5 = Windows Server 2012, 6 = Windows Server 2012 R2, 7 = Windows Server 2016. Microsoft did not introduce a new functional level for Windows Server 2019 or 2022 — both run at the 2016 level. The 2016 functional level is the highest currently available, even on a forest of all-2022 DCs.

Critically, functional levels apply only to domain controllers. Workstations and member servers can run any supported Windows version regardless of what the forest or domain mode is set to. A Windows Server 2022 file server happily joins a domain at the 2008 R2 functional level; a Windows 11 client authenticates against a 2012 R2 domain without complaint.

Key Concepts

• Active Directory Domain Services (AD DS): the role on Windows Server that turns it into a domain controller. The directory database (ntds.dit), Kerberos KDC, LDAP server, and replication engine all live inside this role.
• Domain: a logical security boundary — one directory database, one Kerberos realm, one set of security policies, one or more DCs. Users, computers, groups, and OUs all live inside a domain.
• Forest: a collection of one or more domains that share a schema, configuration partition, and global catalog. The forest is the actual security and trust boundary; cross-forest authentication requires explicit forest trusts.
• Schema: the directory’s data model — the list of object classes (user, group, computer) and the attributes on each. Forest-wide; identical on every DC in every domain in the forest.
• Functional Level: the version-and-features setting we are discussing. Two flavours, forest and domain.

The Forest-Beats-Domain Rule

The forest functional level is the floor for every domain in the forest. The domain functional level cannot be lower than the forest functional level — AD enforces this when you raise the forest level. The relationship is:

domain functional level >= forest functional level

Concretely:

• If the forest is at Windows Server 2016, every domain must be at 2016 or higher. AD will not let you raise the forest to 2016 unless every domain inside it is already at 2016.
• If the forest is at Windows Server 2012 R2, individual domains can independently be at 2012 R2, 2016, or in theory anything newer — whichever the DCs in that specific domain support.

This is why functional-level upgrades are usually a two-phase process: first raise each domain to the new level, then raise the forest. Microsoft documentation calls out this ordering explicitly; PowerShell tools enforce it.

Why Raise the Functional Level

Three reasons, in roughly the order you encounter them:

• Feature availability. The Active Directory Recycle Bin, fine-grained password policies, and the offline domain join feature all require a 2008 R2 or higher forest mode. Authentication policies and silos require a 2012 R2 forest. Higher levels unlock newer security primitives without needing add-on products.
• Security. Newer functional levels include security improvements that previous levels could not safely assume. Protected Users (introduced at 2012 R2 domain mode) is a good example — it changes how Kerberos pre-authentication works for members of the group, and only DCs running 2012 R2 or newer know how to enforce it. The functional level is the lever that says “assume every DC understands the new behaviour.”
• Operating system support. Older Windows Server versions reach end-of-life and stop receiving security updates. To replace them you have to install newer versions; running a mix of old and new DCs is fine indefinitely, but eventually the old ones must go — and once they are gone you may as well raise the functional level to match the survivors.

Features by Level (Windows Server 2008+)

Every level inherits the features of the levels below it — running at 2016 means you have everything from 2008 through 2016 available.

Checking the Current Levels: GUI

The fastest GUI path is Active Directory Domains and Trusts (domain.msc):

1. Open Active Directory Domains and Trusts.
2. To check the forest mode, right-click the root Active Directory Domains and Trusts node in the left pane and pick Properties. The dialog shows the current Forest functional level.
3. To check a specific domain’s mode, right-click the domain (e.g. fortesting.local) and pick Raise Domain Functional Level…. The dialog shows both the current level and the highest level you can raise it to from this DC. Cancel out without changing anything.

For a single combined view, Active Directory Users and Computers → right-click the domain → Properties shows the domain functional level on the General tab. The forest functional level is not shown there — it lives in Domains and Trusts.

Checking the Current Levels: PowerShell

The PowerShell path is faster and scriptable. From any RSAT-equipped machine:

# Forest mode
Get-ADForest | Select-Object Name, ForestMode

# Every domain in the forest
Get-ADForest |
    Select-Object -ExpandProperty Domains |
    ForEach-Object {
        Get-ADDomain -Identity $_ |
            Select-Object Name, DomainMode, PDCEmulator
    }

Expected output for a single-domain forest at the 2016 level:

Name             ForestMode
----             ----------
fortesting.local Windows2016Forest

Name         DomainMode           PDCEmulator
----         ----------           -----------
fortesting   Windows2016Domain    test-dc1.fortesting.local

The ForestMode and DomainMode properties return enum values: Windows2003Forest, Windows2008Forest, Windows2008R2Forest, Windows2012Forest, Windows2012R2Forest, Windows2016Forest, and the matching Domain values.

Worked Example: Two Domains, Different Levels

A forest example.com with two child domains, headquarters.example.com and branch.example.com:

• Forest functional level: Windows Server 2012 R2. Forest-wide features available: AD Recycle Bin, Authentication Policies and Silos, Protected Users group. The forest cannot use Privileged Access Management features — those are 2016+ forest mode only.
• Domain functional level for headquarters.example.com: Windows Server 2016. Within this domain, PAM time-bound group membership is available. Every DC for this domain must run Windows Server 2016 or newer.
• Domain functional level for branch.example.com: Windows Server 2012 R2. Within this domain, only the 2012 R2 features are available; PAM is not. DCs for this domain can run 2012 R2 or newer (so a 2016 or 2022 DC is fine here, it just operates at the 2012 R2 level).

This pattern — one or more domains running at a higher level than the forest — is normal during a phased upgrade. The forest level only rises after every domain has crossed the new level.

SYSVOL Replication: FRS to DFS-R Migration

Forest functional level 2008 introduced DFS Replication (DFS-R) as the supported replication engine for the SYSVOL share that holds Group Policy and logon scripts. The older File Replication Service (FRS) was deprecated and is no longer supported on Windows Server 2012 or newer. Domains created at 2008 forest mode or higher use DFS-R automatically; domains upgraded from older forests still use FRS until you explicitly migrate.

Confirm which engine is in use:

dfsrmig /getglobalstate

Expected output on a healthy modern domain: Current DFSR global state: ‘Eliminated’ — FRS is gone and DFS-R is the only engine. Anything else (Start, Prepared, Redirected) means the migration is incomplete or never happened. Microsoft has a documented migration procedure (Start → Prepared → Redirected → Eliminated) that has to be completed before raising the domain to 2016 mode.

Best Practices

• Set the highest level your environment supports. When deploying a new forest, pick the highest forest mode the DCs will run. New forests on Windows Server 2022 should default to 2016 forest mode (the current ceiling) — there is no upside to choosing a lower level for a fresh deployment.
• Audit DC versions before raising. The functional-level dialog shows you the highest level achievable from the DC you are running it on, but does not check other DCs. Run Get-ADDomainController -Filter * first and confirm every DC meets the minimum OS requirement before raising. A single old DC blocks the raise.
• Decommission old DCs deliberately. “The 2008 R2 DC has been offline for two months, can we raise to 2016?” is a trap — the DC may still be in Get-ADDomainController’s output and AD will refuse the raise. Demote dormant DCs cleanly with Uninstall-ADDSDomainController before counting them gone.
• Plan upgrades carefully — raising is one-way. Functional level is generally not reversible. Microsoft introduced limited downgrade support starting at the 2008 R2 domain mode (provided AD Recycle Bin has not been enabled), but the official guidance is “you cannot downgrade.” Treat the raise as an irrevocable production change.
• Complete FRS → DFS-R first. If dfsrmig /getglobalstate reports anything other than Eliminated, finish that migration before raising the domain mode to 2016. Mixed FRS/DFS-R environments cannot raise.
• Schedule for a maintenance window. The raise itself is fast and does not interrupt authentication, but the replication of the change to every DC in the scope can take a full replication cycle. Plan for an hour of “watch this propagate” rather than a sub-minute change.

Common Misconceptions

• “Higher functional level means newer Windows Server clients.” No — the functional level only constrains domain controllers. A 2008 R2 forest can host every Windows version from XP through 11 as members.
• “Raising the forest to 2016 makes my 2022 DCs faster.” Also no. The functional level enables features; it does not change the runtime behaviour of operations that already work. A 2022 DC running at 2008 R2 forest mode performs identically to one running at 2016 forest mode for everything except the 2012-and-newer feature set.
• “If I never use AD Recycle Bin, the functional level does not matter.” Almost true, but newer security defaults (Kerberos AES, Protected Users, authentication policies) are tied to functional level even without explicit feature enablement. Stay current.
• “Functional level controls what schema extensions I can install.” Schema extensions are independent of functional level — they require schema admin rights and a forest schema update, not a particular functional level. Confusion comes from products like Exchange that have both schema and functional-level requirements.

Conclusion

The forest functional level is the floor; the domain functional level is the per-domain ceiling that sits at or above it. Both gate which Windows Server versions the DCs can run and which AD features are safely available. The day-to-day impact is small — users and member servers do not notice — but the level is a hard prerequisite for almost every modern AD feature, from Recycle Bin through Group Managed Service Accounts to Privileged Access Management. Audit the current state with Get-ADForest and Get-ADDomain, plan upgrades after every DC meets the new minimum, raise domains before forests, and keep the level current with the OS lifecycle of the DCs themselves. The follow-up Check Active Directory Forest and Domain Functional Level article covers the practical “what level am I at right now?” checks; the next article in this pathway will walk the actual Raise Domain Functional Level and Raise Forest Functional Level operations end to end.