Intune deployed and still blocked, and why managed installer is usually the reason

You deployed an application through Intune, App Control blocked it on the endpoint, and nothing about that seems reasonable. This is the most common support question in application control and it almost always has the same cause. Your policy does not contain the managed installer configuration, so App Control has no idea the files came from a tool you trust.

Here is how to confirm that, and what to do about it.

The short version #

App Control does not know what Intune is. It evaluates code against a policy. If the policy says nothing about your deployment tool, then a file Intune wrote to disk is indistinguishable from a file a user downloaded from the internet. Both are untrusted, both get blocked.

Managed installer is the mechanism that closes this gap. It tells Windows to treat files written by a nominated installer as trusted, using an extended attribute applied at the moment the file is written. Configure it and your existing software deployment approval process becomes the trust decision.

Miss it and you get the outcome that feels absurd. The applications you deployed yourself are the ones that stop working.

Confirming it is actually this #

Before changing anything, look at the event.

Open Event Viewer on an affected device and go to:

Applications and Services Logs
  Microsoft
    Windows
      CodeIntegrity
        Operational

You want event 3077 if the policy is enforcing, or 3076 if it is still in audit mode. The event names the file that was refused and the policy that refused it.

You can also pull them with PowerShell, which is easier when you are checking several machines.

# Blocked and audited code integrity events from the last day
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077
    StartTime = (Get-Date).AddDays(-1)
} |
Select-Object TimeCreated, Id, Message |
Format-List

Two things to check in the message.

The file path. If it is somewhere your deployment tool writes, such as the Intune Management Extension working directory or a per machine install location, that supports the managed installer theory.

Whether the file is signed. If it is unsigned, managed installer is very likely the only practical way you were ever going to trust it, short of signing it yourself.

The event that actually answers the managed installer question #

Worth being precise here, because the Operational log will not tell you what you want to know. Events 3076 and 3077 tell you a file was audited or blocked and which policy did it. They do not tell you whether the origin check passed, which is the whole question when you deployed the file yourself.

That determination is recorded in the CodeIntegrity Verbose channel, in the correlated events Microsoft documents alongside 3076 and 3077, carrying the managed installer and Intelligent Security Graph fields for the file. Verbose is disabled by default, so it captures nothing until you turn it on:

# Enable the CodeIntegrity Verbose channel, then reproduce the block
$log = 'Microsoft-Windows-CodeIntegrity/Verbose'
wevtutil set-log $log /enabled:true

Reproduce the block, then read that channel rather than the Operational one. This is the step that separates knowing managed installer did not apply from assuming it. Understanding App Control event IDs is the reference for which correlated event carries which field, and it is worth reading rather than memorising, because the numbering has changed across Windows releases.

Turn Verbose back off when you are finished. It is chatty.

Confirming the policy #

Then confirm what the policy actually contains.

# List the App Control policies currently on the device
CiTool --list-policies

If your policy is a custom XML you authored or generated, open it and look for the managed installer option. In the policy XML this is the Enabled:Managed Installer rule option. If it is absent, that is your answer.

Fixing it #

There are three parts and all three have to be true. Getting two of them right is the second most common version of this problem.

One, the AppLocker policy that defines the managed installer #

Managed installer identifies the trusted installer using an AppLocker rule collection, even though you are configuring App Control. This surprises people. AppLocker is doing the identification, App Control is doing the enforcement.

Microsoft ships a reference XML that nominates the Intune Management Extension and the Configuration Manager client. Start from that rather than writing it yourself, because getting the executable identities right by hand is fiddly and easy to get subtly wrong.

Two, the managed installer option in the App Control policy #

The policy has to have the managed installer rule option enabled. Without it, the tagging happens and nothing acts on it.

Three, the files have to have been written after all of this was in place #

This is the part that catches people who have done the first two correctly. Managed installer tagging is applied when the file is written to disk. It is not retrospective.

Anything already installed on the device before managed installer was configured was never tagged. Those files are not covered, no matter how correct your configuration now is.

The practical consequences:

• Test on a device that received the application after managed installer was live, not on your own machine where the app has been installed for months.
• For existing estate, either redeploy the affected applications so they are written again, or cover them with explicit rules.
• New builds from a refreshed image behave differently from upgraded devices. Test both.

What managed installer requires #

Four things have to be true at once. Three of the four are configuration and the fourth is timing, which is why a correct configuration can still produce a block.

An AppLocker policy that names the installer. The identification happens in an AppLocker rule collection even though the enforcement is App Control. Microsoft ships a reference XML nominating the Intune Management Extension and the Configuration Manager client, and starting from it is safer than writing the executable identities by hand.

The managed installer rule option in the App Control policy. Without it the tagging still happens and nothing acts on it.

The Application Identity service running. AppLocker does the identifying, so AppIDSvc has to be running for anything to be tagged. This one is easy to miss because nothing about the symptom points at a service, and a device where it is stopped looks identical to a device with a missing policy option.

