Windows Server Release History: 2016 to 2025, Security and Support

Windows Server has had four Long-Term Servicing Channel releases since 2016: Windows Server 2016 (build 14393), 2019 (build 17763), 2022 (build 20348) and 2025 (build 26100). Each gets five years of mainstream support and five years of extended support. As of late October 2026, Windows Server 2016 has under three months of security updates left (extended support ends 12 January 2027), Windows Server 2022 left mainstream support on 13 October 2026, and Windows Server 2025 is the current release, supported until 14 November 2034.

The security story across those four releases moves in one direction: protections that were optional become defaults. Windows Server 2016 introduced virtualization-based security and Credential Guard as features you switched on. Windows Server 2022 turned on TLS 1.3 and added Secured-core server. Windows Server 2025 enables Credential Guard by default on capable hardware, requires SMB signing for outbound connections, stops issuing RC4 Kerberos tickets and ships OpenSSH server installed.

This post goes one level deeper than our Windows 11 version history, which covers the client side of the same code base. Every date and build below comes from Microsoft's own release information and lifecycle pages, fetched on 23 October 2026. Where two Microsoft pages disagree, we say so.

Key takeaways

• Four LTSC releases, one rule. Windows Server 2016, 2019, 2022 and 2025 all follow Microsoft's Fixed Lifecycle Policy: five years of mainstream support (security and non-security updates) and five years of extended support (security updates only).
• Windows Server 2016 is almost out. Extended support ends 12 January 2027. Microsoft's Extended Security Updates overview page, as fetched, lists only Windows Server 2012 and 2012 R2, whose three year ESU window closed on 13 October 2026.
• Windows Server 2022 is in extended support. Mainstream support ended 13 October 2026. Security updates continue until 14 October 2031.
• The Semi-Annual Channel is gone. It ran from version 1709 (October 2017) to version 20H2 and was retired in August 2022. Since September 2023 the alternative to LTSC is the Annual Channel, a Server Core only container host with 24 months of support.
• Defaults got stricter in 2025. Credential Guard on by default where hardware allows, outbound SMB signing required, an SMB authentication rate limiter on by default, no RC4 ticket granting tickets, LDAP sealing by default on new deployments, and NTLMv1 removed.
• Active Directory got its first new functional level since 2016. The Windows Server 2025 level (DomainLevel and ForestLevel 10) unlocks the 32k database page option. Windows Server 2019 and 2022 never had their own functional level.
• Server Core is still the smaller target. It drops the GUI shell packages, and you cannot convert between Server Core and Desktop Experience after installation.
• Windows Server 2025 can upgrade in place from up to four versions back, so Windows Server 2012 R2 can go straight to 2025. Earlier releases allowed two versions. For domain controllers, Microsoft recommends building new ones rather than upgrading old ones.
• The OS is only part of the patch surface. OpenSSH, curl, .NET, web stacks, runtimes and agents on a Windows Server host carry their own release cycles and their own CVEs.

Windows Server releases at a glance

Microsoft publishes the authoritative table on its Windows Server release information page, with each product's lifecycle page holding the formal dates. The lifecycle pages print timestamps in UTC (for example "1/12/2022 6:59:59 AM"), which is the end of the previous day in Redmond time. The dates below are the Pacific dates Microsoft uses on the release information page.

Three details in that table trip people up.

Windows Server 2016 has two start dates. The release information page lists its availability as 2016-08-02, which matches the version 1607 code base it shares with Windows 10. The Windows Server 2016 lifecycle page gives a start date of 15 October 2016. For support planning only the end dates matter, and both pages agree on those.

Windows Server 2019 was released twice. Microsoft's lifecycle page notes that Windows Server 2019 and version 1809 were re-released on 13 November 2018 and that support dates were adjusted accordingly. The re-release date is the one the lifecycle clock uses.

The build number is two numbers. The major build (14393, 17763, 20348, 26100) tells you the release. The number after the dot, called the update build revision (UBR), tells you which monthly cumulative update is installed. A server on 20348.5761 has the October 2026 update (KB5126655); a server on 20348.4893 stopped at March 2026. Comparing the UBR on each server against the release information page is the fastest patch audit you can run, and we show how in the walkthrough below.

Editions

The lifecycle pages list which editions each release covers:

The release information page lists only Datacenter and Standard for 2019, 2022 and 2025, and adds Essentials for 2016. The lifecycle page is the formal source for support, so use it when an Essentials or Azure Edition server is in scope.

The practical differences:

• Standard and Datacenter are the two general purpose editions and the only ones offered as both Server Core and Desktop Experience on every release in this post. Licensing and some datacenter features differ; check Microsoft's edition comparison for the release you buy.
• Datacenter: Azure Edition arrived with Windows Server 2022. It runs only as a virtual machine on Azure or Azure Local and was the first edition to get Hotpatch and the SMB over QUIC server.
• Essentials is listed on the lifecycle pages and follows the same support dates as the rest of its release.

