AppLocker Group Policy: Complete Audit-to-Enforce Guide in 6 Steps

An AppLocker Group Policy object lets you decide which programs, scripts and installers users can run on domain-joined Windows 11 and Windows Server machines, based on the publisher’s signature, the file path or the file hash. This guide builds a policy in six steps, from starting the Application Identity service to audit-only testing and enforcement, and covers the event IDs, the PowerShell cmdlets and the rollback. It also explains when App Control for Business is the better choice.

Short answer: In a GPO linked to a pilot computer OU, set the Application Identity service to Automatic under Computer Configuration » Policies » Windows Settings » Security Settings » System Services. Under Security Settings » Application Control Policies » AppLocker, right-click each rule collection and choose Create Default Rules, then open Configure rule enforcement and set every collection to Audit only. Review events 8003 and 8006 for two to four weeks, add rules for what you see, then switch to Enforce rules.

Which method to use

Method	Scope	Pros	Cons
AppLocker via domain GPO	Domain-joined clients and servers	Per-user and per-group rules; familiar tools; audit mode	Defence in depth only; no new features
AppLocker local policy (secpol.msc)	One machine	Testing, workgroup servers	Manual; merges with domain policy
AppLocker CSP via Intune	Entra-joined devices	Same rules without AD	Custom OMA-URI with XML; Get-AppLockerPolicy does not see it
App Control for Business (WDAC)	Whole machine, including kernel drivers	Microsoft’s recommended control; stronger	Per-device, not per-user; more planning

AppLocker or App Control for Business?

Microsoft describes AppLocker as a defence-in-depth feature, not a defensible security boundary, and says it does not receive new feature improvements. For protection against a determined attacker it recommends App Control for Business. AppLocker still makes sense when you need rules that differ per user or group on the same machine (for example on RDS hosts), when you want a quick audit of what runs, or as a layer next to App Control. Many organisations use both: App Control for the device baseline, an AppLocker Group Policy object for per-user restrictions.

Prerequisites

• Supported editions. Windows Server 2016 to 2025 can create and enforce AppLocker policies. On Windows 10 version 2004 and later and on Windows 11, Microsoft’s requirements page says all editions can enforce AppLocker once KB5024351 or a later cumulative update is installed. Domain Group Policy still needs Pro, Enterprise or Education.
• The Application Identity service (AppIDSvc) running on every target machine. Without it, rules are not enforced.
• GPMC or RSAT on an admin workstation, and a reference machine with your standard apps installed, to generate rules from.
• A pilot OU and a way to collect events (Windows Event Forwarding, your SIEM or a PowerShell script).

Rule collections and conditions

AppLocker sorts rules into five collections. As soon as a collection contains at least one rule, anything that no rule allows is blocked, unless the collection is set to Audit only. Microsoft warns that the enforcement mode Not configured does not mean the rules are ignored: rules in a “not configured” collection are enforced.

Collection	File types	Notes
Executable rules	.exe, .com	Start here
Windows Installer rules	.msi, .msp, .mst	Controls who can install packages
Script rules	.ps1, .bat, .cmd, .vbs, .js	Logon scripts must be allowed
Packaged app rules	.appx, .msix apps and installers	Needed if executable rules are enforced
DLL rules	.dll, .ocx	Off by default because of the performance cost

Each rule uses one condition:

• Publisher: the digital signature, optionally narrowed by product name, file name and version. Survives updates. Use it wherever the file is signed.
• Path: a folder or file, with variables such as %PROGRAMFILES% and %WINDIR%. Safe only for folders standard users cannot write to.
• Hash: the SHA256 hash of one file. Exact, but breaks with every update. Use for unsigned tools that rarely change.

Every rule has an action (Allow or Deny), a user or group it applies to, and optional exceptions. Deny rules override Allow rules.

Plan the policy before you build it

A few decisions up front save weeks of rework once the AppLocker Group Policy object is live:

• Which collections. Most organisations start with Executable, Windows Installer and Packaged app rules, add Scripts once logon scripts and admin tooling are covered, and leave DLL rules for high-risk machines only.
• Who is restricted. Rules can target Everyone, a user group or a single account. Decide which groups get extra tools (developers, finance add-ins, service desk utilities) and create those AD groups first.
• Allow-list or deny-list. AppLocker is designed as an allow-list. A deny-only design (Everyone allowed, a few tools denied) is easy to bypass by renaming or moving a file, so use deny rules only on top of an allow-list.
• Rule type order. Publisher first, path only for admin-protected folders, hash as a last resort. Microsoft advises against path conditions for locations standard users can write to, such as the user profile.
• Naming and ownership. One GPO per machine role, named for example SEC – AppLocker – Workstations and SEC – AppLocker – RDS, with a named owner who approves new rules.

