AppControl for Business - Managed Installers Part 3: How ConfigMgr and Intune Actually Implement It and defining your own

In Part 1, we explained how Managed Installers work: AppLocker policy defines trusted processes, those processes tag files with NTFS Extended Attributes, and WDAC Rule Option 13 tells your policy to trust those tagged files.

In Part 2, we covered the backlog problem and how security catalogs solve it.

Now it's time to look at how managed installers are actually configured in ConfigMgr and Intune environments. Both platforms have built-in support for setting up managed installers for their own processes, but they do it differently—and those differences have real operational consequences that you need to understand before deploying.

The one thing to keep in mind as we compare implementations: the AppLocker MI policy has its own EnforcementMode setting on the ManagedInstaller RuleCollection. This is separate from your WDAC policy's audit/enforce mode. ConfigMgr and Intune make different choices here, and as we'll see, that has real consequences for your event logs.

Microsoft themselves acknowledge this in their managed installer documentation:

"if applied on a device that doesn't currently have any AppLocker policy, you will see a large increase in warning events generated in the AppLocker - EXE and DLL event log." 

They recommend adjusting your event forwarding configuration to only collect Error events or stop collecting events from that log altogether. The Intune documentation goes even further, recommending you turn off AppLocker event collection in Log Analytics entirely (except for MSI and Script logs) to avoid unexpected billing costs.

ConfigMgr's Managed Installer Implementation

When you enable WDAC through ConfigMgr's built-in Application Control settings, ConfigMgr automatically configures the managed installer for you. Here's what happens under the hood.

What ConfigMgr Configures

ConfigMgr defines two processes as managed installers:

CCMSetup.exe — the ConfigMgr client setup/installation process

CCMExec.exe — the main ConfigMgr client execution process that handles all application deployments

The managed installer ManagedInstaller RuleCollection uses EnforcementMode="Enabled" — not AuditOnly.

How ConfigMgr Deploys It

ConfigMgr uses a Configuration Baseline to deploy the managed installer AppLocker policy. The detection and remediation logic works as follows:

The detection script checks whether the effective AppLocker policy already contains a ManagedInstaller rule for CCMSetup and CCMExec. If both are present, the policy is considered compliant and no changes are made.

If the policy is not compliant, the remediation script runs. It starts the Group Policy Service, sets the AppLocker filter driver (applockerfltr) to auto-start, creates the AppLocker policy from an embedded XML template, and merges it with any existing AppLocker policies on the device. The script then loops until the policy is confirmed as created or updated, and re-checks compliance.

Targeting is done through ConfigMgr collections, giving you the standard ConfigMgr deployment controls you're used to.

The Enforcement Mode Consequence

Because ConfigMgr uses EnforcementMode="Enabled" on the ManagedInstaller RuleCollection, AppLocker generates Event ID 8004 (executable blocked) entries in the AppLocker event logs. These are logged at the Error level.

These are false positives. Nothing is actually being blocked — the dummy rules in the AppLocker policy are the only "real" rules, and they target non-existent binaries. But AppLocker's enforcement mode dutifully logs every executable and script that doesn't match an explicit allow rule as a block event.

The problem is that Event ID 8004 at Error level looks alarming. If your SIEM, your security operations team, or your monitoring tools flag AppLocker Error events, you'll see a flood of alerts for perfectly normal Windows activity. Conhost.exe, svchost.exe, your line-of-business applications — they'll all generate 8004 errors because they don't match the dummy AppLocker rules.

If you look at the XML view of these events, you'll notice the PolicyName field says MANAGEDINSTALLER. That's your indicator that these are MI-related false positives, not actual AppLocker enforcement actions. You can filter on this PolicyName to suppress or ignore them in your monitoring.

What ConfigMgr Doesn't Cover

ConfigMgr's built-in MI only covers applications deployed through ConfigMgr itself. If you use third-party patching tools (like Patch My PC, ManageEngine, or similar), those tools typically don't use CCMExec.exe as their installation process. They often use the Windows Update Agent (wuauclt.exe) or their own installation processes.

