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.
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