AppLocker rollout: scripts, installers and packaged apps

The App Control pillar guide recommends App Control for Business as the device-wide baseline and keeps AppLocker for what it still does well: per-user and per-group rules, quick wins on systems where App Control is not ready, and blocking the classic user-writable launch points. This guide is the full AppLocker rollout, collection by collection, with the audit data that keeps it from breaking the business.

AppLocker is not deprecated. It receives security fixes but no new features, and it is enforced in user mode by the Application Identity service. Keep both facts in mind: it is easy to deploy and easy to undermine for anyone with admin rights, so it pairs with removing local admin rights.

The five rule collections

Each collection has its own enforcement setting. A collection with no rules is not enforced, and one with rules but no enforcement setting is enforced. That second behaviour surprises people: always set the mode explicitly.

Rules come in three types: publisher (signer, product, file name, version), path and file hash. Prefer publisher rules; they survive updates. Use path rules only for folders standard users cannot write to.

Step 1: prerequisites

• Application Identity service set to Automatic. Use Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Application Identity. On current Windows versions you cannot change its start type in the Services console, so policy is the reliable way.
• Supported edition. AppLocker historically enforced only on Enterprise, Education and Server editions. Since KB5024351, Windows 10 2004 and later and all Windows 11 versions enforce it on every edition, including Pro. On older builds (including Windows Server 2019), policies delivered by Group Policy work only on Enterprise and Server editions, while MDM-delivered policies work on all editions.
• A pilot OU with a representative set of users: finance, developers, helpdesk and a shared kiosk if you have one.

AppLocker rules live under Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. On Intune-managed devices, AppLocker policy is delivered through the AppLocker CSP as custom OMA-URI settings containing the rule collection XML, one node per collection: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/{Grouping}/EXE/Policy, with MSI, Script, StoreApps and DLL in place of EXE for the other collections ({Grouping} is a unique name, ideally a GUID).

Step 2: start in audit mode with sane defaults

In the AppLocker node, open Configure rule enforcement and set Executable, Windows Installer, Script and Packaged app rules to Audit only. Then, per collection, right-click and Create Default Rules. Default rules are a starting point, not a design; two changes are needed straight away.

Close the writable folders under %WINDIR%. The default "Everyone may run anything under %WINDIR%" rule includes subfolders standard users can write to, which turns them into launch pads. Common examples:

• C:\Windows\Tasks
• C:\Windows\Temp
• C:\Windows\tracing
• C:\Windows\System32\spool\drivers\color
• C:\Windows\System32\Tasks

Add these as exceptions on the %WINDIR% path rules for executables and scripts. Check your build for others with Sysinternals AccessChk against the Users and Everyone groups, since the list varies by version and installed software.

Deny known bypass binaries for standard users. The default rules allow every signed Windows binary, including ones that run arbitrary code: mshta.exe, wscript.exe, cscript.exe, regsvr32.exe, msbuild.exe and installutil.exe are frequent examples. Add publisher deny rules for the ones your users do not need, scoped to standard users rather than Everyone so admin tooling keeps working.

Step 3: collect audit data and build rules from it

Leave the pilot in audit for two to four weeks, long enough to cover month-end processes. AppLocker logs to Applications and Services Logs > Microsoft > Windows > AppLocker:

Generate candidate rules straight from the audit events on a pilot device:

