Introduction to AppLocker on Windows Server 2022

AppLocker is an application control feature in Windows Server 2022 that allows administrators to define which applications, scripts, and Windows Installer packages users are allowed to run. Unlike WDAC which operates at the kernel level, AppLocker is enforced by the Application Identity service in user mode and provides flexible per-user and per-group rule enforcement. While Microsoft’s strategic direction favors WDAC for new deployments, AppLocker remains widely used and fully supported in Windows Server 2022, particularly for environments that require granular per-user application control policies.

This article covers AppLocker rule types, creating rules through Group Policy, rule collections, path vs hash vs publisher rules, audit mode, PowerShell management, event log analysis, and the limitations of AppLocker on Server Core.

AppLocker vs WDAC: Choosing the Right Technology

Both AppLocker and WDAC control which code can execute on a Windows system, but they serve different purposes and have different capabilities. The key differences that should guide your choice are:

AppLocker advantages:

  • Rules can be applied per-user or per Active Directory security group. Different users on the same machine can have different application access.
  • Configuration is straightforward through Group Policy with a built-in GUI rule wizard.
  • Audit mode output includes the user account that triggered the event, making it easier to understand user behavior.
  • Well-documented with a long history in enterprise environments.

AppLocker limitations compared to WDAC:

  • AppLocker enforcement can be bypassed by a local administrator who stops the Application Identity service or uses alternative script execution methods.
  • AppLocker does not control kernel-mode code execution (drivers).
  • AppLocker is not integrated with Virtualization Based Security, so it provides no hardware-level enforcement guarantees.
  • On Server Core installations, AppLocker policies can be deployed and will be enforced, but the GUI tools (secpol.msc, gpedit.msc) are not available for local management.

In practice, many enterprises run AppLocker and WDAC together: WDAC handles kernel-level enforcement and provides the security guarantee, while AppLocker provides the per-user granularity that WDAC lacks.

AppLocker Rule Types and Rule Collections

AppLocker organizes rules into five rule collections, each covering a different category of executable content:

  • Executable Rules: Controls .exe and .com files. This is the primary collection for controlling application execution.
  • Windows Installer Rules: Controls .msi, .msp, and .mst files. Prevents unauthorized software installation.
  • Script Rules: Controls .ps1, .bat, .cmd, .vbs, and .js files. Critical for preventing script-based attacks.
  • DLL Rules: Controls .dll and .ocx files. This collection is the most performance-intensive and is disabled by default. Enable only when the security requirement justifies the overhead.
  • Packaged App Rules: Controls Windows Store (AppX) packages. Used to block or allow modern/UWP applications.

Each rule collection operates independently. You can enforce the Executable Rules collection while leaving Script Rules in audit mode. This is useful when gradually rolling out AppLocker in a new environment.

Creating AppLocker Rules in Group Policy

AppLocker rules are configured through Group Policy. The AppLocker node is located at:

Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker

To create AppLocker rules:

  1. Open the Group Policy Management Editor (gpme.msc) and edit or create a GPO
  2. Navigate to the AppLocker node
  3. Right-click on Executable Rules and choose Create New Rule
  4. The wizard guides you through Action (Allow or Deny), User/Group, and Conditions (Publisher, Path, or File Hash)
  5. Repeat for Script Rules, Windows Installer Rules, and other collections as needed

Before creating custom rules, always create the default rules first. Default rules ensure that Windows system files and applications in Program Files are always allowed, preventing accidental lockout. Right-click each collection and select Create Default Rules:

  • Executable Rules default rules: Allow all files in %PROGRAMFILES% and %WINDIR% for Everyone; Allow everything for the BUILTINAdministrators group
  • Script Rules default rules: Allow all scripts in %SYSTEMDRIVE%Windows for Everyone; Allow everything for Administrators
  • Windows Installer Rules default rules: Allow all digitally signed Windows Installer files for Everyone; Allow all files in %WINDIR%Installer

Rule Condition Types: Path, Hash, and Publisher Rules

