The Managed Installer Backlog Problem (And How to Solve It)

Why existing applications create operational challenges and what to do about them

In Part 1, we covered how Managed Installers work and why they make AppControl for Business/WDAC deployment feasible. The core benefit is straightforward: instead of creating explicit allow rules for thousands of individual files, you trust your deployment process. Files written by managed installer processes receive NTFS Extended Attributes that WDAC recognizes as trusted.

This works well for applications installed after you enable the managed installer policy. However, it doesn't address applications already deployed in your environment. This is commonly referred to as "the backlog problem."

The Technical Limitation

Managed Installer functionality only applies to files installed after the managed installer policy is active. This happens because Extended Attributes are written at the time a managed installer process writes a file to disk. Windows doesn't maintain historical records of which process installed which files, so there's no mechanism to retroactively add Extended Attributes to existing files.

The result: applications installed before enabling Managed Installer will generate WDAC audit or block events, even if they were deployed through the same tools (ConfigMgr, Intune, etc.) that you've now designated as managed installers.

The Operational Challenge

The technical limitation is well documented. The operational challenge is less discussed but more problematic: how do you efficiently identify and trust the applications that are already deployed?

When ACfB/WDAC runs in audit mode, it generates Event ID 3076 for each file that would be blocked. These events are logged locally on each workstation in the Microsoft-Windows-CodeIntegrity/Operational event log.

File-Level Events vs. Application-Level Decisions

WDAC events are file-centric. Each event contains:

• File path and name

• SHA256 hash

• Process that attempted to load the file

• Timestamp

  
  

What the events don't tell you:

• Which application this file belongs to

• How many other files are part of the same application

• Whether all files from this application are generating events

  
  

For example, Mozilla Firefox consists of approximately 154 files, Adobe Acrobat DC has over 2,300 files. Your environment might have 200+ applications already deployed.

The operational question becomes: how do you group these file-level events into application-level trust decisions?

Traditional Centralization Approaches

Most organizations attempt to solve this through event log centralization:

Windows Event Forwarding (WEF): Forwards events from endpoints to a central collector. This consolidates the data but doesn't solve the analysis problem. You now have all events in one location, but you're still looking at individual file entries.

SIEM Solutions (Splunk, Sentinel, etc.): Can ingest WDAC events and provide query capabilities. You can filter and group events, but the SIEM doesn't inherently understand that 154 file paths represent a single application. Analysis still requires manual correlation.

Microsoft Defender for Endpoint (MDE): Collects application control events as part of its telemetry. However, MDE's application control views still present file-level data rather than application-level summaries.

The common limitation: these tools centralize file-level events but don't translate them into application-level intelligence. You still need to manually identify which files belong to which applications and then determine how to trust them. In addition, all file-level events are recorded, so you're looking at ten-thousands of records generated each day.

Three Approaches to Address the Backlog

There are three technical approaches to handling applications installed before Managed Installer was enabled:

Approach 1: Reinstallation

Uninstall and reinstall applications after enabling the managed installer policy. This ensures files get Extended Attributes during installation.

When this works: Small number of applications (fewer than 10), controlled test environments.

Why it doesn't scale: Hundreds of applications can't be reinstalled without significant operational disruption. Some applications have problematic uninstallers that leave remnants, causing reinstallation failures.

Approach 2: Explicit WDAC Policies

Create allow rules in WDAC policies for existing applications. This can use publisher signatures, file hashes, or other rule types.

Example:

powershell

New-CIPolicy -ScanPath "C:\Program Files\Application" -Level Publisher -Fallback Hash -FilePath app.xml

When to use: Small number of applications that can't be cataloged, applications you want granular control over, or applications with valid code signing certificates.

Limitations: You're back to creating rules for individual files or publishers. This is the traditional WDAC approach that Managed Installer was meant to avoid. Policies require updates when applications change and are only identified by a GUID. You have to keep track of what GUID belongs to what policy.

Approach 3: Security Catalogs

Generate catalog files (.cat) that contain hashes of all files for an application. The catalog is signed with your code signing certificate and deployed to endpoints. WDAC trusts files if their hashes exist in a deployed catalog.

Structure: A catalog is essentially a signed list of file hashes. One catalog can contain all files for an application.

Benefits:

• Single catalog file trusts an entire application

• Can be deployed independently from WDAC policies

• Works for unsigned applications

• Catalog deployment can be managed through existing tools (ConfigMgr, Intune)

This is our recommended approach for handling the backlog. Check this older blogpost to see why we strongly prefer security catalogs over policies.

Creating Security Catalogs

Microsoft provides PackageInspector.exe (available by default on every windows device) for creating catalogs.

Manual Process

powershell

# Start monitoring a drive
PackageInspector.exe start C:

# Install or copy the application files to the monitored drive
# Generate catalog
PackageInspector.exe stop C: -out cat -name Application.cat

# Sign the catalog
Set-AuthenticodeSignature -Certificate $Cert -FilePath .\application.cat 
	-TimestampServer http://timestamp.digicert.com -HashAlgorithm sha256 
	-FilePath "file"
# Deploy to endpoints: copy .cat file to
# C:\Windows\System32\CodeIntegrity\CIPolicies\Active\

The Scale Problem

For an environment with 200 applications, you need to:

1. Run PackageInspector for each application

2. Generate each catalog

3. Sign each catalog

4. Deploy each catalog

5. Verify each catalog works

   
   

While the process itself is easy enough to do, it takes 60-90 minutes per application, including testing (once you get the hang of it). That's 200-300 hours of work for 200 applications. Most organizations don't have this time available.

The Automated Approach: AppControl.AI

