App Control for Business Part 2: How to Avoid the Exception Factory

In Part 1, you were the person walking through a dark archive with a flashlight and a clipboard. Audit mode was the flashlight. Documentation was the clipboard. The job was to figure out what was hiding on the shelves before enforcement started throwing boxes away.

Now someone has turned on the overhead lights.

Your App Control for Business policy is enforced on a pilot group. The obvious blocks have been handled, the help desk has a runbook, and nobody has called to report that their laptop has become an expensive paperweight. That feels like the finish line.

It is not.

Most App Control deployments do not fall apart during the first enforcement assignment. They slowly lose their value afterward. A blocked application creates a ticket. The ticket creates an allow rule. Another update creates another rule. Eighteen months later, the policy contains a small archaeological record of every urgent request the endpoint team has ever received, and nobody can explain what half of it still protects.

That is the exception factory. This post is about keeping it closed.

Start With Managed Installer

I am putting Managed Installer first for a reason. If Intune is your application delivery channel, Managed Installer can be the difference between an allow list you can maintain and a policy that needs another rule every time an application changes versions.

Without Managed Installer, every application needs its own trust decision. Depending on the rule type, a new version may need another decision. Multiply that across the software catalog and you have built a second job for the endpoint team.

Managed Installer changes the model. Applications deployed through an approved software distribution tool are tagged as they are written to disk. An App Control policy configured to trust Managed Installer can then allow those tagged files. You are trusting the approved delivery path instead of trying to inventory every binary that travels through it.

That is useful. It is not magic, and it is not a substitute for understanding the applications you deploy.

Configure the Intune Management Extension as a Managed Installer

You can build the required AppLocker configuration manually, but Intune gives you a much cleaner path.

In the Intune admin center, go to Endpoint security > App Control for Business > Managed installer, then select Create. Set Enable Intune Managed Extension as Managed Installer to Enabled, assign the policy to a device group, and create it. Intune handles the AppLocker policy used to designate the Intune Management Extension as a Managed Installer.

Treat it as a planned change performed by a named administrator. It should not be the thing someone enables from a phone while waiting in the school pickup line.

Managed Installer assignment also supports deployment rings. Microsoft replaced the old tenant-wide switch with policies that can be assigned to selected device groups. If you want a staged rollout, replace that converted policy with scoped policies and move through your normal rings.

Do not use the portal status as a stopwatch. Microsoft notes that delivery to devices can take up to 30 minutes after the policy becomes active. The Managed Installer overview can take up to 24 hours to update its device status and trend data.

Tagging Starts After the Policy Arrives

Managed Installer tagging is not retroactive. Applications installed before the configuration reached the device do not suddenly become trusted.

This is why Managed Installer belongs in the audit phase. Enable it early, deploy applications through the approved channel, and use the audit results to identify older applications that still need explicit rules. If you wait until enforcement day, the software already on the device remains untagged and your first pilot becomes a scavenger hunt.

Disabling or deleting the Managed Installer policy stops new devices and future installations from being configured as expected, but it does not remove the existing configuration from devices that already received it. Microsoft provides CatCleanIMEOnly.ps1 at aka.ms/intune_WDAC/CatCleanIMEOnly for that cleanup. Restart the Intune Management Extension service after the script runs.

Know Where Managed Installer Stops Helping

Managed Installer has several limitations that tend to show up later as mysterious application tickets.

• Self-updating applications: Files written by the application’s own updater do not receive the original Managed Installer claim. Deploy updates through the approved management channel, create explicit rules for the application, or carefully evaluate whether the updater itself should be designated as a Managed Installer.
• Installers that immediately run generated content: Some installers extract, download, or generate a binary and launch it immediately. That process can fall outside the Managed Installer heuristic.
• Kernel drivers: Managed Installer does not authorize kernel drivers. Required drivers need explicit allow rules.
• Boot-critical binaries and services: Managed Installer and Intelligent Security Graph decisions might not be available early enough in the boot sequence. Use explicit signer, file attribute, or hash rules for binaries, services, and drivers needed during startup.

There is also a security tradeoff. Managed Installer is a trust mechanism. Microsoft is clear that it does not provide the same guarantees as an explicit allow or deny rule. It works best when users operate as standard users and software installation is controlled. Local administrators, or malware already running with administrative rights, may be able to work around the policy’s intent.

If most of your users are local administrators, Managed Installer might still improve operations, but it does not repair the larger privilege problem.

Understand the Origin Claim

When a Managed Installer writes a file, Windows adds a kernel-managed extended attribute named $KERNEL.SMARTLOCKER.ORIGINCLAIM. That claim records where the file came from, whether the writer was trusted through Managed Installer or the Intelligent Security Graph, and whether that trust was inherited.

Trust follows the live process tree. The installer passes it to files it writes and to child processes it starts. The chain breaks when the trusted process tree ends or when a process crosses into another security context without carrying the claim forward.

This explains a common support ticket: Intune says the application installed successfully, but the application refuses to launch. Installation status and execution trust are separate decisions. Intune may have completed its job perfectly while App Control blocks a later file that never inherited the Managed Installer claim.

Verify the Claim on a Device