This means you'll need additional managed installers for third-party patching. At minimum, you should consider adding wuauclt.exe/wuaucltcore.exe as a managed installer if you're using any solution that leverages Windows Update Agent for patch deployment. This requires creating a separate AppLocker MI policy for wuauclt.exe/wuaucltcore.exe and merging it with the existing applocker policy as configmgr built-in controls don't allow you to add your own Applocker rules.

Intune's Managed Installer Implementation

What Intune Configures

Microsoft.Management.Services.IntuneWindowsAgent.exe (commonly referred to as the Intune Management Extension, or IME)

Unlike ConfigMgr which uses two processes, Intune only needs one. The IME handles all Win32 application deployments, and since Intune doesn't have a separate "client setup" process like CCMSetup.exe, one managed installer entry is sufficient.

The managed installer ManagedInstaller RuleCollection uses EnforcementMode="AuditOnly" — not Enabled.

How Intune Deploys It

Intune uses a hidden Proactive Remediation (now called Remediations in the Intune portal) to deploy the managed installer policy. When you enable the managed installer setting in Intune's "App Control for Business" section under Endpoint Security, Intune creates a remediation script package that targets devices through Entra ID groups.

The detection script contains the AppLocker XML policy with AuditOnly enforcement mode, dummy block rules, and the Intune Management Extension as a managed installer. It verifies compliance by checking whether the specific FilePublisherRule (with a known Rule ID) is present in the effective AppLocker policy.

If the rule is found, the detection script marks the device as compliant and sets a registry key: HKLM:\Software\Microsoft\IntuneManagementExtension\SideCarPolicies\ManagedInstallerEnabled.

If the detection script finds the policy is not compliant, the remediation script runs. It starts the required services (AppID, AppIDSvc, and the AppLocker filter driver), waits for them to initialize, and then merges the AppLocker policy with any existing policies on the device.

The AuditOnly Consequence (and the False Positive Problem)

This is where the operational difference between ConfigMgr and Intune shows up — not in managed installer functionality (that works the same regardless of enforcement mode), but in the type of false positive events generated.

Because Intune uses EnforcementMode="AuditOnly", the AppLocker engine generates Event ID 8003 (executable audited) entries in the AppLocker event logs. These are logged at the Warning level.

Just like ConfigMgr's 8004 errors, these are false positives. Every executable, DLL, and script that runs on the device and doesn't match an explicit AppLocker rule generates an audit event. Since you only have dummy rules in the policy, that means essentially everything triggers a warning.

The difference from ConfigMgr: warnings are less scary than errors. An 8003 Warning saying "this executable was audited" is less likely to cause panic than an 8004 Error saying "this executable was blocked." Both are harmless false positives caused by the managed installer policy, but the Error-level events from ConfigMgr's Enabled mode tend to generate more support tickets and SIEM alerts.

If you look at the XML view of these 8003 events, you'll see the same telltale indicator: the PolicyName field says MANAGEDINSTALLER. This confirms these are generated by the MI AppLocker policy and can be safely filtered out of your monitoring.

On a typical workstation, expect hundreds to thousands of these AppLocker audit events per day. They're informational noise, but they fill up log space and can trigger false-positive alerts in security monitoring tools that flag any AppLocker events as suspicious.

Identifying MI False Positives in Defender for Endpoint

If you're a Microsoft Defender for Endpoint customer, you can use Advanced Hunting to query for these MI-related false positives across your entire environment. DfE forwards AppLocker events as ActionTypes in the DeviceEvents table:

AppControlExecutableAudited (Event ID 8003) — the AuditOnly false positives from Intune's enforcement mode

AppControlExecutableBlocked (Event ID 8004) — the Enabled false positives from ConfigMgr's enforcement mode

3rd Party Patching in Intune Environments