Get-AppLockerFileInformation -EventLog -EventType Audited `
  -LogPath "Microsoft-Windows-AppLocker/EXE and DLL" |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File .\candidate-exe.xml

Or from a reference folder:

Get-AppLockerFileInformation -Directory "C:\Program Files (x86)\Contoso" -Recurse |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File .\contoso.xml

Review every candidate before importing. Audit data from a user who ran a random download will produce a rule allowing that download. Scope rules to groups where it makes sense: engineering tools for GG-Engineering, not Everyone.

Import reviewed rules into the GPO with Set-AppLockerPolicy -XmlPolicy .\contoso.xml -Ldap "LDAP://CN={GPO-GUID},CN=Policies,CN=System,DC=corp,DC=example" -Merge.

Step 4: scripts, installers and packaged apps

Scripts. Enforcing script rules has an important side effect: PowerShell runs in Constrained Language Mode for scripts and interactive sessions that are not allowed by policy. That blocks most offensive PowerShell, but it also breaks admin scripts run from user-writable folders. Store admin scripts under an admin-only path or sign them, and allow logon scripts explicitly: add path rules for \\corp.example\SYSVOL\* and \\corp.example\NETLOGON\* (only if those shares are writable by admins only, which they should be). See the PowerShell logging and CLM guide for the details.

Windows Installer. The default "all signed MSIs" rule lets users run any signed installer, which is broad but relies on the fact that most MSIs need elevation. Tighten it to publisher rules for your software catalogue if users should never install anything themselves.

Packaged apps. The default allows every signed MSIX package, including every Store app. If you want to control which Store apps can run, replace the default with publisher rules per package; generate them from installed apps with Get-AppxPackage | Get-AppLockerFileInformation.

Step 5: enforce in rings

Switch one collection at a time to Enforce rules, starting with executables, then scripts, then installers and packaged apps. For each ring, keep watching 8003, 8006, 8021 and 8024 on devices that remain in audit, and 8004, 8007, 8022 and 8025 on enforced devices.

Per-user rules on shared devices

This is where AppLocker still beats App Control, which applies the same policy to every user of a device. On shared machines such as reception desks, shop-floor terminals, training rooms and nurse stations, you can give different populations different rules on the same hardware:

• Kiosk and shift accounts: a short list of publisher rules for the line-of-business app and the browser, nothing else. No script rules beyond logon scripts.
• Local IT and helpdesk groups: their support tools on top.
• Administrators: the default "all files" rule, since they are protected by other controls.

Target each rule at a group rather than Everyone, and keep the groups in Active Directory or Microsoft Entra ID so that membership changes do not require a policy change. Combine this with a restricted shell or assigned access where the device is a true kiosk.

What breaks

• Per-user installers: apps that install into %LOCALAPPDATA% (common for conferencing, chat and developer tools) are blocked by default. Provide a machine-wide version through your deployment tool.
• Self-updaters that drop new executables in user-writable paths.
• Logon scripts from SYSVOL or NETLOGON when script rules are enforced without the path rules above.
• Office add-ins and macros that shell out to scripts in temp folders.
• Helpdesk remote support tools downloaded on the fly. Pre-install an approved one.

Verify it

Get-Service AppIDSvc | Select-Object Status, StartType
Get-AppLockerPolicy -Effective -Xml | Out-File .\effective.xml
Test-AppLockerPolicy -XmlPolicy .\effective.xml -Path "$env:LOCALAPPDATA\Temp\test.exe" -User CORP\jdoe
$ExecutionContext.SessionState.LanguageMode   # ConstrainedLanguage for a standard user when script rules are enforced

Test-AppLockerPolicy returns Allowed, Denied or DeniedByDefault per file and user, which makes it useful in change reviews. Forward the blocked-event IDs to your SIEM; a burst of 8004 events from one user often means someone ran a phishing payload.

Checklist

• Application Identity service set to Automatic by GPO on every targeted device
• Enforcement mode set explicitly for each collection
• Default rules created, with exceptions for writable folders under %WINDIR%
• Deny rules for bypass binaries standard users do not need
• Two to four weeks of audit data reviewed before enforcement
• Publisher rules preferred, scoped to groups where possible
• Script rules enforced with SYSVOL/NETLOGON allowed and admin scripts signed
• Blocked events (8004, 8007, 8022, 8025) forwarded and alerted

AppLocker is the fast, per-user layer. For a control that local administrators cannot simply switch off, pair it with App Control and a managed installer; the application control area lists the full series.