Publisher rules are the recommended rule type for commercially signed software. They allow a file to run if it is signed by a specific publisher (matched against the certificate chain). Publisher rules are resilient to software updates because the signature remains the same across versions. Publisher rules can be tuned to allow:

  • Any file from a publisher (broad)
  • Any version of a specific product from a publisher
  • A specific version and above of a product
  • An exact file version (most restrictive)

Path rules allow or deny execution based on file system path. They are simple to configure but are weaker from a security perspective because any user who can write to the allowed path can place executable files there and have them run. Path rules use environment variables for portability:

%PROGRAMFILES%MyApp*
%WINDIR%*
\ServerShareApprovedApps*

Hash rules create a cryptographic hash of the exact file and only allow that specific binary to run. Hash rules are the most precise but are maintenance-intensive because any update to the file changes its hash, requiring a policy update. Use hash rules for:

  • Unsigned legacy executables that cannot use publisher rules
  • Allowing a specific known-good version of a file while blocking all other versions
  • Creating deny rules for specific known-bad file hashes

AppLocker Audit Mode vs Enforce Mode

Each AppLocker rule collection can be independently configured as Audit Only or Enforce. This granularity is valuable during deployment as it lets you audit one collection while enforcing another.

To configure the enforcement mode for a rule collection in Group Policy:

  1. Right-click the AppLocker node in the GPO and select Properties
  2. Under the Enforcement tab, each collection has a dropdown: Not Configured, Audit only, or Enforce rules
  3. Set Executable Rules to Audit only initially
  4. After monitoring the audit log for 1–2 weeks and adding required rules, switch to Enforce rules

In Audit Only mode, Event ID 8003 is generated when a file would have been blocked. In Enforce mode, Event ID 8004 is generated when a file is actually blocked. The Application Identity service must be running for AppLocker to function:

# Ensure the Application Identity service is running and set to Automatic
Set-Service -Name "AppIDSvc" -StartupType Automatic
Start-Service -Name "AppIDSvc"
Get-Service -Name "AppIDSvc"

Without the Application Identity service running, AppLocker rules in Enforce mode will not be applied and the system will allow all code to run.

Managing AppLocker Policies with PowerShell

The AppLocker PowerShell module provides cmdlets to view, test, and manage AppLocker policies without the Group Policy GUI. These cmdlets are essential for Server Core management and for scripting policy deployments.

To retrieve the currently effective AppLocker policy on the local machine:

Get-AppLockerPolicy -Effective

To export the effective policy to an XML file:

Get-AppLockerPolicy -Effective | Get-AppLockerPolicyXml | Out-File "C:AppLockerEffectivePolicy.xml" -Encoding UTF8

To retrieve the local (non-GPO) AppLocker policy:

Get-AppLockerPolicy -Local

To apply a new AppLocker policy from an XML file to the local machine:

Set-AppLockerPolicy -XmlPolicy "C:AppLockerNewPolicy.xml"

To merge a new policy into the existing local policy (preserving existing rules):

Set-AppLockerPolicy -XmlPolicy "C:AppLockerAdditionalRules.xml" -Merge

To generate AppLocker file information for all executables in a directory (useful for creating rules based on an application installation):

Get-AppLockerFileInformation -Directory "C:Program FilesMyApp" -Recurse | Format-List

This outputs path, publisher, and hash information for every file, which can then be piped to New-AppLockerPolicy to generate an XML policy:

Get-AppLockerFileInformation -Directory "C:Program FilesMyApp" -Recurse | New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml | Out-File "C:AppLockerAppPolicy.xml"

Testing Policies with Test-AppLockerPolicy

Before deploying a policy in enforce mode, you can test it against a specific executable or a set of files using Test-AppLockerPolicy. This cmdlet simulates the policy evaluation without actually blocking anything and tells you whether a file would be allowed or denied.

To test whether a specific file is allowed by the effective policy for a given user:

Test-AppLockerPolicy -Path "C:Program FilesMyAppmyapp.exe" -User DOMAINTestUser

To test all executables in a directory against the effective policy:

