Applocker with Windows Installer rules and SCCM 2012 RRS feed

  • Question

  • Hi,

    We have been running Applocker since two years on Windows 7 Enterprise clients with SCCM 2007 as management and distribution tool.
    This setup was working fine until we migrated to SCCM 2012 and started to encounter problems with msi-packages not being able to self-heal when the source was the sccm client cache.

    We have recreated this scenario in a lab environment.
    Our setup is this:

    • Windows 2008 R2 (DC)
    • Windows 7 Enterprise SP1 (Client)
    • Standard user (not admin)
    • SCCM 2012 R2 (upgraded from 2007)
    • Applocker with these rules:
      • Executable Default rules enabled (Enforced)
      • Windows Installer Default rules enabled (Enforced)
        • Exception for %WINDIR% (where SCCM cache is located)
      • Script Default Rules enabled (Enforced)
      • Application msi-package with self-heal (omus) and advertised shortcuts

    We install the application from the sccm cache (%windir%\ccmcache) and then trigger a self-heal (user components being copied to the user profile).

    What we see on the client is: Error 1718. File C:\Windows\ccmcache\54\application.msi was rejected by digital signature policy.

    Event log is showing: Event 1008: The installation of C:\Windows\ccmcache\54\application.msi is not permitted due to an error in software restriction policy processing. The object cannot be trusted.

    It looks like the file cannot be evaluated by Applocker and therefore is not trusted. We get an Access Denied error when testing AppLocker-policy with the following PS-command,
    Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path C:\Windows\ccmcache\54\application.msi. This command works fine when accessing files in the cache-folder on a SCCM2007-client.

    For testing purposes we recreated a similar folder structure: C:\Windows\Folder1\Folder2\application.msi where the user has no permissions on Folder2 and read on the other folders and the File.msi. This is how the permissions look like in SCCM 2012 (no user permissions on %Windir%\ccmcache). Applocker cannot evaluate the trust-level of application.msi.

    The GPO setting “Bypass traverse checking” is set to everyone.

    As we can see, the permissions are the same on SCCM 2007 client cache (%Windir%\syswow64\ccm\cache) but we do not have this issue there.

    Has anyone got Applocker (with windows installer rules actived) to work with SCCM 2012 and windows installer self-heal?

    • Moved by Cloud_TS Tuesday, March 4, 2014 2:10 AM move to appropriate forum
    Monday, March 3, 2014 9:59 AM


All replies

  • The msi in SCCM 2007 and SCCM 2012 is the same file? The error means SRP encounters an error when processing the MSI signature check.

    I suggest you put a small msi file into SCCM 2012 client cache folder, and run the policy check to see whether the file can be allowed.

    Juke Chou

    TechNet Community Support

    • Marked as answer by Juke Chou Sunday, March 30, 2014 2:54 PM
    Tuesday, March 11, 2014 4:58 PM
    • Marked as answer by Juke Chou Sunday, March 30, 2014 2:54 PM
    Tuesday, March 11, 2014 4:59 PM
  • Hi Niklas

    I had same problem today and you can solve the problem if you set NTFS security read permission for Authenticated users on C:\Windows\ccmcache folder. 

    Also create a applocker path to C:\Windows\ccmcache\*.*

    Wednesday, April 2, 2014 6:37 PM
  • I've run into this a few times now. It's very strange and annoying. I'm still not convinced it's an applocker issue and not SCCM. Applocker worked fine in 2007.
    Wednesday, November 15, 2017 2:04 PM
  • To test I compared the rights on the 2007 client folder and files within the cache. They look identical.  This seems like some sort of bug. I see no reason for it to fail in CB but succeed in 2007 even without.

    we have an applocker rule that lets any msi install from anywhere and this still happens.

    We attempted as a fix to take users and pc's out of the scope of applocker and the issue still happened.  I'm very surprised this issue hasn't happened to more people.

    • Edited by dynas2001 Thursday, November 23, 2017 7:48 PM
    Thursday, November 23, 2017 7:12 PM
  • Dynas,

    This issue seems to occur because applocker is hard failing when it fails to scan the file, in this because the user can't access. The way SCCM launches executables on behalf of the user in a folder the user can't access (ccmcache) seems to trigger this bug when you deploying an application with "install for user" through SCCM with any sort of applocker policy enabled.

    The fix seems to be to deploy a GPO granting NT AUTHORITY\INTERACTIVE read and Execute access to your ccmcache folder.

    Friday, December 1, 2017 4:40 PM