Third-party patching solutions in Intune environments (like Patch My PC, or Intune's own third-party app catalog) typically deploy through the Intune Management Extension. This means those patches get the benefit of managed installer trust automatically, since the IME is the process writing files to disk.

This is different from ConfigMgr environments where third-party patching tools often bypass the ConfigMgr client entirely and use Windows Update Agent instead.

Defining Your Own Managed Installers

Not every environment uses ConfigMgr or Intune exclusively. You might use PDQ Deploy, Chocolatey, IBM BigFix, Liquit, or custom deployment scripts. In these cases, you need to create your own managed installer AppLocker policy.

The process is straightforward but has several steps that are easy to get wrong:

Step 1: Generate the Base Policy

Get-ChildItem <path-to-installer-exe> | 
  Get-AppLockerFileInformation | 
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Xml > AppLocker_MI.xml

This generates an AppLocker policy with an Exe RuleCollection. The output uses EnforcementMode="NotConfigured" by default, which won't work for managed installer purposes.

Step 2: Modify the Rule Collection Type

Change the RuleCollection Type from "Exe" to "ManagedInstaller" in the XML. This tells AppLocker that this rule defines a managed installer rather than an application control rule.

Step 3: Set the Enforcement Mode

Change EnforcementMode from "NotConfigured" to either "AuditOnly" or "Enabled".

We recommend AuditOnly due to the difference in eventlogs (warnings vs errors).

Step 4: Consider ProductName and Version Numbers

When the PowerShell command generates the publisher rule, it captures the exact ProductName and version from the binary. Think carefully about whether you want to keep these restrictions. Pinning to a specific version means the managed installer will stop working when the process updates. Setting the maximum version to "*" (or removing the version constraint) allows any version of the process from that publisher to act as a managed installer—more practical, but slightly less restrictive.

Step 5: Add Dummy Exe and Dll Rules

The AppLocker policy needs at least one Exe and one Dll RuleCollection entry to be valid. Add dummy deny rules that target a non-existent binary (like a fictional hash). These rules will never match a real file.

Step 6: Add RuleCollectionExtensions

Add the RuleCollectionExtensions node to the Exe RuleCollection with Services and SystemApps entries. Without the Services extension, managed installers running as Windows services won't be tracked. Without SystemApps, inbox store applications won't be included in the trust chain.

Step 7: Deploy and Merge

Use Set-AppLockerPolicy with the -Merge parameter to add your MI policy to any existing AppLocker policies on the device. Don't use Set-AppLockerPolicy without -Merge or you'll overwrite any existing ConfigMgr or Intune MI configurations.

Hybrid and Co-Managed Environments

Many organizations run both ConfigMgr and Intune, either as part of a co-management transition or as a permanent architecture. In these environments, you need managed installers for both platforms.

You could potentially enable the Managed installer functionality in both management platforms using the built-in controls as they should both merge with an existing applocker policy or you take matter into your own hands and craft the policy yourself and deploy it using whatever means you want.

As an alternative, you can use the AppControl.AI managed installer script (based on PSADT) to handle multiple MI's. The script supports

• ConfigMgr

• Intune

• Windows Update Agent (wuauclt)

• Liquit

• IBM BigFix

It uses AuditOnly enforcement mode and doesn't conflict with either ConfigMgr's or Intune's built-in MI setup process. There are variables available to control the minimum agent version as well.

If you are using a different management solution, feel free to contact us so we can work with you to add it to this list!

Verifying Your Managed Installer Configuration

Regardless of which platform you use, the verification process is the same:

Check the effective AppLocker policy:

Get-AppLockerPolicy -Effective -Xml | Out-File AppLockerPolicy.xml

Open the XML and verify that your ManagedInstaller RuleCollection exists with the correct processes, enforcement mode, and RuleCollectionExtensions.

Check prerequisites are running:

fltmc filters

Look for applockerfltr in the output. If it's not listed or shows 0 instances, the AppLocker filter driver isn't loaded and managed installer won't work.

Check the AppID service:

Get-Service AppIDSvc

It should be running. If it's not, managed installer tracking won't function.

Test with an actual deployment:

Deploy an application through your managed installer and then check the Extended Attributes:

fsutil file queryea "C:\Program Files\YourApp\application.exe"

If you see $KERNEL.SMARTLOCKER.ORIGINCLAIM, the managed installer is working correctly.

---

Have questions about your managed installer configuration? Reach out to us at info@appcontrol.ai