Policy Analyzer and LGPO: compare, test, apply baselines

The security baselines pillar introduces the Microsoft Security Compliance Toolkit and its two utilities. This guide goes into how to use them day to day: Policy Analyzer to answer "what is different, and where?", and LGPO.exe to apply, export and inspect local policy. Together they are the fastest way to test a baseline on one machine before it reaches a GPO, and to prove to an auditor what a machine actually runs.

Both tools are free downloads from the Security Compliance Toolkit page on the Microsoft Download Center and run on Windows 11 and Windows Server 2016 and later. Download the current baseline packages at the same time; each contains GPO backups, documentation spreadsheets and a Scripts folder expecting LGPO.exe in Scripts\Tools.

What each tool reads and writes

Step 1: build rule sets in Policy Analyzer

Start PolicyAnalyzer.exe and click Add. The Policy File Importer lets you add individual files or a whole GPO backup folder (File > Add files from GPO(s)), then save the combination as a named .PolicyRules set. Build at least three:

1. Baseline: the Microsoft baseline GPOs for your OS and role, for example the Windows 11 24H2 computer and user GPOs, plus the Edge and Microsoft 365 Apps baselines.
2. Current: a backup of every GPO that applies to the target OU. Export them with Backup-GPO, or all at once:

New-Item -ItemType Directory C:\GPOBackup\Workstations -Force | Out-Null
(Get-GPInheritance -Target 'OU=Workstations,DC=corp,DC=example').InheritedGpoLinks |
  ForEach-Object { Backup-GPO -Guid $_.GpoId -Path C:\GPOBackup\Workstations }

3. Previous baseline: the last version you deployed, to diff against a new release.

Store the .PolicyRules files in source control next to your deviation register. They are small XML files and make excellent evidence.

Step 2: compare and read the grid

Select two or more rule sets and click View / Compare. Each row is one setting; each column shows its value in one set. Filter the view with Show only differences or Show only conflicts:

• A conflict is the same setting with different values in two sets. Between Baseline and Current, each conflict is either a gap to fix or a deviation to document.
• A setting present in Current but absent from Baseline is not necessarily wrong: Microsoft baselines omit settings whose default is already secure. But check any that weaken a default, such as re-enabling SMBv1, LM hashes or WDigest (see cached logons and WDigest).
• The same setting defined in several of your GPOs, even with the same value, is a maintenance hazard. Consolidate.

Use Export > Export table to Excel to share the result. For a new baseline release, compare Previous and New: the diff is your change list, and it is shorter than reading the whole release notes.

Step 3: compare against effective state

The most useful mode for audits: run Policy Analyzer as administrator on the target machine, select the Baseline set and tick Compare to Effective State. Policy Analyzer reads the machine's current registry policy values, security settings and audit policy and adds them as a column.

This catches things GPO reviews miss:

• Settings changed by scripts, installers or local administrators.
• GPOs that don't apply because of WMI filters, security filtering or a computer in the wrong OU.
• MDM-delivered values, which appear in effective state even though no GPO sets them.

Save the effective state as its own .PolicyRules set with the machine name and date. Two snapshots of the same machine a month apart are a quick drift check; the configuration drift guide covers automating that.

Step 4: apply a baseline locally with LGPO

On a lab VM, a standalone server or a reference image, apply the baseline GPO backups straight into local policy:

# Apply every GPO backup found under the folder
.\LGPO.exe /g "C:\SCT\Windows 11 v24H2 Security Baseline\GPOs"

# Or apply individual components
.\LGPO.exe /m C:\Policy\machine-registry.pol     # computer registry.pol
.\LGPO.exe /u C:\Policy\user-registry.pol        # user registry.pol
.\LGPO.exe /s C:\Policy\GptTmpl.inf              # security template
.\LGPO.exe /a C:\Policy\audit.csv                # advanced audit policy
.\LGPO.exe /p C:\Policy\Baseline.PolicyRules     # a Policy Analyzer rule set

