Windows Server 2016 End of Support: Active Directory Domain Controller Upgrade Before January 12, 2027

A Windows Server 2016 end of support Active Directory domain controller upgrade is a dated project with a fixed deadline, not a backlog item you can keep deferring. Microsoft's Windows Server team states plainly that "extended support for Windows Server 2016 will end on January 12, 2027", and the Microsoft Lifecycle entry for Windows Server 2016 confirms the product follows the Fixed Lifecycle Policy with an extended end date in January 2027. Mainstream support already ended in January 2022.

The uncomfortable part is rarely the domain controllers themselves. Most teams can schedule a DC rebuild. What blocks them is a short list of business-critical hosts and appliances that cannot be upgraded — and those hosts do not merely carry their own risk. Because Kerberos encryption defaults, functional levels and domain-wide hardening settings are properties of the domain, a handful of unpatchable machines pin the entire directory to their security level.

Windows Server 2016 End of Support: Active Directory Domain Controller Upgrade Deadline

Windows Server 2016 follows Microsoft's Fixed Lifecycle Policy, which commits to "a minimum of five years Mainstream Support" plus "an additional period of Extended Support for some products". The ten-year figure people quote comes from a different page: Microsoft describes the Windows Server Long Term Servicing Channel as having "a minimum of 10 years of support: five years for mainstream support and five years for extended support, which includes regular security updates". Extended support is the phase that still delivers security updates. Once it ends, that stops.

Microsoft's own framing of what end of support means for a server operating system is blunt: once products reach the end of support, "it also means the end of security updates and bulletins", a situation that "can cause security or compliance issues and put business applications at risk".

On February 25, 2026, Microsoft announced Extended Security Updates for Windows Server 2016. Those updates are delivered "through the Azure portal", and ESU "enabled by Azure Arc" is positioned as providing additional Azure benefits including licensing flexibility and Azure management capabilities. Microsoft's recommendation in the same post is to upgrade to Windows Server 2025 or migrate to Azure — ESU is framed as a bridge, not a destination.

For a domain controller specifically, the risk is not abstract. ANSSI's Active Directory checkpoint catalogue carries a dedicated finding titled "DC/RODC with an obsolete operating system", and describes it as domain controllers running "operating systems for which Microsoft no longer publish security updates. Thus, any new vulnerability found on these operating systems will stay exploitable." Its remediation is one line: "Migrate these obsolete operating systems as soon as possible, preferably to the last version of Windows."

Why One Legacy Host Holds the Whole Domain

This is the counter-intuitive part, and it is where most 2027 migration plans quietly fail.

Functional levels are gated by your worst domain controller

The forest and domain functional level determines which AD DS capabilities are available — and Microsoft's functional levels interoperability matrix makes the dependency explicit. A Windows Server 2012 R2 DC cannot run at the Windows Server 2016 functional level. A Windows Server 2016, 2019 or 2022 DC cannot run at the Windows Server 2025 functional level.

One surviving 2012 R2 domain controller therefore caps the entire domain at the 2012 R2 level, which costs you every capability introduced since — including the Windows Server 2016 domain-level features (automatic rolling of NTLM and other password-based secrets on accounts configured for Smart card required for interactive logon, support for allowing network NTLM when a user is restricted to specific domain-joined devices, and the fresh public key identity SID for Kerberos clients authenticating with the PKInit Freshness Extension) and the Windows Server 2025 level's 32k database pages optional feature.

ANSSI's checklist treats this as a graded defect in its own right, under "Insufficient forest and domains functional levels": the alert fires at its first maturity tier when the forest functional level is below Windows Server 2008 R2, at tier 3 below Windows Server 2012 R2, and at tier 4 below the Windows Server 2016 level. The stated rationale is that "using a weak functional level deprives the forest from important security features".

Legacy clients hold your Kerberos crypto hostage

The same mechanic applies to encryption. Microsoft's guidance on detecting and remediating RC4 usage in Kerberos explains that RC4 "is typically used in Windows environments when accounts or devices don't support stronger encryption types such as AES-SHA1" — and that when an account has no msDS-SupportedEncryptionTypes value, the KDC falls back to the domain-wide DefaultDomainSupportedEncTypes value.

That fallback is the trap. Loosening DefaultDomainSupportedEncTypes to keep one appliance working "changes the behavior of all accounts that don't have a value", in Microsoft's words. One host, one domain-wide regression. This is the same mechanism behind Kerberos RC4 fallback, and it is what keeps Kerberoasting economically viable: RC4-encrypted service tickets crack far faster offline than AES ones.

Windows Server 2025 closes the door entirely, and Microsoft's warning is worth quoting in full:

Read that last sentence again. A single RC4-only device does not just weaken the domain — it can force you to keep older domain controllers, which in turn caps your functional level, which in turn blocks the hardening you were trying to deploy. The dependency runs backwards from the appliance to the directory.

The RC4 default change has already shipped

This is not a future problem. KB5073381, which addresses CVE-2026-20833, rolled the change out in phases:

The rollback escape hatch is gone. If a legacy dependency was only working because of the old RC4 default, it is already broken or already carved out with an explicit exception.

Detection

Start with three inventories. None of them requires an agent, and all three are cheap enough to run weekly.