Dated timeline: 2016 to 2034

If you remember one thing from the timeline: in the next 27 months, two of the four releases leave support entirely. Windows Server 2016 goes in January 2027 and Windows Server 2019 in January 2029, which is closer than it sounds once you account for budget cycles, hardware refresh and application testing.

What are the servicing channels: LTSC, Semi-Annual Channel and Annual Channel?

Microsoft's servicing channels page describes two current channels and the history behind them.

Long-Term Servicing Channel

The LTSC is what most people mean by "Windows Server". A new major version arrives every two to three years, each with five years of mainstream support and five years of extended support. You can install it as Server Core or Server with Desktop Experience, activate it with any Windows Server key and buy it through every licensing program. Windows Server 2016 used the older name Long-Term Servicing Branch (LTSB); the model is the same.

LTSC releases receive monthly cumulative updates on the second Tuesday (the "B" release in Microsoft's notation), optional non-security previews in the fourth week while in mainstream support (the "D" release), and out-of-band updates when something cannot wait. The release information page lists every one. Windows Server 2025, for example, received a regular update on 8 September 2026 and an out-of-band update on 14 September 2026.

Semi-Annual Channel, 2017 to 2022

The Semi-Annual Channel (SAC) shipped a new Windows Server version roughly every six months, each supported for 18 months. According to the SAC lifecycle page, the releases were:

The end dates above are converted from the UTC timestamps on the lifecycle page. SAC releases were Server Core only; the Windows Server 2019 what's new page says they did not include Desktop Experience by design and were "strictly Server Core and Nano Server container image releases". Microsoft retired the channel on 9 August 2022, and no SAC release followed 20H2.

Annual Channel, from 2023

Since September 2023 the second channel is the Annual Channel (AC), formally Windows Server Annual Channel for Containers. The servicing channels page sets out the rules:

• A new release roughly every 12 months, named for the half year it ships in (version 23H2 shipped in the second half of 2023).
• 24 months of support per release: 18 months mainstream plus 6 months extended.
• Server Core only, and only as a container host.
• Available only to volume licensing customers with Software Assurance and through Visual Studio subscriptions (for development and test).
• Activated with Datacenter keys; under KMS it uses the CSVLK of the last LTSC release before it.
• Moving to a new AC release is a clean installation, not an update.

The release information page names version 23H2 as the latest AC release. You cannot tell an AC host from an LTSC host by product name alone, because both report "Windows Server 2022 Datacenter". The display version gives it away: 21H2 for LTSC 2022 and 23H2 for the Annual Channel. That OSDisplayVersion field exists only on Windows Server 2022 and later; anything older is LTSC by definition.

Which channel should a server be on?

For almost every server that holds state, LTSC is the answer. The Annual Channel suits teams that already treat container hosts as disposable and rebuild them from automation.

What security features arrived in each release?

The four "what's new" pages on Microsoft Learn are the primary record. Below is what each release added for security, followed by a comparison table.

Windows Server 2016: virtualization-based security arrives

According to Microsoft's Windows Server 2016 what's new page, the release brought:

• Virtualization-based security (VBS) with Device Guard and Credential Guard. VBS uses the hypervisor to carve out an isolated region of memory. Credential Guard uses that region to isolate credential secrets that would otherwise sit in the memory of the normal OS, where a process with administrator rights could try to read them. Generation 2 virtual machines at configuration version 8 or later could use these features too.
• Code integrity policies (application control), letting administrators allow only signed or listed binaries to run.
• Shielded virtual machines and the Host Guardian Service, which encrypt a virtual machine's state and disks so a compromised or curious Hyper-V administrator cannot inspect or tamper with it.
• Just Enough Administration (JEA), PowerShell endpoints that give an operator only the specific commands their job needs instead of full administrator rights.
• Privileged access management for Active Directory, using a separate bastion forest and time limited group membership, configured through Microsoft Identity Manager.
• Nano Server, a headless, remotely managed installation option. By the Semi-Annual Channel era, Microsoft shipped Nano Server only as a container image.

The common thread is that all of these were options. A fresh Windows Server 2016 install did not turn on Credential Guard or code integrity enforcement for you.

Windows Server 2019: hardening the platform you already had

The Windows Server 2019 what's new page describes a release focused on making 2016's features easier to run:

• Exploit protection built in as a set of mitigations that replaced an older standalone toolkit, plus attack surface reduction rules and network protection as host intrusion prevention controls.
• Default code integrity policies that allow Windows in-box files and Microsoft applications, which made application control easier to start with.
• Shielded VM improvements: a fallback Host Guardian Service, an offline mode for hosts with intermittent connectivity, and support for Ubuntu, Red Hat Enterprise Linux and SUSE Linux Enterprise Server as shielded guests.
• Encrypted virtual networks in the software defined networking stack, using DTLS between virtual machines on subnets marked "Encryption Enabled".
• HTTP/2 improvements, including better server side cipher suite negotiation.
• OpenSSH available as a feature on demand for the first time on a server release, according to Microsoft's OpenSSH overview.

Windows Server 2019 is also the oldest server release that can run Windows LAPS, the built-in successor to the legacy LAPS add-on, once it has the 11 April 2023 update or later.

Windows Server 2022: Secured-core, TLS 1.3 and stronger SMB

The Windows Server 2022 what's new page is where hardware rooted security becomes a product line:

• Secured-core server. Certified hardware from OEM partners that combines a TPM 2.0 hardware root of trust, UEFI Secure Boot, Dynamic Root of Trust for Measurement (DRTM) to measure and verify the boot process, DMA protection to isolate driver access to memory, and VBS with hypervisor-protected code integrity (HVCI). Microsoft's Secured-core server page frames it as three pillars: a hardware backed root of trust, defense against firmware level attacks, and protecting the OS from running unverified code. It also sets TPM 2.0 and Secure Boot as the recommended baseline for every system and as requirements for Windows Server hardware certification.
• TLS 1.3 and HTTPS enabled by default. Microsoft's Schannel protocol table states that TLS 1.3 is supported starting in Windows 11 and Windows Server 2022, and that enabling it on earlier versions "is not a safe system configuration". Applications still have to support TLS 1.3 themselves to use it.
• DNS over HTTPS in the DNS client, which encrypts name resolution queries.
• SMB AES-256 encryption. SMB gained AES-256-GCM and AES-256-CCM cipher suites, negotiated automatically with peers that support them and mandatable by Group Policy, with AES-128-GMAC accelerating signing.
• East-west SMB encryption and signing for Cluster Shared Volumes and the storage bus layer inside failover clusters, and SMB Direct encryption over RDMA without losing direct data placement.
• SMB over QUIC (SMB 3.1.1 over QUIC with TLS 1.3) for the Azure Edition server, giving remote users file access without a VPN.
• Hotpatch for Datacenter: Azure Edition, installing many security updates without a restart.
• Microsoft Edge replacing Internet Explorer on Desktop Experience installations. Edge follows the Modern Lifecycle Policy, not the server's fixed lifecycle.

Windows Server 2025: secure by default

The Windows Server 2025 what's new page is the longest list, and most of the security items are changes of default rather than new options.

Credentials and identity

• Credential Guard on by default on devices that meet its requirements. Microsoft's Credential Guard configuration page adds an important caveat: if Credential Guard was explicitly turned off before the upgrade, it stays off.
• Windows LAPS improvements: automatic management of a local account (including a randomized account name), detection of image rollbacks through a new msLAPS-CurrentPasswordVersion attribute, passphrase generation from word lists, a more readable password dictionary, and a post-authentication action that terminates processes still running under the managed account.
• Delegated managed service accounts (dMSA), which let you migrate a classic service account to an account with managed, randomized keys while disabling the original password.
• VBS enclaves and VBS key protection for developers who want to isolate secrets and keys from even an administrator on the host.

SMB

• SMB signing required by default for all outbound connections. Previously it was required only for SYSVOL and NETLOGON shares on domain controllers. Microsoft's SMB signing page clarifies that Windows Server 2025 requires outbound signing only, while Windows 11 24H2 Enterprise, Pro and Education require it both ways. Requiring signing also disables guest access to shares.
• SMB authentication rate limiter, on by default, which inserts a delay between failed NTLM or PKU2U authentication attempts to slow brute force guessing.
• NTLM blocking for outbound SMB as an option, so a client can refuse to fall back to NTLM.
• SMB dialect control, letting administrators set minimum and maximum SMB 2 and SMB 3 dialects.
• The option to require encryption on all outbound SMB client connections, refusing servers that do not support SMB 3.x with encryption.
• SMB signing and encryption auditing, which logs peers that cannot sign or encrypt so you can find them before you enforce.
• Firewall rule hardening: creating a share now enables a "File and Printer Sharing (Restrictive)" rule group that no longer opens NetBIOS ports 137 to 139.
• SMB over QUIC in Standard and Datacenter, not just Azure Edition, with client access control by certificate.
• Remote Mailslot disabled by default.

Our SMB protocol explainer covers the dialects and what signing and encryption protect.

Active Directory and Kerberos (covered in the next section): no RC4 ticket granting tickets, LDAP sealing by default on new deployments, TLS 1.3 for LDAP, random default machine account passwords and a new functional level.

TLS and certificates

• TLS server authentication now requires an RSA key of at least 2,048 bits.
• Certificate lookups support SHA-256 hashes.

Operations

• Hotpatch for Azure Arc-connected Windows Server 2025 Standard and Datacenter machines, covered below.
• OpenSSH server installed by default, with a one-step switch in Server Manager to enable or disable the sshd service.
• DTrace as a native tracing tool, plus Bluetooth and Wi-Fi support.

Removals and deprecations

Microsoft's removed and deprecated features list records that NTLMv1 is removed, LANMAN and NTLMv2 are deprecated (NTLMv2 still works for now), VBScript is a preinstalled feature on demand ahead of later removal, Remote Mailslots are deprecated, and Windows Server Update Services (WSUS) is "no longer actively developed", though existing capabilities and content continue.

Security features compared across releases

What changed in Active Directory functional levels, and what broke for older clients?

Functional levels decide which domain controller (DC) operating systems a domain or forest can contain and which directory features are available. Microsoft's functional levels page is blunt about one thing that is often misunderstood: functional levels "don't affect which operating systems you can run on workstations and member servers". A Windows 10 laptop does not care what level the forest is at.

The levels across these releases

Points that matter in practice:

• Windows Server 2019 and 2022 never got their own functional level. Both use the Windows Server 2016 level as their highest. Microsoft has no plans to add one retroactively.
• Windows Server 2025 introduces a new level that maps to DomainLevel 10 and ForestLevel 10 for unattended installs. Its headline feature is the optional 32k database page size, which raises long-standing directory limits (such as the number of values in a multivalued attribute) by moving the ESE database from 8k pages to 32k pages with 64-bit long value IDs. The switch is forest-wide and requires every DC to have a 32k capable database.
• A Windows Server 2025 DC cannot join a domain still at the 2012 R2 level. New forests and new AD LDS configuration sets must be at the Windows Server 2016 level or higher, and promoting a replica requires the existing domain to be at 2016 or higher already.
• The 2016 level requires DFSR for SYSVOL. Windows Server 2016 was the last release to support the old File Replication Service (FRS). A domain still replicating SYSVOL with FRS has to migrate before it can raise its level.
• What the 2016 level added: automatic rolling of NTLM secrets for accounts that require smart card logon, network NTLM allowed only from specific devices for restricted users, and PKInit freshness support in Kerberos. The 2012 R2 level added the DC-side Protected Users protections (no NTLM, no DES or RC4 in preauthentication, no delegation, four hour TGT lifetime) and authentication policies and silos.

What changes for older clients and devices

Raising a functional level rarely breaks a client. Changing DC behavior often does. Windows Server 2025 DCs change several behaviors that older systems, appliances and scripts may rely on, according to the 2025 what's new page:

• No RC4 ticket granting tickets. The KDC no longer issues TGTs encrypted with RC4-HMAC. Anything that only supports RC4 (old appliances, some non-Windows Kerberos clients, accounts with only RC4 keys) needs attention first. Our Kerberos versus NTLM explainer helps you find which protocol an application actually uses.
• The SupportedEncryptionTypes registry value is ignored. Kerberos no longer honors the legacy registry key under the LSA Kerberos parameters path; Microsoft says to use the Group Policy setting for allowed encryption types instead. Hardening scripts that set the registry value silently stop working.
• LDAP signing and sealing by default on new deployments. All new AD deployments require LDAP sealing after a SASL bind. Applications that bind with simple, unsigned LDAP need to move to LDAPS or signed binds.
• Confidential attributes need encrypted LDAP. Add, search and modify operations that touch confidential attributes work only over an encrypted connection.
• Legacy SAM RPC password change methods are blocked by default on DCs, with the AES based SamrUnicodeChangePasswordUser4 accepted. Remote password changes through the legacy SAM RPC interface are blocked for members of Protected Users and for local accounts on domain members.
• Default machine account passwords are rejected. Windows Server 2025 DCs block setting a computer account password to the default derived from the account name, which affects some pre-staging workflows.
• LSA name and SID lookups between machines use Kerberos and the DC locator instead of the legacy Netlogon secure channel, with Netlogon kept as a fallback for legacy systems.
• Remote Mailslot is disabled for SMB and for DC locator use, which matters only for very old software that still locates DCs that way.

On the SMB side, Windows Server 2025 acting as an SMB client requires signing, so a 2025 server that reads files from an old NAS using guest access or unsigned SMB will fail until the NAS is fixed or the policy is relaxed. Microsoft's SMB signing page advises against disabling signing as a workaround and against signing with guest accounts.

A safe sequence: turn on the auditing Microsoft provides (LDAP channel binding events 3074 and 3075, SMB signing and encryption audit logs, NTLM usage counters), run a Windows Server 2025 DC alongside older DCs for a while, fix what the logs show, and only then retire old DCs and raise the level. Our Active Directory basics post explains domains, forests and Group Policy if you are new to them.

What is Server Core versus Desktop Experience, and why does it matter?

Every LTSC release from 2016 to 2025 offers two installation options for Standard and Datacenter. Microsoft's Server Core page describes Server Core as a minimal option with "a smaller disk footprint, and therefore a smaller attack surface due to a smaller code base".

What Server Core leaves out:

• The GUI shell packages: Microsoft-Windows-Server-Shell-Package, Microsoft-Windows-Server-Gui-Mgmt-Package, Microsoft-Windows-Server-Gui-RSAT-Package and the Cortana desktop package.
• Accessibility tools, the out-of-box experience and audio.
• Windows Push Notification services.

You manage Server Core with PowerShell, remote server administration tools, Windows Admin Center or SSH. Some graphical tools can be added back as features on demand.

Why it matters for security and patching

• Less code installed means less code to attack. Components that are not installed cannot be exploited on that host, and a browser, shell and desktop stack are among the components with the most frequent fixes.
• Some fixes have nothing to change. A monthly cumulative update still covers the whole OS, but fixes for components that are not installed have nothing to patch on that server. The Server Core page gives no figure for how many fewer restarts Server Core needs, so treat claims of a specific percentage with caution.
• It is the only option for some features. The Annual Channel is Server Core only. On Windows Server 2022, Hotpatch for Azure Edition originally targeted Server Core images.
• It forces good habits. Administrators manage the box remotely and through scripts, which is easier to audit than interactive desktop sessions.

The catch: you cannot switch later

Microsoft's upgrade overview states that you cannot convert between Server Core and Server with Desktop Experience after installation, and that an in-place upgrade cannot switch between them either. Choosing wrongly means a clean install. Decide based on the workload: domain controllers, DNS, DHCP, file servers, Hyper-V hosts and IIS web servers run well on Server Core; some third-party applications insist on Desktop Experience.

What happens at end of support, and what are Extended Security Updates?

Microsoft's Fixed Lifecycle Policy defines two phases. Mainstream support includes security updates, the ability to request non-security updates, and incident support. Extended support includes security updates at no extra cost and paid support, but Microsoft "will not accept requests for warranty support, design changes, or new features".

When extended support ends, monthly security updates stop. The server keeps running and nothing switches off, which is exactly why unsupported servers linger. CISA's Bad Practices list names the "use of unsupported (or end-of-life) software" in service of critical infrastructure as a dangerous practice that significantly elevates risk, and calls it "especially egregious" for internet-accessible technology. NIST's SP 800-40 Rev. 4, the guide to enterprise patch management planning, treats patching as preventive maintenance that should be planned rather than handled as an emergency, and an end of support date is the most predictable patching event there is.

Extended Security Updates

Microsoft's ESU overview calls the program "a last resort option". ESU provides security updates rated critical and important for a fixed period after extended support ends. It does not include new features, non-security hotfixes or design changes. ESU is included at no extra charge for Windows Server running on Azure (including the Azure Stack portfolio) and must be purchased for servers elsewhere, with a product key installed on each server.

So as of this writing, any Windows Server 2012 or 2012 R2 machine, in Azure or not, is past the end of its paid security updates. For Windows Server 2016, the ESU overview page we fetched on 23 October 2026 did not list an offer. Check the Windows Server 2016 lifecycle page and your Microsoft licensing contact before assuming one exists, and plan as if January 2027 is the last update.

What "out of support" means in practice

• No new security fixes. Vulnerabilities disclosed after the end date remain open on that OS forever, unless covered by ESU.
• Compliance findings. Many audit frameworks ask for supported software. An unsupported OS usually means a documented exception, compensating controls and a retirement date.
• Dependent software follows. Vendors drop support for their agents, runtimes and applications on unsupported operating systems, so the rest of the stack stops getting updates too.
• Containers follow the host. The lifecycle pages state that containers released with each Windows Server version follow the same lifecycle dates, so a Windows Server 2016 base image goes out of support with the OS.

For the vocabulary of end of sale, end of support and end of life, see our lifecycle dates explainer.

What is Hotpatch, and which servers can use it?

Microsoft's Hotpatch page describes Hotpatch as patching "the in-memory code of running processes without the need to restart the process". It changes the restart rhythm, not the need for updates.

• Supported platforms. Windows Server 2022 Datacenter: Azure Edition and Windows Server 2025 Datacenter: Azure Edition on Azure and Azure Local, using specific marketplace images (custom images and container base images are not supported), plus Windows Server 2025 Standard and Datacenter machines connected to Azure Arc. The page states that Azure Arc-enabled Hotpatch for Windows Server 2025 "is now available at no extra cost". The 2025 what's new page still labels Arc-enabled Hotpatch as a preview, so check the Hotpatch page for current terms.
• Baselines. Every three months a normal cumulative update (a baseline) installs and requires a restart. The two months after each baseline get Hotpatch releases with no restart. A typical year has four planned baselines and eight Hotpatch releases.
• Unplanned baselines. If an urgent fix cannot ship as a hotpatch, that month becomes an unplanned baseline with a restart.
• What is not covered. Non-security Windows updates, .NET updates, and drivers and firmware still need a normal update and restart.
• No automatic rollback. If a hotpatch misbehaves, you uninstall it and reinstall the last good baseline, which requires a restart.

Lifecycle note: the Windows Server 2022 lifecycle page says Hotpatch is supported on Windows Server 2022 Datacenter: Azure Edition Core only through the end of mainstream support, which was 13 October 2026.

Step by step: check build, edition, updates and security features with PowerShell

Run these in an elevated PowerShell session on the server, or wrap them in Invoke-Command to run against many servers. Everything here is read only except the optional SMB audit settings in step 5, which change logging and nothing else.

1. Release, edition, build and installation type

Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, WindowsInstallationType, OsBuildNumber, OSDisplayVersion

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0}.{1}' -f $cv.CurrentBuildNumber, $cv.UBR

