A fresh Windows Server 2025 install matches only 22 of the 360 settings in Microsoft’s own member server baseline. Most of the other 338 are policies nobody has set: no minimum password length, lockout only after 10 bad attempts, SMB signing optional on the server side, and 43 of 60 audit subcategories switched off. The Windows Server 2025 security baseline closes those gaps in one pass, but it also changes logons, remote administration and SMB in ways you need to know about before you push it to production.
Here you’ll take the baseline from the Security Compliance Toolkit, apply it to a standalone server with LGPO and measure the result in Policy Analyzer. Then the same GPOs go into Active Directory, linked the way Microsoft intends. Every command below was run in October 2026 on Windows Server 2025 Datacenter with the current baseline release, and the one place the baseline loosens a control (remote admin for local accounts on workgroup servers) is called out where it happens.
What the Windows Server 2025 security baseline contains
The baseline is a set of GPO backups, not an installer. Microsoft ships it as one zip in the Security Compliance Toolkit. Inside are eight GPOs, two helper scripts, two custom ADMX templates (SecGuide and MSS-legacy), HTML reports of every GPO and a spreadsheet of every setting. Which GPOs a server gets depends on its role:
| GPO (prefix MSFT Windows Server 2025) | Member server | Domain controller | What it covers |
|---|---|---|---|
| Member Server | Yes | No | User rights, UAC, NTLM, SMB, firewall, Remote Desktop, audit policy |
| Member Server Credential Guard | Yes | No | VBS, Credential Guard and HVCI |
| Domain Controller | No | Yes | DC user rights, LDAP signing and channel binding, DC audit subcategories |
| Domain Controller Virtualization Based Security | No | Yes | VBS and HVCI without Credential Guard |
| Domain Security | Yes | Yes | Password and lockout policy (link it at the domain root) |
| Defender Antivirus | Yes | Yes | Cloud protection, PUA blocking, attack surface reduction rules |
| Internet Explorer 11 Computer and User | Yes | Yes | IE11 zone lockdown for the IE mode engine |
The current release adds a handful of settings worth knowing about before you roll it out, because each one is a behaviour change rather than a hidden registry tweak. According to the announcement that ships inside the zip (Documentation\Announcement.pdf), this release:
- Turns off the new sudo command on member servers and domain controllers.
- Audits incoming NTLM traffic for all accounts and audits outgoing NTLM to remote servers.
- Forces the print spooler’s RPC to TCP with authentication, and to Kerberos on member servers.
- Applies Mark of the Web to files copied from insecure sources.
- Blocks ROCA-vulnerable Windows Hello for Business keys on domain controllers.
IPPS for IPP printers and the Secure Boot certificate update are guidance only in this release. The new settings for CVE-2025-55234 are audit-only (our server showed AuditClientDoesNotSupportSigning and AuditClientDoesNotSupportEncryption set to 1). The mitigation Microsoft describes is SMB server signing or EPA, and the baseline already requires server signing elsewhere. For Secure Boot that means you still roll the certificates yourself, which our Secure Boot certificate update guide walks through.
Security Compliance Toolkit downloads
You need three files from the toolkit page: the Windows Server 2025 baseline, LGPO.zip and PolicyAnalyzer.zip. Microsoft gives each baseline release a new download link and has no version API, so the baseline URL below is pinned to the release we tested; check the toolkit page for a newer zip before you copy it. Run this in an elevated PowerShell session on the server:
New-Item -ItemType Directory -Force C:\SCT | Out-Null
$urls = @(
'https://download.microsoft.com/download/e99be2d2-e077-4986-a06b-6078051999dd/Windows%20Server%202025%20Security%20Baseline%20-%202602.zip', # pin: no release API #https://www.microsoft.com/en-us/download/details.aspx?id=55319
'https://download.microsoft.com/download/8/5/c/85c25433-a1b0-4ffa-9429-7e023e7da8d8/LGPO.zip',
'https://download.microsoft.com/download/8/5/c/85c25433-a1b0-4ffa-9429-7e023e7da8d8/PolicyAnalyzer.zip')
foreach ($u in $urls) {
$f = Join-Path C:\SCT ([uri]::UnescapeDataString(($u -split '/')[-1]))
Invoke-WebRequest -Uri $u -OutFile $f -UseBasicParsing
Expand-Archive -Path $f -DestinationPath C:\SCT -Force
}Record the hashes before you trust anything in those archives. Microsoft does not publish SHA256 values on the download page, so these are what our copies hashed to on the day we pulled them. A different hash for the same file name means a different build, which is not necessarily a bad one but deserves a second look:
Get-ChildItem C:\SCT\*.zip | Get-FileHash -Algorithm SHA256 | Format-Table -AutoSize Hash, @{n='File';e={Split-Path $_.Path -Leaf}}Our three downloads hashed to:
Hash File
---- ----
CB7159D134A0A1E7B1ED2ADA9A3CE8CE8F4DE391D14403D55438AF824247CC55 LGPO.zip
F2830F79A8E10CA9AF6030EF3C7FBDAD970C125D2F6FAF81649CAE08238E4FFC PolicyAnalyzer.zip
A66DFFBE2622C3C4DD70E44A7F2080F362FB2D6F9208C50678671CBB046A286F Windows Server 2025 Security Baseline - 2602.zipThe archives extract to LGPO_30, PolicyAnalyzer_40 and a folder named after the baseline release. The baseline’s install script refuses to run unless LGPO.exe sits in its Scripts\Tools folder or on the PATH, and the zip deliberately leaves it out, so copy it in now:
Copy-Item C:\SCT\LGPO_30\LGPO.exe 'C:\SCT\Windows Server 2025 Security Baseline - 2602\Scripts\Tools\' -ForcePrefer the Server 2025 zip over the older Server 2022 one even on a mixed fleet. The GPO names carry the release number, so the two sets can sit side by side in the same domain without one overwriting the other.
A rollback point before the first setting changes
LGPO writes straight into local policy, and there is no “uninstall baseline” button. Take a hypervisor snapshot or a full backup first, because that’s the only undo we trust. On top of that, export the current local policy with LGPO so you have a record of what the server looked like before:
New-Item -ItemType Directory -Force C:\lab\pre-baseline | Out-Null
C:\SCT\LGPO_30\LGPO.exe /b C:\lab\pre-baseline /n 'Before MSFT baseline'LGPO prints its banner and the GUID folder it created. PowerShell wraps the banner in a red NativeCommandError block because LGPO writes it to stderr; the backup still succeeds, as the file list confirms:
LGPO.exe - Local Group Policy Object Utility
Version 3.0.2004.13001
Copyright (C) 2015-2020 Microsoft Corporation
Security Compliance Toolkit - https://www.microsoft.com/download/details.aspx?id=55319
Creating LGPO backup in "C:\lab\pre-baseline\{B87C3BDF-E0D6-4305-A054-8692A2F296E1}"We rolled our VM back with a Proxmox snapshot between test phases and did not test restoring from this LGPO backup. Re-importing it would put back the values that existed before, but it wouldn’t remove the hundreds of policies the baseline adds that had no value before. Treat it as an audit record, not a rollback.
The baseline on a standalone server with LGPO
A server that is not in a domain, or one you want hardened before it joins, takes the baseline through Baseline-LocalInstall.ps1. The script wraps LGPO and accepts exactly one switch, and picking the wrong one is the most common mistake with it:
-WSMemberis for a domain-joined member server and keeps every local-account restriction.-WSNonDomainJoinedis for a workgroup server and backs out the local-account restrictions so you can still manage it remotely.-WSDomainControllerexists, but the script exits on a domain controller, so DCs get the baseline through Group Policy only.
Our lab server is in a workgroup, so it gets -WSNonDomainJoined. The scripts are unsigned, so allow them for this PowerShell session only and run the installer from its own folder, because it finds the GPO backups by relative path:
Set-ExecutionPolicy -Scope Process Bypass -Force
Set-Location 'C:\SCT\Windows Server 2025 Security Baseline - 2602\Scripts'
.\Baseline-LocalInstall.ps1 -WSNonDomainJoinedThe run took 154 seconds on our 2 vCPU VM. Read the list of GPOs it installs and the line about local accounts near the end, because that line is the difference between the two member switches:
Windows Server - non-domain-joined
GPOs to be installed:
MSFT Internet Explorer 11 - Computer
MSFT Internet Explorer 11 - User
MSFT Windows Server 2025 v2602 - Defender Antivirus
MSFT Windows Server 2025 v2602 - Domain Security
MSFT Windows Server 2025 v2602 - Member Server
MSFT Windows Server 2025 v2602 - Member Server Credential Guard
==================================================================================================
Copy custom administrative templates...
Configuring Client Side Extensions...
Running LGPO.exe /v /e mitigation /e audit /e zone /e DGVBS
Applying GPO "MSFT Internet Explorer 11 - Computer"...
Running LGPO.exe /v /g ..\GPOs\{2E1948EE-56EE-45A1-9473-D5A4C2153E5F}
Applying GPO "MSFT Internet Explorer 11 - User"...
Running LGPO.exe /v /g ..\GPOs\{F74D904A-2A4B-4865-8877-3E71FEFF91FF}
Applying GPO "MSFT Windows Server 2025 v2602 - Defender Antivirus"...
Running LGPO.exe /v /g ..\GPOs\{B0CBE378-B19F-440E-A939-80B79E48C4EF}
Applying GPO "MSFT Windows Server 2025 v2602 - Domain Security"...
Running LGPO.exe /v /g ..\GPOs\{40CF40AD-F1B2-433F-A5C9-032DB7424608}
Applying GPO "MSFT Windows Server 2025 v2602 - Member Server"...
Running LGPO.exe /v /g ..\GPOs\{066B7FF5-BF2B-4B1B-8A92-2A83B8619444}
Applying GPO "MSFT Windows Server 2025 v2602 - Member Server Credential Guard"...
Running LGPO.exe /v /g ..\GPOs\{5DCDD718-EB35-4D88-9E9A-2B936D7B8A4B}
Non-domain-joined: back out the local-account restrictions...
Running LGPO.exe /v /s ConfigFiles\DeltaForNonDomainJoined.inf /t ConfigFiles\DeltaForNonDomainJoined.txt
==================================================================================================
==================================================================================================
To test properly, create a new non-administrative user account and reboot.Reboot twice, not once. After the first reboot our server reported Credential Guard and HVCI as configured but not running, and the Wininit event at boot still showed Registry Configuration: 0x0. Only after the second reboot did Win32_DeviceGuard list both services as running and LsaIso.exe appear, so a single-reboot change window would close with Credential Guard off and nobody noticing.
The table compares the server before the baseline with the server after two reboots. Values come from secedit /export, the registry, auditpol, Get-MpPreference and the Device Guard WMI class:
| Setting | Fresh install | After the baseline |
|---|---|---|
| Minimum password length | 0 | 14 |
| Account lockout threshold | 10 attempts | 3 attempts, 15 minutes |
| Password history | 0 | 24 |
| Audit subcategories enabled | 17 of 60 | 24 of 60 |
| SMB server signing required | False | True |
| LmCompatibilityLevel | not set | 5 (NTLMv2 only) |
| UAC prompt for administrators | 5 | 2 (secure desktop) |
| Defender ASR rules | 1 | 8 |
| Firewall default inbound (policy store) | not configured | Block, with logging |
| Credential Guard and HVCI | off | running after the second reboot |
| sudo for Windows | not set | disabled |
Two rows hide a trap. A plain Get-NetFirewallProfile still says “not configured”, because it reads the local store. The baseline writes to the policy store, and only Get-NetFirewallProfile -PolicyStore ActiveStore shows the Block and logging values that are actually enforced. The SMB dialect floor is the other one. After the baseline both the SMB server and client policy read MinSmb2Dialect 768 (SMB 3.0), so the server shuts out clients that only speak SMB 2.x and also can no longer reach SMB 2.x shares itself, which on most networks means an old scanner, NAS or embedded device. We had no such client in the lab, so audit your SMB clients before the rollout, not after it.
Policy Analyzer against the effective state
Policy Analyzer answers the question auditors actually ask: does this server match the baseline, setting by setting. It needs no install, and the baseline zip already contains a ready rule file (Documentation\MSFT-WS2025-v2602.PolicyRules), so you never have to import the GPOs yourself. Policy Analyzer doesn’t look in its own Policy Rules folder, though. That folder only ships old Windows 10 and Server 2012 R2 rule sets. It reads the folder shown in its “Policy Rule sets in” field, which is your Documents folder, so copy the rule file there:
New-Item -ItemType Directory -Force "$env:USERPROFILE\Documents\PolicyAnalyzer" | Out-Null
Copy-Item 'C:\SCT\Windows Server 2025 Security Baseline - 2602\Documentation\MSFT-WS2025-v2602.PolicyRules' "$env:USERPROFILE\Documents\PolicyAnalyzer\"
Start-Process C:\SCT\PolicyAnalyzer_40\PolicyAnalyzer.exeComparing against the effective state reads security templates and audit policy, which needs an elevated session, and the button carries a UAC shield for that reason. In the main window:
- 1MSFT-WS2025-v2602
- 2Compare to Effective State
- Tick the MSFT-WS2025-v2602 rule set.
- Click Compare to Effective State.
The Policy Viewer opens with one row per setting. Yellow cells are settings where the effective state differs from the baseline, and grey cells are settings the baseline does not configure. On our fresh server it listed 390 items, because the shipped rule file holds the member server and domain controller GPOs together, and the audit rows alone were mostly yellow:
Each comparison saves an EffectiveState_<computer>_<timestamp>.PolicyRules file into the same Documents folder, and that file then shows up in the rule list. Sorted by name it lands above the baseline, so on our second run the first tick box picked the old snapshot instead of the baseline and the viewer compared the server with itself from an hour earlier. Move old EffectiveState files out of the folder, or check the Baseline(s) column says MSFT before you read anything into the colours.
With the right rule set ticked, the after view is almost white. The yellow rows left in the audit section are the six subcategories that only the Domain Controller GPO sets (Kerberos, directory service access and computer account management), which a member server isn’t supposed to audit:
For a number you can put in a change record, we parsed the rule file and the saved effective state with a short script. It kept only the six GPOs the member switch applies. Before the baseline, 22 of 360 settings matched and 310 were not set at all. After it, 316 matched. Three of the rest are the deliberate non-domain-joined exceptions covered below, and three are user-rights lists with the same SIDs in a different order. Most of the remainder are security-template registry values that Policy Analyzer stores in another form, plus user rights the baseline leaves empty on purpose, and the ones we read back from the registry (LmCompatibilityLevel, RestrictAnonymous, SMB signing) held the baseline values.
Baseline GPOs imported into Active Directory
In a domain the baseline goes in as ordinary GPOs, and the hard part isn’t the import but the link order. We promoted the same VM to the first DC of a new forest, corp.example.com, from the clean snapshot; our Active Directory install guide covers that step if you do not have a domain yet. Run everything below on a DC, or on a machine with GPMC from the AD PowerShell tooling installed.
Start with the ADMX templates. Several baseline settings come from SecGuide.admx and MSS-legacy.admx, which the local install script copied for us on the standalone server (“Copy custom administrative templates…” in its output). In a domain you put them in the central store yourself so GPMC can show and edit those settings. Our new domain had no central store yet, so the first line creates it from the DC’s local templates:
$root = 'C:\SCT\Windows Server 2025 Security Baseline - 2602'
$pd = 'C:\Windows\SYSVOL\sysvol\corp.example.com\Policies\PolicyDefinitions'
Copy-Item C:\Windows\PolicyDefinitions $pd -Recurse -Force
Copy-Item "$root\Templates\*.admx" $pd -Force
Copy-Item "$root\Templates\en-US\*.adml" "$pd\en-US" -ForceIf your domain already has a central store, skip the first Copy-Item; copying a folder onto an existing one nests it inside instead of merging. Replace corp.example.com with your own domain name in the path. Next, import all eight GPOs with the script Microsoft ships for it:
Set-Location "$root\Scripts"
.\Baseline-ADImport.ps1The script lists the GPOs, then runs Import-GPO -CreateIfNeeded for each one and prints the new object. All eight landed in 18 seconds, each with its unused half disabled:
Importing the following GPOs:
MSFT Internet Explorer 11 - Computer
MSFT Internet Explorer 11 - User
MSFT Windows Server 2025 v2602 - Defender Antivirus
MSFT Windows Server 2025 v2602 - Domain Controller
MSFT Windows Server 2025 v2602 - Domain Controller Virtualization Based Security
MSFT Windows Server 2025 v2602 - Domain Security
MSFT Windows Server 2025 v2602 - Member Server
MSFT Windows Server 2025 v2602 - Member Server Credential GuardImporting changes nothing on any server, because none of the GPOs is linked yet. Link them by role: Domain Security at the domain root, where password and lockout policy for domain accounts has to live, the DC set on the Domain Controllers OU, and the member set on an OU that holds your member servers. We created that OU for the test:
$dn = (Get-ADDomain).DistinguishedName
New-ADOrganizationalUnit -Name 'Member Servers' -Path $dn
$v = 'MSFT Windows Server 2025 v2602'
New-GPLink -Name "$v - Domain Security" -Target $dn -LinkEnabled Yes
foreach ($g in "$v - Domain Controller", "$v - Domain Controller Virtualization Based Security", "$v - Defender Antivirus") { New-GPLink -Name $g -Target "OU=Domain Controllers,$dn" -LinkEnabled Yes }
foreach ($g in "$v - Member Server", "$v - Member Server Credential Guard", "$v - Defender Antivirus") { New-GPLink -Name $g -Target "OU=Member Servers,$dn" -LinkEnabled Yes }
(Get-GPInheritance -Target "OU=Domain Controllers,$dn").InheritedGpoLinks | Format-Table Order, DisplayNameNow read the order column, because this is where a baseline rollout quietly fails. New-GPLink appends each new link at the bottom, so Default Domain Controllers Policy keeps order 1 on the OU and Default Domain Policy keeps order 1 at the root:
Order DisplayName
----- -----------
1 Default Domain Controllers Policy
2 MSFT Windows Server 2025 v2602 - Domain Controller
3 MSFT Windows Server 2025 v2602 - Domain Controller Virtualization Based Security
4 MSFT Windows Server 2025 v2602 - Defender Antivirus
1 Default Domain Policy
2 MSFT Windows Server 2025 v2602 - Domain SecurityLink order 1 has the highest precedence, as the Set-GPLink documentation spells out. Wherever a default GPO and a baseline GPO set the same value, such as the DC user rights or the domain password and lockout policy, the default wins and the baseline loses without any warning. Move the two baseline GPOs above the defaults, refresh policy, then read back the domain password policy:
Set-GPLink -Name "$v - Domain Security" -Target $dn -Order 1
Set-GPLink -Name "$v - Domain Controller" -Target "OU=Domain Controllers,$dn" -Order 1
gpupdate /force
Get-ADDefaultDomainPasswordPolicy | Select-Object MinPasswordLength, PasswordHistoryCount, LockoutThreshold, LockoutDurationOur lab host dropped off the network while this ran, so we have no readback to show you. The values to expect are the ones the Domain Security GPO applied on the standalone server: a minimum length of 14, history of 24 and a lockout threshold of 3 for 15 minutes. If Get-ADDefaultDomainPasswordPolicy still shows anything else, Default Domain Policy is still winning at the root. For the same reason we can’t show Policy Analyzer’s DC rows; the member server numbers earlier are the measured ones.
One result from the DC did come back, and it matters more than the baseline itself if you run Linux or appliance clients. Before any baseline GPO was linked, an unsigned LDAP simple bind on port 389 against the brand-new Server 2025 DC already failed with “Strong authentication is required for this operation”. In a new Server 2025 forest like ours, applications that bind in clear text over plain LDAP break the day the DC answers them, not the day you apply the baseline, so move them to LDAPS or a signed SASL bind first.
Microsoft’s LDAP signing documentation says upgraded domains keep their existing signing settings, and we only tested a new forest. If you’re joining Linux servers to the domain, our Rocky Linux AD join guide uses SSSD with Kerberos rather than a clear-text simple bind.
What the baseline broke
Most of the baseline is invisible until something old touches the server. These are the changes that produced an error or a behaviour change in our lab, with the exact text you’ll see.
“The password does not meet the password policy requirements”
The Domain Security GPO sets a 14-character minimum and a history of 24. Any provisioning script that creates local service accounts with short passwords now fails, which is the point, but it fails at deploy time:
The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.
More help is available by typing NET HELPMSG 2245.Raising the password length then trips a second, older trap. net user asks for confirmation whenever a password is longer than 14 characters, and in a non-interactive script nobody answers:
The password entered is longer than 14 characters. Computers
with Windows prior to Windows 2000 will not be able to use
this account. Do you want to continue this operation? (Y/N) [Y]:
No valid response was provided.That prompt exists with or without the baseline; the baseline just makes long passwords the norm. Switch account creation to New-LocalUser, which takes a SecureString and never prompts.
“The referenced account is currently locked out and may not be logged on to”
Three bad passwords now lock an account for 15 minutes, down from ten attempts. We tested it with a throwaway local account: three logons with the wrong password returned error 1326, and the fourth, with the correct password, returned error 1909 with this message. A monitoring probe or scheduled task with a stale password will lock its own account within minutes of the baseline landing, so rotate those credentials first.
Local administrators regain remote access on workgroup servers
This one runs the opposite way to what most people expect. On our fresh server, net use \\localhost\c$ as a local administrator failed with “System error 5 has occurred. Access is denied.”, because UAC remote restrictions strip the admin token from local accounts over the network. After -WSNonDomainJoined, the same command completed successfully. The non-domain-joined delta sets LocalAccountTokenFilterPolicy to 1 and removes the two deny rights the Member Server GPO puts on “Local account and member of Administrators group”.
Microsoft does this on purpose so a workgroup server stays manageable, but it means a hardened workgroup server accepts remote admin logons from local accounts that a stock install refused. Do not reach for -WSMember to undo that on a workgroup box unless you manage it only from the physical or hypervisor console. On a server without a domain every admin account is local, so -WSMember denies your own RDP, SMB and WinRM logons after the reboot, and the practical way back in is that console.
For a remotely managed workgroup server, keep -WSNonDomainJoined and restrict where remote admin can come from with the firewall instead. A domain-joined server gets the deny rights from the Member Server GPO anyway, and domain admin accounts are not affected by them.
WinRM Basic authentication is off
The baseline disables Basic authentication and unencrypted traffic on both the WinRM client and service. The service configuration shows the policy as the source, so a local winrm set will not override it:
winrm get winrm/config/service/authBasic is false and marked as coming from GPO:
Auth
Basic = false [Source="GPO"]
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = RelaxedAutomation that logs in to WinRM with a username and password over Basic has to move to Kerberos, Negotiate or certificate authentication before the rollout. We didn’t run an Ansible controller against the lab VM, so we have not measured which inventories break, only that Basic is refused at the service.
Rollout audit checklist
Run these checks on the first server that takes the baseline, and again on a sample after every new baseline release. Each one is a condition that must hold, not a step to perform:
- A snapshot or full backup from before the baseline exists and has been restored at least once.
- Policy Analyzer, with only the MSFT rule set ticked, shows no yellow rows outside the role’s own exceptions.
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuardlists services 1 and 2 as running after the second reboot.Get-NetFirewallProfile -PolicyStore ActiveStoreshows Block for inbound on all three profiles.Get-SmbServerConfigurationshows RequireSecuritySignature True and Smb2DialectMin 768, and every SMB client on the network still connects.- No service account, scheduled task or monitoring probe has locked out in the 24 hours after rollout.
- Workgroup servers that took
-WSNonDomainJoinedare reachable for remote admin only from the networks you intend, since local admins can log on remotely again.
Once these hold on a pilot server, the same GPOs are ready to link more widely. A WSUS server that keeps the fleet patched and a hardened VM template built from a baselined server make sure new machines start compliant instead of drifting into it.