The core problem is translating file-level audit events into application-level trust decisions at scale. AppControl.AI addresses this through a two-part strategy: pre-trust your managed applications and intelligent event aggregation.

How It Works

Part 1 : Pre-Trust Strategy (Server Agent)

The recommended approach is to address the backlog BEFORE you enable WDAC in audit mode. This is where the server agent comes in.

The server agent connects to your ConfigMgr or Intune environment and inventories all deployed applications. For each application, the agent:

• Identifies all files that are part of the application

• Generates and validates security catalogs automatically

• Makes catalogs (or policies if you prefer) available for download

You deploy these catalogs before enabling WDAC. This pre-trusts all your managed applications, dramatically reducing the events you'll see in audit mode.

What you avoid: Enabling audit mode and seeing 50,000 events from applications you already know and trust.

What you get: Audit events only for applications NOT in your ConfigMgr/Intune inventory—the actual unknowns you need to investigate.

Part 2: Intelligent Event Aggregation (log Collector)

Despite pre-trusting managed applications, you'll probably still have events from:

• Applications not deployed through ConfigMgr/Intune

• User-installed software

• Applications installed before they were added to your deployment tools

• Applications that are auto-updating

The log collector deploys to endpoints and:

• Collects WDAC events locally

• Correlates file-level events to applications (100 Chrome files = "Google Chrome")

• Sends deduplicated application-level data to the portal

• Tracks which catalogs are deployed where

• Checks proper configuration of your managed installer process

Portal: Application-Level Visibility

The portal shows:

• Applications generating audit/block events (deduplicated, one line per app)

• How many files per application

• Which devices are affected

• Version distribution across your environment

• Workflow for tracking decisions (Trust/Review/Block)

What's available today: View and understand which applications are generating events at application-level rather than file-level.

What's coming very soon: Direct generation of catalogs (or policies) for these discovered applications from the portal, closing the loop entirely!

The Operational Difference

Traditional approach:

• Export 50,000 event log entries to CSV

• Sort/filter by file path

• Identify that files in "C:\Program Files\Google\Chrome\Application..." might be Chrome

  • But which version? The path doesn't tell you

  • Some devices might have Chrome 120, others 119, others 121

  • How do you know which devices have which versions?

  • Do you create separate catalogs for each version? How do you even identify what versions exist?

• Repeat this analysis for 199 more applications

AppControl.AI approach:

• Before audit mode: Deploy server agent, generate catalogs for all managed applications, deploy catalogs

• Enable audit mode: Events are dramatically reduced (managed apps already trusted)

• Remaining events: Portal shows application-level view

  • "Google Chrome - 3 versions detected"

    • Version 120.0.6099.130 on 23 devices

    • Version 119.0.6045.199 on 15 devices

    • Version 121.0.6167.85 on 12 devices

• For managed apps: Catalogs already generated via server agent

• For discovered apps: Create catalogs manually (automated catalog generation from discovered apps coming very soon)

The pre-trust strategy eliminates the majority of the backlog problem before you even start. The remaining events are shown at application-level, making decisions manageable.

Deployment Strategies

Strategy 1: Greenfield

Enable WDAC only on newly provisioned devices. Don't address the backlog on existing devices.

Use cases:

• Active device refresh cycle

• Windows Autopilot deployments

• New sites or offices

Advantages: No backlog to handle, Managed Installer works from day one.

Disadvantages: Existing devices remain unprotected. Inconsistent security posture. May take years to cover the entire environment.

Strategy 2: Backlog First

Address existing applications with catalogs before expanding WDAC to more devices.

Process:

1. Deploy WDAC in audit mode to pilot group

2. Collect events for 3-4 months

   1. remember, not all applications are used constantly, some may only be used quarterly or even less

3. Generate catalogs for identified applications

4. Deploy catalogs

5. Validate applications work

6. Enable managed installer

7. Move to enforcement

8. Expand to more devices

Advantages: Complete coverage, consistent security posture.

Disadvantages: Requires upfront work to address backlog.

Strategy 3: Hybrid (Recommended)

Combine both approaches:

• New devices: Enable WDAC from day one with Managed Installer (greenfield)

• Existing devices: Generate catalogs for backlog, then enable WDAC (backlog approach)

This provides the fastest path to full coverage.

Monitoring Backlog Solutions

How do you know if your catalogs (or policies) are deployed and working?

Without monitoring: Wait for users to report blocked applications. Not ideal.

With AppControl.AI:

• Dashboard shows catalog/policy deployment status per device

• Track which applications are still generating events (catalog issues)

• Monitor enforcement state (Audit/Enforced) per device

• Heartbeat mechanism confirms devices are reporting

This visibility is necessary to confidently move from audit to enforcement mode.

Common Mistakes

Mistake 1: Assuming Managed Installer handles everything Many teams enable Managed Installer and expect all applications to work immediately, not realizing applications installed before MI are not covered.

Mistake 2: Trying to manually analyze tens of thousands of events

Manual event analysis doesn't scale. You need either significant automation or a tool that provides application-level views.

Mistake 3: Not testing catalogs before production deployment

Deploy catalogs to a pilot group first. Catalog generation issues (incomplete file sets, signing problems) need to be caught early.

Mistake 4: No visibility into catalog deployment status

You can't move to enforcement if you don't know which catalogs are deployed where. Monitoring is not optional.

What's Next

Part 3 will cover real-world implementation scenarios:

• ConfigMgr-only environments

• Intune-only environments

• Hybrid and co-managed scenarios

• Defining your own managed installers

---

Ready for real-world implementation guidance? Part 3 covers deployment scenarios across different management tools and environment types.

Want to automate your backlog solution? Learn more at https://appcontrol.ai or contact info@appcontrol.ai