WindowsInstallationType reads Server Core or Server. OsBuildNumber maps to the release (14393, 17763, 20348 or 26100). The second command prints the full build with the update revision, such as 20348.5761, which you compare against the latest build on the release information page. On Windows Server 2022, OSDisplayVersion of 21H2 means LTSC and 23H2 means Annual Channel.

2. Installed updates

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, Description, InstalledOn

Get-CimInstance -ClassName Win32_QuickFixEngineering |
  Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn

The most recent KB number should match the latest cumulative update for that build. If the newest entry is months old, the UBR from step 1 will confirm the server stopped patching.

3. Credential Guard and VBS

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

Microsoft's Credential Guard documentation says a SecurityServicesRunning value containing 1 means Credential Guard is running and 0 means it is not. On Windows Server 2025, an unexpected 0 on modern hardware often means a policy turned it off before the upgrade.

4. Secure Boot and TPM

Confirm-SecureBootUEFI
Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerVersion

Confirm-SecureBootUEFI returns True when Secure Boot is on, False when it is off, and an error on systems that do not boot with UEFI. These two are the recommended baseline on the Secured-core server page.

5. SMB signing, encryption and SMB1

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature, EncryptData, RejectUnencryptedAccess

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

Get-WindowsFeature FS-SMB1

You want EnableSMB1Protocol set to False and the FS-SMB1 feature not installed. On Windows Server 2025 the client's RequireSecuritySignature should be True by default. If you are preparing to enforce, turn on auditing first:

Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true -AuditClientDoesNotSupportEncryption $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true -AuditServerDoesNotSupportEncryption $true

