How to Implement AppLocker Policies on Windows Server 2012 R2

AppLocker is a feature introduced in Windows Server 2008 R2 that allows administrators to specify exactly which applications, scripts, Windows Installer files, and DLLs are permitted to run. On Windows Server 2012 R2, AppLocker provides application whitelisting—one of the highest-value security controls available because it directly prevents unauthorized or malicious code from executing, even when malware manages to land on the filesystem. This tutorial covers creating and deploying AppLocker policies through Group Policy, with attention to rule types, enforcement modes, auditing, and common pitfalls.

Prerequisites

  • Windows Server 2012 R2 with Enterprise or Datacenter edition (AppLocker requires Enterprise or above for enforcement on servers)
  • The Application Identity service must be running—AppLocker will not enforce rules if this service is stopped
  • Domain Administrator access and GPMC for domain-wide deployment
  • A representative sample server on which to generate rules automatically before deploying

Step 1: Start and Configure the Application Identity Service

AppLocker depends on the Application Identity service (AppIDSvc). Start it and set it to automatic:

Set-Service -Name AppIDSvc -StartupType Automatic
Start-Service -Name AppIDSvc
Get-Service -Name AppIDSvc

Ensure the service is Running before any policies take effect. You can also configure this through Group Policy under Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity.

Step 2: Understand AppLocker Rule Collections

AppLocker organizes rules into five collections, each controlling a different type of executable content:

  • Executable rules — .exe and .com files
  • Windows Installer rules — .msi, .msp, and .mst files
  • Script rules — .ps1, .bat, .cmd, .vbs, and .js files
  • Packaged app rules — Windows Store apps
  • DLL rules — .dll and .ocx files (enable only if required; high performance overhead)

For a server hardening baseline, start with Executable, Windows Installer, and Script rules.

Step 3: Create Default Rules via PowerShell

AppLocker ships with default rules that allow Windows itself and installed programs under %ProgramFiles% and %SystemRoot% to run. Always create these defaults first to avoid locking yourself out:

# Create default executable rules
$policy = New-AppLockerPolicy -RuleType Publisher, Hash, Path `
    -User Everyone `
    -Optimize `
    -IgnoreMissingFileInformation

# Apply default rules (Audit mode first)
Set-AppLockerPolicy -PolicyObject $policy -Merge

Or use the Local Security Policy GUI: open secpol.msc, navigate to Application Control Policies → AppLocker, right-click Executable Rules, and select Create Default Rules. Repeat for Windows Installer and Script Rules.

Step 4: Generate Rules Automatically from Installed Applications

Before writing custom rules, scan a reference server to generate a rule set based on what is currently installed. This ensures that all legitimate software receives an allow rule before you enable enforcement mode:

# Generate publisher-based rules for executables in Program Files
$exeRules = Get-AppLockerFileInformation -Directory "C:Program Files" -Recurse -FileType Exe |
    New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -IgnoreMissingFileInformation

# Generate rules for Windows directory
$winRules = Get-AppLockerFileInformation -Directory "C:Windows" -Recurse -FileType Exe |
    New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -IgnoreMissingFileInformation

# Export to XML for review
$exeRules | ConvertTo-Xml | Out-File "C:AppLockerExeRules.xml"

Step 5: Configure AppLocker via Group Policy

Create a GPO for AppLocker policies. In GPMC, create a new GPO named AppLocker-Servers and link it to the target OU. Navigate to:

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

Right-click AppLocker and select Properties. Under each rule collection, set the enforcement mode:

  • Initial deployment: Audit only — rules are evaluated and logged but not enforced
  • After audit review: Enforce rules

Create a publisher rule that allows anything signed by Microsoft:

  1. Right-click Executable Rules → Create New Rule
  2. Select Allow, assign to Everyone
  3. Choose Publisher as the condition
  4. Browse to C:WindowsSystem32cmd.exe as a reference file
  5. Set the rule to match on publisher O=MICROSOFT CORPORATION at the publisher level (not the specific file)

Step 6: Create Custom Rules via PowerShell

Create a path-based allow rule for your application directory:

# Allow everything in a custom application folder
$customRule = New-Object Microsoft.Security.ApplicationId.PolicyManagement.PolicyModel.FilePathRule
# Use the AppLocker PowerShell module for path rules:
$pathInfo = Get-AppLockerFileInformation -Path "D:Applications*"
$pathPolicy = $pathInfo | New-AppLockerPolicy -RuleType Path -User Everyone -RuleNamePrefix "Custom-App"
Set-AppLockerPolicy -PolicyObject $pathPolicy -Merge

Create a hash-based rule for a specific executable (useful for unsigned scripts or tools):

$hashInfo = Get-AppLockerFileInformation -Path "C:Toolspsexec.exe"
$hashPolicy = $hashInfo | New-AppLockerPolicy -RuleType Hash -User Everyone -RuleNamePrefix "Tool-PSExec"
Set-AppLockerPolicy -PolicyObject $hashPolicy -Merge

Step 7: Test in Audit Mode

With enforcement mode set to Audit Only, run normal workloads on the target server for at least a week. Query the AppLocker event log to identify what would have been blocked:

Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" |
    Where-Object { $_.Id -eq 8003 -or $_.Id -eq 8004 } |
    Select-Object TimeCreated, Message |
    Format-List

Event ID 8003 = file would have been blocked; Event ID 8004 = file was blocked. Use these events to identify any legitimate software that needs additional allow rules before switching to enforcement mode.

Step 8: Switch to Enforcement Mode

After confirming the policy captures all legitimate software, switch to enforcement:

# Export current policy
Get-AppLockerPolicy -Effective -Xml | Out-File "C:AppLockerEffectivePolicy.xml"

# Review in XML, then apply enforcement via GPO (change Enforcement in the XML)
# Or use secpol.msc → AppLocker → Properties → change Configured to "Enforce rules"

Apply the updated GPO:

gpupdate /force

Step 9: Manage Exceptions for Administrators

AppLocker’s default rules typically exempt the built-in Administrator account. For additional administrator accounts, create exception rules or use a separate AppLocker policy for admin OUs with broader permissions. Never create a blanket “allow all” rule for the Administrators group on hardened servers—administrators should still run only approved software.

Step 10: Verify Enforcement

Test that the policy is blocking unapproved executables:

# View effective policy on local machine
Get-AppLockerPolicy -Effective | Format-List

# Test a specific file against the policy
Test-AppLockerPolicy -Path "C:tempunauthorized.exe" -User Everyone

The output will indicate whether the file would be Allowed or Denied under the current policy.

Summary

AppLocker application whitelisting on Windows Server 2012 R2 is one of the most impactful security controls you can implement. By ensuring the Application Identity service is running, generating a rule baseline from installed software, deploying in audit mode first, and transitioning to enforcement only after validating the policy, you dramatically reduce the attack surface available to malware and unauthorized tools. Maintain the AppLocker policy as part of your change management process—any new application deployment requires a corresponding allow rule before the software can run in production.