DEPLOYING WINDOWS 10 APPLICATION CONTROL POLICY

mbrown2180 

Thank you for this information.

At this moment we still have problems with this solution when using a cloud-only solution...

To explain my problem, my scenario:

- Cloud-Only, Windows is Intune only managed (MDM enrolled with AutoPilot) (There's no SCCM or on-premises managed solutions)

- Using MDAC, created a custom policy, starting with the default template : C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml

- Because all users are "standard users", we have added some exclussions with filepaths : C:\Windows\*, C:\Program Files\*, C:\Program Files (x86)\*

- We have converted the policy to a BIN file, using OMA-URL we have deployed it to "Test" systems in Intune.

- MDAC is doing it's job after deployment, it's working nice.

But we have seen some scenario's with Application Deployments that MDAC is preventing installation, without a nice solution...

For example:

- We have downloaded a application from a vendor website, downloaded the MSI from the original source website... but it's unsigned...

- But we have seen that the "Filepath" exclussion isn't working for MSI, seems to be only for EXE? So starting in C:\Windows\IMEcache isn't working... 

- We can create a hash rule, so it seems to be no problem in first place.

- But sometimes we see strange behaviours, for example the MSI's extracts itself to another location, where it starts another EXE/MSI installation, for example somewhere in the C:\ProgramData subfolders or in C:\Windows\System32\config\systemprofile\AppData\Local\ subfolders.

- Sometime we have to add multiple hashes to let the installation work... sometimes it's a problem, because when installation is succesfull it will delete the "extra extracted installation folders" so it will be imposible to track al blocking MSI's...

- Also when the application needs to be replaced by a new version, will must hash everything again. If it was only the first installer it is not a problem, but al the sub installation files are.

We thought with "Managed Installer" option it will be possible to give all "Intune Deployments" sort kind of "Exception" from MDAC, everything from Intune we trust... doesn't matter if it's a MSI/EXE or Script...

But this seems to be difficult to setup...

When trying to upload the XML file with the Managed Installer for Intune, we have to split the XML for EXE, MSI, SCRIPT, etc... like:

./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/groupname/MSI/Policy

./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/groupname/EXE/Policy

etc

So how can we deploy the Managed Installer XML correctly with Intune.... ?

Or is there another solution for this, like creating a .intunewin file with the XML and create a CMD which will import the Applocker XML file?

And also in the example file for Managed Installer, we see only EXE and DLL, is it also possbile to add MSI in the XML for Managed Installer? 

We have also some problems with deploying firmware/bios settings with Dell systems, because also these executables will extract the extra installers to C:\ProgramData folders and will execute there, also not signed...

C:\ProgramData is a user-writable location, to add this folder to the filepath is not an option...

When deploying MDAC and Applocker, which rule will win? Sometimes we see Applocker can complement MDAC...

Many questions, but cannot find all answers on the internet...