The Setup

You found it. The Group Policy blocking the Microsoft Store. You removed it, ran gpupdate /force, and tried again. New Outlook downloaded — progress. Then this:

"Install blocked by policy. Retry."

Same wall. Different door.

Why Removing One Block Isn't Enough

Enterprise environments don't have a single application control switch. They have layers — added over time, by different teams, for different reasons — and each one enforces independently. Removing the Store block only addresses one layer.

For New Outlook (Microsoft.OutlookForWindows), there are four places the install can be stopped:

Layer 1 — Microsoft Store Policy (the one you removed)
Controls whether users can access the Store at all. Removing this unblocks the download. It says nothing about whether the package can install.

Layer 2 — AppLocker
Packaged App Execution rules can block MSIX apps from installing or running, completely independent of the Store policy. Check: Event Viewer → Application and Services Logs → Microsoft → Windows → AppLocker → Packaged app-Execution. A block event for Microsoft.OutlookForWindows means AppLocker is the culprit. You'll need an allow rule for the package.

Layer 3 — WDAC (Windows Defender Application Control)
Kernel-level policy, separate from AppLocker entirely. Check: Event Viewer → Microsoft → Windows → CodeIntegrity → Operational. Block events here mean a WDAC policy is enforcing — this requires a policy update, not just a GPO change.

Layer 4 — App Package Deployment GPO
Even with AppLocker and WDAC clear, a secondary Store policy can still block MSIX installs. Check: Computer Configuration → Administrative Templates → Windows Components → App Package Deployment → Allow all trusted apps to install — this needs to be set to Enabled.

Bonus: Third-Party Endpoint Management
If you're running ManageEngine Endpoint Central, Tanium, or a similar tool, check the Application Control module. These maintain their own blacklists that won't appear in any Windows event log. In Endpoint Central: Configurations → Application Control → Blacklist.

Where This Breaks in Production

The reason this catches teams off guard is that these policies were never designed together. AppLocker came from a security hardening project two years ago. WDAC got added during a compliance push. The App Package Deployment GPO was set when someone blocked sideloading long before the current team arrived. The Store policy was the most visible one, so it got removed first.

Each layer was added by a different engineer, in a different quarter, for a different reason. None of them left a note.

When Microsoft began migrating users to New Outlook, environments that had been quietly blocking MSIX for years suddenly surfaced these layers all at once. Removing the Store policy was the right first move — it just wasn't the last one.

The Fast Diagnostic

Run this on one of the affected machines:

gpresult /h c:\gpresult.html

Open the HTML report and search for AppLocker, CodeIntegrity, and AppPackageDeployment. This shows every applied policy in one place and will surface whichever layer is actually enforcing.

Resolution Checklist

  • [ ] Store access policy removed ✓
  • [ ] AppLocker: no block event for Microsoft.OutlookForWindows
  • [ ] WDAC: no block event in CodeIntegrity log
  • [ ] App Package Deployment GPO: Allow all trusted apps to install = Enabled
  • [ ] Third-party endpoint tool: no blacklist entry for Outlook package

Work through the list top to bottom. The event logs will tell you which layer is firing — you won't need to guess.

Want more patterns like this?

Get the full 6-part guide — what Intune doesn't tell you, but you'll hit in production.

Running into this in production? 30 minutes — I will tell you directly if it is worth fixing.

Book a Fit Call →