Step 1: Start the Application Identity service

1. In Group Policy Management, right-click Group Policy Objects and create an unlinked GPO such as SEC – AppLocker – Pilot. Link it to the pilot computer OU only after Step 4, so no machine picks up rules before audit mode is set.
2. Go to Computer Configuration » Policies » Windows Settings » Security Settings » System Services.
3. Open Application Identity, tick Define this policy setting, choose Automatic and click OK.

Since Windows 10 the service is a protected process, and services.msc cannot set it to Automatic. On a single test machine use sc.exe config appidsvc start=auto followed by sc.exe start appidsvc.

Step 2: Create the default rules

In the same GPO, go to Security Settings » Application Control Policies » AppLocker. Right-click Executable Rules, Windows Installer Rules, Script Rules and Packaged app Rules in turn and choose Create Default Rules. The defaults are:

• Everyone may run files in %PROGRAMFILES% and %WINDIR% (executables and scripts).
• BUILTIN\Administrators may run all files.
• Everyone may run digitally signed Windows Installer files and files in %WINDIR%\Installer.
• Everyone may run all signed packaged apps.

The %WINDIR% path rule includes a few folders that standard users can write to, such as %WINDIR%\Temp and %WINDIR%\Tasks. Open the rule, go to Exceptions and add path exceptions for them, or replace the path rule with publisher rules for Windows components. Leave the administrator rule in place: it is your way back in if a rule goes wrong.

Step 3: Add rules for your applications

The default rules in an AppLocker Group Policy object allow software installed in Program Files. They block apps that install per user under %LOCALAPPDATA% or %APPDATA%, portable tools on the desktop and anything run from a download folder. Add rules for the ones you want to keep.

With the wizard

1. Right-click Executable Rules and choose Automatically Generate Rules.
2. Pick the folder on the reference machine, for example C:\Program Files\Vendor or a user’s AppData\Local\Programs folder, and the group the rules apply to.
3. Choose Create publisher rules for files that are digitally signed and, for unsigned files, File hash rules. Review the list and click Create.

With PowerShell

Get-AppLockerFileInformation -Directory 'C:\Program Files\Vendor' -Recurse -FileType Exe, Script |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File C:\Temp\vendor-rules.xml
Set-AppLockerPolicy -XmlPolicy C:\Temp\vendor-rules.xml -Ldap "LDAP://CN={GPO-GUID},CN=Policies,CN=System,DC=contoso,DC=com" -Merge

Replace {GPO-GUID} with the GUID shown on the GPO’s Details tab. -Merge adds the rules to the existing AppLocker Group Policy content instead of replacing it.

Step 4: Run in audit-only mode

1. Right-click AppLocker and choose Properties (the Configure rule enforcement link).
2. On the Enforcement tab, tick Configured for each collection that has rules and select Audit only.
3. Link the GPO to the pilot OU, run gpupdate /force on the pilot machines and let people work normally for two to four weeks, covering month-end jobs and software updates.

In audit mode the AppLocker Group Policy settings block nothing; AppLocker logs a warning for each file that would have been blocked. Collect them and turn them into rules:

Get-AppLockerFileInformation -EventLog -EventType Audited -Statistics
Get-AppLockerFileInformation -EventLog -EventType Audited |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File C:\Temp\audit-rules.xml

Review the XML before you merge it. Audit events include malware and unwanted tools as well as business apps; only allow what you mean to allow.

Step 5: Enforce the rules

1. Change each collection from Audit only to Enforce rules. Start with Executable and Windows Installer rules, then Scripts a week later.
2. If Executable rules are enforced, make sure the Packaged app collection has rules too. Otherwise no packaged apps can run (event 8027), which breaks Start, Settings, Calculator and Store apps.
3. Tell the service desk how to read the block events, then widen the link from the pilot OU to production OUs in stages.

When script rules are enforced, PowerShell sessions run in Constrained Language mode for scripts that are not allowed, which can break admin scripts. Allow your script folders by publisher (sign your scripts) or by an admin-only path.

Step 6 (optional): DLL rules and non-user processes