The baseline packages also ship Baseline-LocalInstall.ps1 in the Scripts folder, which applies the right GPO combination with LGPO and takes switches for domain-joined versus non-domain-joined machines. Run Get-Help .\Baseline-LocalInstall.ps1 -Detailed to see the options for your package version; the non-domain-joined option skips settings that would block remote administration of a standalone machine.

Restart after applying, since several security settings (for example LSA and credential settings) only take effect at boot.

Step 5: export and edit local policy as text

LGPO can back up local policy as a GPO backup, which you can then import into a domain GPO or into Policy Analyzer:

.\LGPO.exe /b C:\Export /n "Lab build - local policy"

To read or edit a registry.pol, parse it into LGPO's text format, edit, and apply the text file:

.\LGPO.exe /parse /m C:\Windows\System32\GroupPolicy\Machine\Registry.pol > C:\Temp\machine.txt
.\LGPO.exe /t C:\Temp\machine.txt

The text format is four lines per setting (configuration, key, value name, type and data) separated by a blank line:

Computer
Software\Policies\Microsoft\Windows NT\DNSClient
EnableMulticast
DWORD:0

Use DELETE instead of a type to remove a value. This is also a handy way to build a small local policy for a jump host or a kiosk without a domain, and to keep it in source control.

Step 6: layer your deviations for the domain

Once a baseline is tested locally, move it to the domain as two layers: the baseline GPOs imported unmodified, and a separate higher-precedence GPO containing only your deviations. Build that deviation GPO deliberately:

1. In Policy Analyzer, compare the Baseline set with the effective state of a tested pilot machine where you applied your exceptions.
2. The differences are exactly your deviations. Cross-check each against the deviation register; anything that isn't documented is either an accident or an undocumented decision.
3. Create the deviation GPO with those settings only, back it up, and add the backup as its own rule set so future comparisons show baseline, deviations and effective state side by side.

For a jump host or a standalone server, do the same with LGPO: apply the baseline with /g, then your deviations with /t from a text file kept in source control. Rebuilding the machine then reproduces exactly the same local policy.

Verify it

After applying, confirm what the machine actually processes:

gpresult /scope computer /h C:\Temp\gpresult.html
auditpol /get /category:* | Out-File C:\Temp\auditpol.txt
secedit /export /cfg C:\Temp\secpol.inf /areas SECURITYPOLICY USER_RIGHTS

Then re-run Policy Analyzer with Compare to Effective State against the Baseline set. The only differences left should be the ones in your deviation register. Errors from Group Policy processing appear in the System log from Microsoft-Windows-GroupPolicy (event 1085 is a failed client-side extension, 1129 and 1054 usually point to network or DC connectivity), and in detail in Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational.

What breaks

• Domain GPOs overwrite LGPO. Local policy is processed first, so anything set by a domain GPO wins. Test domain-bound settings in a GPO linked to a lab OU instead.
• Tattooing. Settings written outside the Policies registry keys (for example some MSS legacy values and security template settings) stay on the machine when you remove the policy. Resetting requires setting the old value explicitly, not deleting the policy.
• Locking yourself out of a standalone server. The domain-joined baseline denies network logon to local accounts. On a workgroup machine that is your only way in; use the non-domain-joined option.
• Audit policy ignored. Advanced audit settings only win over legacy categories when Audit: Force audit policy subcategory settings to override audit policy category settings is enabled, which the Microsoft baseline does. Check it when auditing looks wrong (see audit policy and Sysmon).

Checklist

• Current SCT, Policy Analyzer, LGPO and baseline packages downloaded
• .PolicyRules sets for baseline, current GPOs and previous baseline, in source control
• Conflicts between current GPOs and baseline resolved or documented
• Effective state of sample machines compared with the baseline
• Baseline tested locally with LGPO on a lab machine before GPO rollout
• Standalone servers configured with the non-domain-joined baseline option
• Local policy of special-purpose hosts exported and versioned
• New baseline releases diffed against the previous version

Policy Analyzer and LGPO make baselines testable and provable. For the managed-by-Intune side of the same problem, see Intune security baselines, and browse the whole security baselines area.