The file written after all three were in place. Tagging happens at write time and is not retrospective, so the order of operations is part of the configuration.

Why it fails even when it is configured #

The tag records that a designated installer wrote a file. Anything that puts a file on disk by some other route produces an untagged file, and every case below is a version of that.

The installer extracts a payload and something else runs it. A wrapper that unpacks an archive to a temporary directory, then hands off to a second executable, is two processes. If the extracted file is written by the wrapper it may carry the tag, and if it is written or launched by a process that is not the designated installer it will not. This is the most common surprise, because the installer completed successfully and the block happens later.

The installer downloads a second payload at runtime. A small bootstrapper that fetches the real package is not writing the files it appears to install. What lands on disk came from a network fetch by a child process.

The application updates itself. The updater is not the designated installer, so new files carry no origin information. Designating the updater is possible and widens what that binary is trusted to write, which is a decision worth making deliberately rather than reaching for.

Files are copied rather than installed. A copy from a share, a migration tool, or a user moving a folder produces files with no origin. Restoring a profile or a backup has the same effect.

Per user installs written by a user process. An installer that runs in the user context and writes into a user writable location was not run by your deployment tool, whatever the vendor calls it.

Anything already on disk. The whole existing estate predates the configuration and needs its own rules, which is exactly the population you are looking at during audit.

Kernel drivers, always. The heuristic does not authorise drivers under any circumstances.

The pattern is worth stating once. Managed installer trusts a path onto the disk, not an application, so it holds for as long as your deployment tool is the only thing writing files and it stops holding at the first hand off. That is why the documented guidance is to keep explicit rules for everything that cannot arrive that way, rather than to widen the set of trusted installers until the problem stops.

When managed installer is not the answer #

Sometimes the block is legitimate and managed installer is a workaround you should not reach for.

The application is genuinely unsigned and comes from outside your deployment tool. A tool someone downloaded and ran from their Downloads folder should be blocked. That is the control working.

A user installed it into their own profile. Per user installs into %LOCALAPPDATA% are a recurring problem in application control, because that path is user writable. Trusting it with a path rule is not a real control. The answer is usually to package the application properly and deploy it.

It is a script or a macro tool rather than an application. Script enforcement has its own considerations and managed installer coverage of scripts is not the same as coverage of executables.

Three limitations that need explicit rules #

Managed installer is a heuristic, and Microsoft says so directly: it "doesn't provide the same security guarantees as explicit allow or deny rules do". Three gaps are documented, and each one is closed by writing a rule rather than by extending trust further.

It only covers what arrives after you turn it on. A designated installer is watched while it runs and, in Microsoft's words, "as files are written, they're tagged as originating from a managed installer". Tracking starts the next time a matching process runs. So nothing already on disk carries the tag, and the whole existing estate needs rules of its own. This is the one that surprises people during the audit stage, because the existing estate is exactly what they are looking at. Microsoft states the requirement plainly: your policy "must include rules for all system/boot components, kernel drivers, and any other authorized applications that can't be deployed through a managed installer".

Self-updating applications lose the tag. If an application deployed by a managed installer later updates itself, the new files were not written by the installer, so they carry no origin information and may not run. Microsoft's guidance is to deploy all updates through the managed installer, or to authorise the application with rules in the policy. Designating the updater binary as a managed installer is possible and is a decision to make deliberately, since it widens what that binary is trusted to write.

The same applies to installers that extract, download or generate binaries and run them immediately. Files produced that way may not be picked up by the heuristic.

Kernel drivers are not covered at all. The managed installer heuristic does not authorise drivers. The policy must have rules that allow the drivers you need, regardless of how they were deployed. Since kernel mode code integrity validates drivers whether or not the policy opts into user mode enforcement, a missing driver rule is a boot problem rather than an application problem.

The pattern across all three: managed installer reduces how many rules you write, and it does not remove the need for rules. A policy that relies on it entirely has gaps in precisely the places that are hardest to troubleshoot.

The wider point #

Managed installer is what makes App Control practical, and it is also where the trust boundary quietly moves. Once your deployment tool is trusted, whatever it installs is trusted. Your software approval process is now a security control whether it was designed to be one or not.

Most organisations have never looked at the full list of what their deployment tool has installed over the years. It is worth doing before you rely on it, and it usually surfaces a few things nobody expected to still be there.

That is the part of application control that is not really about Windows at all. It is about who decides what software enters the organisation, and whether that decision is written down anywhere. We have written more about that shift on the platform page.

The reason this surprises people is that deployment and trust look like the same act and are not. PoliEze keeps them visibly separate: every acting installer in one approved list, and an application that reached a device without being trusted showing up as a decision to make rather than as a ticket somebody raises.

Sources #

• Authorize apps deployed with a managed installer, including the reference XML that nominates the Intune Management Extension
• Understanding App Control event IDs, for the correlated Verbose events and the managed installer field, which is the reference above
• App Control admin tips and known issues
• Authorize reputable apps with the Intelligent Security Graph
• App Control for Business policies in Intune