To control DLLs, open the AppLocker properties, go to the Advanced tab and tick Enable the DLL rule collection, then create default DLL rules and run them in audit mode first. Every DLL load is checked, so test performance on your slowest hardware. By default AppLocker only applies to code started in a user’s context; rule collection extensions can extend it to non-user processes, including SYSTEM, but that is an advanced change we only recommend with a full audit period.

Exceptions and targeting

• Per group rules: assign a rule to a group such as Dev-Tools-Users instead of Everyone, so only that group may run a tool.
• Rule exceptions: allow %PROGRAMFILES%\* but add an exception for a specific tool you want blocked.
• Separate GPOs: one AppLocker Group Policy object for workstations, a stricter one for RDS hosts and kiosks. Policies from several GPOs merge: the rules are added together and one enforcement mode per collection is chosen by Group Policy precedence. Set the mode explicitly in every GPO so a higher GPO never switches a collection from audit to enforce by surprise.
• Exclude machines with security filtering. See GPO security filtering.

For Intune-managed devices, deploy the same XML through the AppLocker CSP (custom profile under ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/), or better, move those devices to App Control for Business policies.

Verify it works

Check three things on a pilot machine: that the AppLocker Group Policy object applied, that the service runs, and what the event log says.

1. Check that the policy and the service are in place:
   

   gpresult /r /scope computer
   Get-Service AppIDSvc
   Get-AppLockerPolicy -Effective -Xml | Out-File C:\Temp\effective.xml

2. Test a file against the effective policy for a user:
   

   Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path C:\Users\Public\tool.exe -User contoso\jdoe

   
   The result is Allowed, Denied, AllowedByDefault or DeniedByDefault.
3. Open Event Viewer » Applications and Services Logs » Microsoft » Windows » AppLocker. The sub-logs are EXE and DLL, MSI and Script, Packaged app-Deployment and Packaged app-Execution.

Event ID	Level	Meaning
8001	Information	The AppLocker policy was applied to this computer
8002 / 8003 / 8004	Info / Warning / Error	EXE or DLL allowed / would have been blocked (audit) / blocked
8005 / 8006 / 8007	Info / Warning / Error	MSI or script allowed / would have been blocked / blocked
8020 / 8021 / 8022	Info / Warning / Error	Packaged app allowed / would have been blocked / blocked
8023 / 8024 / 8025	Info / Warning / Error	Packaged app installation allowed / would have been blocked / blocked
8027	Error	No packaged apps can run: Exe rules enforced, no packaged app rules
8008	Warning	AppLocker component not available on this SKU

Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' -MaxEvents 50 |
  Where-Object Id -in 8003, 8004 | Format-Table TimeCreated, Id, Message -Wrap

Troubleshooting

Symptom	Likely cause	Fix
Nothing is blocked or audited	Application Identity not running, or enforcement not configured	Check Get-Service AppIDSvc and the Enforcement tab
Start menu, Settings or Store apps fail	Exe rules enforced without packaged app rules (8027)	Create default packaged app rules
Teams, Zoom or other per-user apps blocked	Installed under %LOCALAPPDATA%, not covered by default rules	Add publisher rules for the vendor
Logon scripts or admin scripts fail	Script rules enforced; Constrained Language mode	Allow the NETLOGON path or sign scripts
Rules differ from what the GPO shows	Local policy or another GPO merged in	Compare Get-AppLockerPolicy -Effective with -Local
Event 8008 on a client	Edition or update level does not support enforcement	Install current cumulative updates; check the edition
GPO not applied at all	Link, filtering or replication	See Group Policy not applying

Roll back or undo

1. Fast relief: set every collection back to Audit only and run gpupdate /force, or use Invoke-GPUpdate across the OU. Blocking stops at the next refresh; events keep flowing so you can fix the rules.
2. Full removal: delete the rules from each collection, or unlink the GPO. Do not rely on setting enforcement to Not configured while rules remain: those rules are still enforced.
3. Check that no local policy remains with Get-AppLockerPolicy -Local. Remove local rules in secpol.msc if someone created them during testing.
4. The Application Identity service can stay on Automatic. With no rules it enforces nothing.

Back up the GPO before each AppLocker Group Policy change (Backup-GPO, see back up and restore GPOs), and keep one admin account that the default administrator rule allows, so you can always sign in and fix a bad rule.

AppLocker Group Policy at a glance

Official documentation: AppLocker overview, Using Event Viewer with AppLocker, Requirements to use AppLocker.

Related guides: Block USB Storage Group Policy and Intune: Secure Setup · GPO security filtering: target or exclude users and computers · Deploy Software with Group Policy: MSI Install Step by Step.

Frequently asked questions