1. Operating system spread across computer objects. The operatingSystem attribute is populated by the machine itself at domain join and refreshed at startup, so it is a reasonable — if not authoritative — first pass:

Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemVersion, LastLogonDate |
    Where-Object { $_.Enabled -eq $true } |
    Group-Object OperatingSystem |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Cross-reference LastLogonDate: an obsolete OS that has not authenticated in a year is a cleanup task, not a migration blocker. Treat the ones that logged on this week as the real constraint. This complements the machine-identity review covered in the Active Directory computer objects attack surface — that article covers finding stale and dangerous machine objects; this one covers what to do when you cannot delete them.

2. Domain controller OS versions and current functional levels.

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem, OperatingSystemVersion, IsGlobalCatalog, Site

(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'msDS-Behavior-Version'

3. Actual RC4 usage. Microsoft publishes two open-source scripts, List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1, in the Kerberos-Crypto repository:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

To find accounts pinned to RC4 by configuration rather than by capability, query the attribute directly — decimal 4 is RC4 only:

Get-ADObject -Filter "msDS-SupportedEncryptionTypes -eq 4" -Properties msDS-SupportedEncryptionTypes |
    Select-Object DistinguishedName, ObjectClass

Remediation

Step 1 — Scope the exception per account, never per domain. Microsoft gives two options when an account falls back to the domain default, and only one of them is safe at scale: "Define the specific msDS-SupportedEncryptionTypes value in the account properties to ensure it isn't falling back to the DefaultDomainSupportedEncTypes value." Use that. Reserve the domain-wide value for tightening, not loosening — the registry path to enforce AES-SHA1 only is HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, value DefaultDomainSupportedEncTypes (REG_DWORD) set to 0x18.

Step 2 — Quarantine what you cannot upgrade. For each host that must survive past January 12, 2027:

1. Deny Tier 0 logon. No Domain Admin, no service account with domain-wide rights, no delegation, should ever authenticate to an unpatchable host.
2. Restrict it at the network layer to the specific ports and peers it actually needs.
3. Scope Kerberos etypes with a targeted GPO rather than a domain policy. In Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, set Network security: Configure encryption types allowed for Kerberos, scoped to the OU containing the legacy hosts only.
4. Enforce signing everywhere else, so the weak host cannot be used as a relay pivot — see SMB signing and LDAP signing.

Step 3 — Upgrade the domain controllers first, and cleanly. Microsoft is explicit about the method: "The recommended way to upgrade a domain is to use a clean OS install to promote new servers to DCs that run a newer version of Windows Server and demote the older DCs as needed. This method is preferable to upgrading the operating system of an existing DC." The documented sequence is: join the new server, install the AD DS role (which runs adprep automatically), promote it, move the FSMO roles with Move-ADDirectoryServerOperationMasterRole, then demote and remove the old DC.

# Locate the current FSMO holders before you move anything
Get-ADDomain | Format-List InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Format-List DomainNamingMaster, SchemaMaster

If you do choose an in-place upgrade instead, Microsoft requires you to "run adprep /forestprep and adprep /domainprep manually" — forestprep once per forest for each newer Windows Server version, domainprep once in each domain holding DCs you are upgrading, again per version.

Step 4 — Pick the right target. Per Microsoft's supported in-place upgrade paths, Windows Server 2016 can be upgraded in place, via installation media, to Windows Server 2019, 2022 or 2025. Windows Server 2012 R2 can go directly to Windows Server 2025, because "starting with Windows Server 2025, nonclustered systems can upgrade up to four versions at a time" — but cluster rolling upgrades still advance only one version at a time.

Step 5 — Raise the functional levels last. Only after the last legacy DC is demoted and removed. Note that this is largely one-way: forest functional level rollback is limited to returning to Windows Server 2012 R2 or Windows Server 2008 R2 from an upgrade of those levels, and domain-level rollback only exists when you raise to Windows Server 2016 with a forest level of Windows Server 2012 or lower.

🚨 Danger: Do not raise the functional level while an unsupported DC is still joined. Microsoft's guidance is that if the forest contains DCs at a functional level older than a new OS supports, "the installation is blocked" and those DCs "must be removed and the forest functional level raised to a version that's supported before you add newer Windows Server DCs to your forest."

Sequencing matters more than speed here. Quarantine, then upgrade DCs, then raise levels, then tighten crypto domain-wide. Doing it in any other order either breaks production or leaves you with a hardened-on-paper domain that still falls back to its weakest member — one of the recurring patterns in the most common Active Directory misconfigurations.

How EtcSec Detects This

EtcSec surfaces this exact dependency chain from a single read-only audit, without agents on the legacy hosts. COMPUTER_OS_OBSOLETE_NT, COMPUTER_OS_OBSOLETE_2008 and COMPUTER_OS_OBSOLETE_VISTA inventory the machine objects whose operating systems no longer receive security updates, ranked by whether they still authenticate. PR001_5_1_DC_OS_OBSOLETE isolates the far more serious case — a domain controller itself running an obsolete OS — because that is the check that determines whether your Tier 0 is patchable at all. ANSSI_R15_LOW_FUNCTIONAL_LEVEL reports the current forest and domain functional levels against the recommended baseline, so you can see immediately which legacy DC is capping the directory.

Read together, those checks answer the only question that matters before January 12, 2027: which specific hosts are holding the domain down, and what would actually break if you removed them. Re-running the audit after each remediation step proves the level moved — the approach described in auditing Active Directory security and proving remediation.