Get-AppLockerFileInformation -Directory "C:Program FilesMyApp" -Recurse | Test-AppLockerPolicy -User Everyone

To test against a specific policy file rather than the effective policy:

Get-AppLockerFileInformation -Directory "C:Program FilesMyApp" -Recurse | Test-AppLockerPolicy -XmlPolicy "C:AppLockerTestPolicy.xml" -User DOMAINJohnDoe

The output includes the PolicyDecision field (Allowed or Denied), the matching rule that made the decision, and the file path. Use this to validate that all required application files are covered before switching to enforce mode.

AppLocker Event Log — Event IDs 8003 and 8004

AppLocker logs events to the Microsoft-Windows-AppLocker event channels. Each rule collection has its own log:

  • Microsoft-Windows-AppLocker/EXE and DLL — Executable and DLL rule events
  • Microsoft-Windows-AppLocker/MSI and Script — Windows Installer and Script rule events
  • Microsoft-Windows-AppLocker/Packaged app-Execution — Packaged App rule events

The two key event IDs:

  • Event ID 8003: File was allowed to run but the rule collection is in Audit mode — the file would have been blocked by an Enforce policy. This is the primary audit event for policy refinement.
  • Event ID 8004: File was blocked from running. Enforce mode is active and the file matched a Deny rule or no Allow rule covered it.

To query AppLocker blocked events from the last 24 hours:

$StartTime = (Get-Date).AddDays(-1)
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" | Where-Object { $_.Id -eq 8004 -and $_.TimeCreated -gt $StartTime } | Select-Object TimeCreated, Message | Format-List

To find all audit events across all AppLocker logs:

$Logs = @("Microsoft-Windows-AppLocker/EXE and DLL", "Microsoft-Windows-AppLocker/MSI and Script", "Microsoft-Windows-AppLocker/Packaged app-Execution")
foreach ($Log in $Logs) {
    Write-Host "=== $Log ===" -ForegroundColor Cyan
    Get-WinEvent -LogName $Log -ErrorAction SilentlyContinue | Where-Object { $_.Id -in @(8003, 8004) } | Select-Object TimeCreated, Id, Message | Format-List
}

AppLocker Limitations on Server Core

Windows Server 2022 Server Core is a minimal installation without the Desktop Experience shell. This affects AppLocker management in several important ways:

  • secpol.msc is not available: The Local Security Policy editor used for local AppLocker configuration requires the GUI shell. All local policy management must be done via PowerShell cmdlets (Set-AppLockerPolicy, Get-AppLockerPolicy).
  • gpedit.msc is not available: The Local Group Policy Editor is also absent. For domain-joined servers, manage AppLocker through domain GPOs from a management workstation. For non-domain servers, use PowerShell to write the AppLocker policy XML directly.
  • AppLocker rule wizard is unavailable: The automatic rule generation wizard that scans installed software only runs from a machine with the Desktop Experience. Generate rules on a reference machine with the same software installed, then export and apply them to Server Core instances.
  • Event Viewer GUI is absent: Monitor AppLocker events using PowerShell with Get-WinEvent, forwarded event subscriptions to a central log server, or by shipping logs to a SIEM.

The recommended approach for AppLocker on Server Core is to manage all policy through domain Group Policy Objects, with centralized log collection to a Windows Event Collector or SIEM. This way, the Server Core installation has no local management dependency and policies are consistent across all server instances in the same OU.

To confirm AppLocker is enforcing on a Server Core machine with no GUI, query the effective policy and service state:

# Check Application Identity service
Get-Service AppIDSvc

# View effective policy summary
Get-AppLockerPolicy -Effective

# View recent block events
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaxEvents 50 | Where-Object {$_.Id -eq 8004}

AppLocker, when properly configured with publisher rules, default rules, and regular policy reviews, provides a strong layer of application control for Windows Server 2022 environments. Combined with regular audit log monitoring and the use of Test-AppLockerPolicy before policy changes go live, it significantly reduces the attack surface available to malware and unauthorized software on your server fleet.