These audit settings exist on Windows Server 2025 and log to the SMBServer and SMBClient Audit event channels. They change logging only, not access.

6. TLS protocol configuration

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -Recurse |
  ForEach-Object { $_.Name; Get-ItemProperty $_.PSPath | Select-Object Enabled, DisabledByDefault }

Get-TlsCipherSuite | Select-Object -First 10 Name

No subkeys means the OS defaults apply: TLS 1.3 on Windows Server 2022 and 2025, not available on 2016 and 2019. Explicit Enabled values of 1 under TLS 1.0 or TLS 1.1 keys are worth a question.

7. Active Directory levels and DC versions

Import-Module ActiveDirectory
(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem, OperatingSystemVersion

This shows how far you are from the Windows Server 2025 functional level and which DCs still run 2016 or older.

8. LAPS

Get-Command -Module LAPS | Select-Object -First 5 Name
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 5

If the LAPS module is missing on Windows Server 2019 or 2022, the server is missing the April 2023 or later update. Windows Server 2016 cannot run Windows LAPS and needs the legacy add-on.

9. Installed software and open source components outside Windows Update

Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
  Where-Object DisplayName | Select-Object DisplayName, DisplayVersion, Publisher | Sort-Object DisplayName

Get-WindowsCapability -Online -Name OpenSSH* | Select-Object Name, State
Get-Service sshd -ErrorAction SilentlyContinue
curl.exe -V

This is where the OS inventory ends and the application inventory begins. The next section explains why that list matters.

How do you plan an in-place upgrade versus a rebuild?

Microsoft's upgrade overview lists five ways to move forward: in-place upgrade, clean install, migration of roles to a new server, cluster OS rolling upgrade, and license conversion between editions of the same release.

Supported in-place upgrade paths

Starting with Windows Server 2025, non-clustered servers can jump up to four versions at once; earlier targets allowed two. Clusters using rolling upgrade move one version at a time.

Restrictions that decide the plan for you

From the same page:

• No 32-bit to 64-bit upgrades (every release since Windows Server 2008 R2 is 64-bit only).
• No change of installation language.
• No switch between Server Core and Desktop Experience.
• Edition is retained by default. You can move up (Standard to Datacenter or Azure Edition) during an upgrade, never down.
• Domain controllers cannot be converted to a retail version, and Storage Server editions cannot upgrade in place.
• Each Windows Server upgrade needs its own license, unlike Windows client.

Domain controllers: build new, then demote

Microsoft's DC upgrade guidance says the recommended way to upgrade a domain is to promote new DCs on a clean install and demote the old ones, rather than upgrading a DC in place. If you do upgrade a DC in place, you must run adprep /forestprep once per forest and adprep /domainprep in each domain first.

Decision table

A rebuild is the better security outcome in most cases. It removes software nobody remembers installing, forces you to write down every dependency, and gives you a known baseline for drift detection. An in-place upgrade is the better operational outcome when the server is a snowflake you cannot rebuild yet, but it should come with an inventory so that the next move can be a rebuild.

Testing checklist before the cutover

1. Inventory the current server with the PowerShell in steps 1, 2 and 9 and save the output.
2. Check that every application, agent and driver vendor supports the target release.
3. On a test copy, enable SMB, LDAP and NTLM auditing and run the workload for at least one business cycle.
4. Confirm the backup restores, not just that the backup job succeeded.
5. Snapshot or image the server if it is virtual.
6. Upgrade or rebuild, then run steps 1 to 9 again and compare.
7. Record the new end of support date in your asset register.

What open source components ship on a typical Windows Server workload?

Windows Update patches Windows. It does not patch most of what runs on Windows. Even the OS itself now includes open source software, and the workloads on top usually carry far more:

• OpenSSH. Microsoft maintains a fork of the OpenBSD project's OpenSSH, documented on its OpenSSH overview. It has been a feature on demand since Windows Server 2019 and is installed by default on Windows Server 2025. If someone installed a separate OpenSSH build by hand instead, track that copy and its version on its own.
• curl. The curl project's page on curl shipped by Microsoft explains that curl has been a default Windows component since Windows 10 insider build 17063, built by Microsoft against the Schannel TLS backend, and that Microsoft's copy is typically behind the curl project's own releases. The curl project asks users to report problems with that build to Microsoft.
• .NET. Modern .NET is open source with its own support policy: a new major release every November, with even numbered long term support releases supported for three years and standard term support releases for two years. An application pinned to an old .NET runtime can be unsupported on a fully supported Windows Server.
• Web stacks. IIS sites often host PHP, Node.js or Python applications through FastCGI, reverse proxy or platform handlers, each bringing its own runtime and package tree. Some teams run Apache HTTP Server, nginx or Tomcat on Windows as well.
• Language runtimes and package managers. Java runtimes, Python with pip packages, Node.js with npm packages, and PowerShell modules from public galleries.
• Agents. Monitoring, backup, logging, configuration management and endpoint agents, many built on open source libraries such as OpenSSL, zlib or SQLite.
• Windows containers. Base images follow the host OS lifecycle, but the application layers inside them carry whatever dependencies the build pulled in.

CISA's Product Security Bad Practices guidance asks software makers to routinely monitor for CVEs or other security relevant alerts, "such as end-of-life", in all open source dependencies and update them as necessary. The same habit applies to anyone running a Windows Server fleet: an OS patched to the current UBR can still run a web application with a two year old vulnerable library.

Common mistakes

• Reading "mainstream support ended" as "no more patches". Windows Server 2022 left mainstream support on 13 October 2026 and still receives monthly security updates until October 2031. What stopped is non-security fixes and new features.
• Reading "extended support" as "we have years". Windows Server 2016 extended support ends on 12 January 2027. A migration started in November is already late for any server that needs application testing.
• Assuming ESU exists for every release. Microsoft's ESU page, when we fetched it, covered only Windows Server 2012 and 2012 R2, and that window closed on 13 October 2026.
• Trusting the product name to identify the channel. Annual Channel hosts report "Windows Server 2022 Datacenter" just like LTSC hosts. Check OSDisplayVersion.
• Checking only the major build. Two servers both on build 20348 can be a year apart in patches. Always compare the full build with the update revision.
• Raising the functional level before auditing. The functional level itself rarely breaks clients, but the DC behavior changes in Windows Server 2025 (no RC4 TGTs, LDAP sealing, blocked legacy SAM RPC methods) do. Audit first.
• Disabling SMB signing to reach an old NAS. Microsoft's guidance is to fix the device or its guest access, not to remove signing.
• Hardening Kerberos with the old registry value. On Windows Server 2025 the SupportedEncryptionTypes registry value is not honored. Use the Group Policy setting.
• Installing Desktop Experience "just in case". You cannot remove it later without a clean install, and it adds code you then have to patch.
• Treating Hotpatch as a reason to skip restarts entirely. Baseline months, unplanned baselines, .NET and drivers all still need restarts.
• Forgetting the software on top of the OS. Runtimes, web stacks, agents and container layers follow their own release cycles and do not arrive through Windows Update.

FAQ

What is the latest version of Windows Server?

Windows Server 2025 (build 26100) is the current Long-Term Servicing Channel release, available since 1 November 2024 and supported until 14 November 2034. Version 23H2 is the latest Annual Channel release, which is a Server Core container host for Software Assurance customers.

When does Windows Server 2016 support end?

Extended support for Windows Server 2016 ends on 12 January 2027. Mainstream support already ended on 11 January 2022. After January 2027 Microsoft will not ship security updates for it unless an Extended Security Updates offer is announced, and none was listed on the ESU overview page when we checked.

Is Windows Server 2019 still supported?

Yes. Windows Server 2019 is in extended support, which means monthly security updates continue until 9 January 2029. Its mainstream support ended on 9 January 2024.

Did Windows Server 2022 support end in October 2026?

Only mainstream support ended, on 13 October 2026. Windows Server 2022 now receives security updates under extended support until 14 October 2031.

What happened to the Windows Server Semi-Annual Channel?

Microsoft retired the Semi-Annual Channel on 9 August 2022. Its last release was version 20H2. Since September 2023 the faster channel is the Annual Channel, which is limited to Server Core container hosts with 24 months of support per release.

How do I check my Windows Server version and build number?

Run Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OSDisplayVersion, WindowsInstallationType, then read CurrentBuildNumber and UBR from the HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key to get the full build, such as 26100.33650. You can also run winver on Desktop Experience installations.

Can I upgrade Windows Server 2016 directly to Windows Server 2025?

Yes, for non-clustered servers. Windows Server 2025 accepts in-place upgrades from Windows Server 2012 R2, 2016, 2019 and 2022. Clusters doing a rolling upgrade move one version at a time, and Microsoft recommends replacing domain controllers with new ones rather than upgrading them in place.

Can I switch from Server Core to Desktop Experience?

No. On current releases you cannot convert between Server Core and Server with Desktop Experience after installation, and an in-place upgrade cannot switch them either. Changing the installation option needs a clean install.

Is Credential Guard enabled by default on Windows Server 2025?

Yes, on devices that meet its hardware and configuration requirements. If Credential Guard was explicitly turned off before the upgrade, it stays off. You can check with the Win32_DeviceGuard query in the walkthrough above, where a value of 1 in SecurityServicesRunning means it is running.

Does Windows Server 2025 break older clients?

Clients are not affected by functional levels, but they can be affected by new DC and SMB defaults. Systems that rely on RC4 Kerberos tickets, unsigned LDAP binds on new deployments, legacy SAM RPC password changes, NTLMv1, or SMB guest access to file shares need testing before Windows Server 2025 servers take over those roles.

Where Safeguard fits, honestly

Safeguard does not patch Windows, manage Windows Server, deploy cumulative updates, run on endpoints as an agent or check Secured-core configuration. Microsoft's own servicing tools and your configuration management do that work, and nothing in this post depends on Safeguard.

The fit is the software you put on the server. The applications running under IIS, the services built on .NET, Node.js, Python, PHP or Java, the agents and the container images your team builds all carry open source dependencies with their own vulnerabilities and release cycles. Safeguard scans those repositories, container images and SBOM files, shows which projects contain a given component and version, matches components against vulnerability databases with reachability analysis, and evaluates policies and gates. When a fixed version exists, it can open a fix pull request; autonomous remediation ships switched off by default. Windows OS updates themselves still come from Microsoft.

An OS migration is also the moment applications get rebuilt and redeployed, which means every dependency is resolved again on the new server. Runtimes, web stacks, OpenSSH and curl all ship open source components, so the supply chain questions do not go away when the operating system is current.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies to a Node.js application you are moving from a Windows Server 2016 host to Windows Server 2025, where the rebuild is a natural time to clear known vulnerable dependencies.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. Teams that build application packages and container images on their own build servers can run scans there rather than sending code elsewhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. During a migration, an engineer can ask which of the applications being moved carry a given component and version, without granting more access than they intend.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Microsoft Learn: Windows Server release information
• Microsoft Lifecycle: Windows Server 2016
• Microsoft Lifecycle: Windows Server 2019
• Microsoft Lifecycle: Windows Server 2022
• Microsoft Lifecycle: Windows Server 2025
• Microsoft Lifecycle: Windows Server Semi-Annual Channel
• Microsoft Lifecycle: Windows Server Annual Channel
• Microsoft Lifecycle: Fixed Lifecycle Policy
• Microsoft Learn: Windows Server servicing channels
• Microsoft Learn: What's new in Windows Server 2016
• Microsoft Learn: What's new in Windows Server 2019
• Microsoft Learn: What's new in Windows Server 2022
• Microsoft Learn: What's new in Windows Server 2025
• Microsoft Learn: Secured-core server
• Microsoft Learn: Active Directory Domain Services functional levels
• Microsoft Learn: Upgrade domain controllers to a newer version of Windows Server
• Microsoft Learn: Extended Security Updates for Windows Server overview
• Microsoft Learn: Hotpatch for Windows Server
• Microsoft Learn: Overview of Server Message Block signing
• Microsoft Learn: What is Windows LAPS?
• Microsoft Learn: Configure Credential Guard
• Microsoft Learn: What is Server Core?
• Microsoft Learn: Windows Server upgrade overview
• Microsoft Learn: Protocols in TLS/SSL (Schannel SSP)
• Microsoft Learn: Features removed or no longer developed in Windows Server
• Microsoft Learn: OpenSSH for Windows overview
• .NET and .NET Core support policy
• curl project: curl shipped by Microsoft
• CISA: Bad Practices
• CISA: Product Security Bad Practices
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning

Last reviewed: 23 October 2026.