The starting point.
I worked on application-control restrictions for Windows endpoints, including command shells and PowerShell. The practical challenge was not just making a policy appear in Intune: it was checking which execution paths were actually allowed or blocked, and preserving legitimate administration.
What I did.
- I tested command execution in different user contexts and checked the effective behavior rather than relying only on assignment status.
- I used PowerShell to review AppLocker EXE and DLL events and look for activity involving cmd.exe, powershell.exe and pwsh.exe.
- I kept policy behavior separate from application availability. A missing PowerShell 7 executable, for example, is not evidence that AppLocker blocked it.
Decisions & trade-offs.
Observe before enforcing
Audit mode helps reveal legitimate execution paths before a restrictive rule interrupts them. The trade-off is that audit findings are evidence of potential impact, not active blocking.
Preserve administrative access
Standard-user restrictions and administrative workflows need separate tests. An administrator being able to run a shell does not establish that every user can.
Prefer a small, observable change
A narrow pilot makes an unexpected block easier to attribute and reverse than changing several control layers at once.
Read AppLocker shell events
A read-only example reconstructed for this case study. It inspects the EXE and DLL log without changing policy.
$events = Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-AppLocker/EXE and DLL'
Id = 8002,8003,8004
StartTime = (Get-Date).AddHours(-24)
} -ErrorAction SilentlyContinue
$events |
Where-Object {
$_.Message -match '(?i)cmd\.exe|powershell\.exe|pwsh\.exe'
} |
Select-Object TimeCreated,Id,MessageWhat I checked.
The checks combined actual command execution with local event records. That let me distinguish an allowed action, an audit-mode would-block event and an enforced block. I also checked whether the executable under test existed at the expected path.
Scope & limits.
These notes describe specific configuration and validation work, not a claim that every device or application was tested. Event collection, policy scope and user context still determine what the evidence covers.
A configured control and a validated control are not the same thing.