Verify AppLocker Policy

If you’re using AppLocker in your Windows 7 environment as I’m, you sometimes maybe want to verify that AppLocker is not the culprit. Today I ran into a problem where a custom MSI package would’nt install and exited with error code 1625. The error was:

The installation of <MSI-file> is not permitted due to an error in software restriction policy processing. The object cannot be trusted."

My instinct lead me to believe that there were some AppLocker policy blocking the installation. Here’s an easy PowerShell command to test just that.

Open up a PowerShell prompt as the user you want to verify AppLocker rules for, you could shift + right-click on the PowerShell icon in order to Run as another user.

Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path 'C:\Windows\ccmcache\t\file.msi' | fl

The output should look something like:

FilePath : C:\Windows\ccmcache\t\file.msi
PolicyDecision : Allowed
MatchingRule : C:\Windows\ccmcache\*

In this case the problem was clearly not an AppLocker policy, since the PolicyDecision shows Allowed. The problem was when I choose Install for user in the Deployment properties, the logged on user didn’t have read rights on C:\Windows\ccmcache and recursive folders. In order to change that, I ran the following command.

icacls C:\Windows\ccmcache /grant "Users":(OI)(CI)R /inheritance:r

The MSI installation for the user now completed without any problems.


Nickolaj Andersen

Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences such as Microsoft Ignite, NIC Conference and IT/Dev Connections including nordic user groups.

1 comment

  • I’m seeing this. So what is the issue here? Why is this an issue with SCCM 2016 and NOT 2007? BUG? where is the fix?

    You shouldn’t have to re-acl the folder for this basic behavior to work