Use fsutil.exe to inspect the extended attribute on a file:

fsutil.exe file queryEA "C:\Program Files\YourApp\yourapp.exe"

fsutil.exe file queryEA "C:\Program Files\YourApp\yourapp.exe"

Find the first data row labeled 0000: and read it as four groups of four two-character values.

• The first value is 01.
• The fifth value identifies the source. 00 indicates Managed Installer and 01 indicates Intelligent Security Graph.
• The ninth value identifies how the file was created. 00 means the Managed Installer wrote it directly. 02 means it is a child-of-a-child file and needs another way to be authorized.

Managed Installer also depends on AppLocker components. From an elevated terminal, confirm that both services report STATE : 4 RUNNING:

sc.exe query appidsvc
sc.exe query AppLockerFltr

sc.exe query appidsvc
sc.exe query AppLockerFltr

If they are not running, use the command below and check again:

appidtel start

appidtel start

You can verify origin events centrally with Defender advanced hunting:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType in (
    "AppControlCodeIntegrityOriginAllowed",
    "AppControlCodeIntegrityOriginAudited",
    "AppControlCodeIntegrityOriginBlocked"
)
| summarize Count = count()
    by ActionType, DeviceName, bin(Timestamp, 1d)
| sort by Count desc

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType in (
    "AppControlCodeIntegrityOriginAllowed",
    "AppControlCodeIntegrityOriginAudited",
    "AppControlCodeIntegrityOriginBlocked"
)
| summarize Count = count()
    by ActionType, DeviceName, bin(Timestamp, 1d)
| sort by Count desc

These action types map to events 3090, 3091, and 3092. They show when Managed Installer origin or Intelligent Security Graph reputation contributed to an allow, audit, or block decision.

Watch for Three Deployment Traps

First, Microsoft Entra hybrid-joined devices need domain controller connectivity for the AppLocker policy involved in Managed Installer. That connectivity often is not available during Windows Autopilot. For hybrid-joined devices, make sure domain connectivity exists when applications install, or deploy the applications after provisioning finishes. Side note, if you’re hybrid joining devices from Autopilot, I’m not sure that we can be friends.

Second, the Intune policy designates the Intune Management Extension. It does not designate Configuration Manager. If ConfigMgr also needs to be a Managed Installer, configure that through Configuration Manager or use the ManagedInstaller switch with ccmsetup.exe as described in Microsoft’s guidance.

Third, review existing AppLocker XML before deployment. Intune’s Managed Installer configuration merges a policy containing a dummy rule with the policy already on the device. If an existing RuleCollection is set to NotConfigured and contains no rules, the merge can leave that collection enforced with only the dummy rule. Applications can fail to start, and Windows can fail to boot or sign in.

Remove empty NotConfigured rule collections before enabling Managed Installer. I have been down the recovery road before. It is not scenic.

Build a Policy Structure That Can Survive Change

Once Managed Installer carries most approved software, the App Control policy structure can stay simple. Simple is easier to explain, easier to test, and much harder to ruin during an urgent ticket.

Treat the base policy as boring and durable. It should contain the trust decisions that apply broadly, such as Windows components, Microsoft Store applications, organization-wide policy options, and other rules that truly belong on every targeted device.

Do not edit the base policy every time a team discovers a new application. (<- Probably the most common mistake that I see) Base policy changes have the largest blast radius. Frequent exceptions belong in supplemental policies with narrow assignments, clear ownership, and review dates.

Avoid the PolicyID Trap

A supplemental policy must be XML and must reference the PolicyID of the base policy it extends. One supplemental policy extends one base policy, although one base policy can have multiple supplementals.

Custom XML base policies receive a unique PolicyID. Intune base policies created with built-in controls use one of four fixed IDs:

Two base policies built with the same controls share the same PolicyID. Assignment is what keeps their supplemental policies separated. If the Executive and Help Desk base policies use the same built-in configuration, an assignment mistake can put the Help Desk remote support exception on executive devices.

That is not an XML problem. It is a change-control problem.

Use names that explain the policy without requiring a decoder ring:

ACB-Base-Windows-Production-v1.0
ACB-Supp-ContosoERP-Production-v1.0
ACB-Supp-Exception-INC123456-Expires-20261130

Assign Ownership Before the Tickets Arrive

When ownership is vague, the help desk becomes the decision maker and endpoint engineering becomes the emergency rule-writing department. Neither is a good long-term operating model.

Map ownership to the permissions and decisions people actually hold:

Set response targets before the first production issue. Define what a ticket must include, how quickly a business-impacting block is reviewed, who can approve a supplemental policy, and how long a temporary exception can remain active.

A temporary exception without an owner and an expiration date is not temporary. It is permanent access wearing a visitor badge.

Treat Exceptions as Decisions, Not Queue Items

A blocked-application ticket should be useful before anyone from engineering replies. Require the device, user, timestamp, complete file path, hash and signer when available, parent process, relevant App Control event, business justification, and a named application owner.

Before writing a rule, work through these questions in order:

1. Is the application already approved and available through Intune?
2. Is the user launching the expected file, or a temporary installer, updater, or helper component?
3. Is the file running from an acceptable location, or from Downloads, Temp, a profile folder, or removable media?
4. Can the application be packaged and delivered through Managed Installer instead of receiving a new allow rule?
5. What is the narrowest rule that solves the business need?
6. Is the request permanent, or should it expire after a project, migration, or vendor update?

Question 4 is why Managed Installer came first. In a healthy Intune environment, many blocked-application tickets should end with “package it correctly” instead of “add another rule.”

Document Every Rule

The XML is not the documentation. It tells Windows what to do, but it rarely tells the next administrator why the decision was made.

Every allow rule and exception should have a corresponding record that includes:

• The business reason for the rule
• The application and business owner
• The security approver
• The related incident, request, or change number
• The evidence used to make the decision
• The rule type and why that rule type was selected
• The assigned device scope
• The creation date and last review date
• The expiration date, if temporary
• The long-term remediation plan

I have worked in too many environments where a broad rule was clearly important to someone three years earlier, but nobody could remember who or why. Without the reason, owner, and approver, teams are afraid to remove anything. That is how an exception factory becomes permanent infrastructure.

Review the register on a schedule. Look for expired exceptions, rules with missing owners, rules unused during the review window, and supplementals assigned to more devices than intended.

The Evidence Lives Outside Intune

Intune can tell you whether the policy was assigned, delivered, and reported a status. It cannot tell you the full story of what the policy allowed or blocked.

This distinction matters. Intune provides device check-in, assignment, and per-setting status. Microsoft states that Intune does not yet include built-in event collection or reporting for App Control scenarios. Microsoft Defender for Endpoint provides the event collection, device timeline, and advanced hunting data needed to investigate policy behavior.

Part 1 focused on event 3076, which means a file would have been blocked while the policy was in audit mode. Enforcement introduces event 3077, which means the file was actually blocked.

Start with a seven-day summary of enforcement blocks:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "AppControlCodeIntegrityPolicyBlocked"
| summarize Blocks = count(), Devices = dcount(DeviceName)
    by FileName, FolderPath
| order by Blocks desc

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "AppControlCodeIntegrityPolicyBlocked"
| summarize Blocks = count(), Devices = dcount(DeviceName)
    by FileName, FolderPath
| order by Blocks desc

For one file, widen the query to every App Control event associated with it:

let FileToInvestigate = "yourapp.exe";
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "AppControl"
| where FileName =~ FileToInvestigate
| project Timestamp, DeviceName, ActionType, FileName,
    FolderPath, SHA256, InitiatingProcessFileName, AdditionalFields
| order by Timestamp desc

let FileToInvestigate = "yourapp.exe";
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType startswith "AppControl"
| where FileName =~ FileToInvestigate
| project Timestamp, DeviceName, ActionType, FileName,
    FolderPath, SHA256, InitiatingProcessFileName, AdditionalFields
| order by Timestamp desc

These are the action types I use most often during enforcement:

Native Defender XDR advanced hunting queries can search up to 30 days of data. If Defender tables are streamed into Microsoft Sentinel and configured with longer analytics-tier retention, advanced hunting can query the longer period. Know which data source and retention period you are using before presenting a 90-day trend based on 30 days of evidence.

Stage Every Material Change

Separate specialized devices early. A developer workstation, a kiosk, an AVD session host, and a standard laptop do not have the same application requirements. Forcing all of them through one base policy is how the base policy gets diluted until it barely controls anything.

Managed Installer policies should move through these rings too. Group assignment now gives you that option, so use it.

When Production Finds the Edge Cases

An approved application breaks after an update. Start with the Managed Installer limitations. The application may have updated itself, the installer may have generated and immediately launched a new file, or the vendor may have changed the signer. Compare the old and new artifacts before creating a rule.

The application installs but will not launch. Separate deployment from execution trust. Inspect the failing file’s origin claim. A child-of-a-child result often explains why the deployment succeeded while App Control blocked execution.

The application works for one technician but not another. Check base and supplemental assignments first. Policies with the same built-in settings can share a PolicyID, so assignment is part of the trust design.

The application runs from Program Files but not from Downloads or USB. That may be the control working correctly. A file trusted because it arrived through Managed Installer should not automatically keep that trust when someone copies a different instance into a user-writable location.

Rehearse Recovery Before You Need It

Most rollback plans I review are one sentence: “We will roll back if needed.” That is a hope with punctuation.

Deleting an App Control policy is not the first rollback step. Microsoft recommends making the policy effectively inactive before removal. The short Intune procedure is to replace the policy with a new version modeled on %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml, confirm that the replacement has deployed, and then delete it.

Policies deleted through Intune remain in effect until the device restarts. Build that restart into the recovery timeline.

Keep the Clipboard in Use

The flashlight showed you what was on the shelves. The clipboard recorded why it mattered. Enforcement is what happens when the lights stay on and people keep bringing more boxes into the room.

Configure Managed Installer deliberately and move it through deployment rings. Keep the base policy boring. Bind supplemental policies to the correct PolicyID, then review the assignments twice. Require evidence before writing a rule. Give every exception an owner, an approver, and a review date. Rehearse recovery on a device you can afford to rebuild.