Microsoft Store Apps in Intune — Deployment & Troubleshooting, End to End

Deploying a Microsoft Store app through Intune should be the easy part of your day. You search the catalogue, click assign, and walk away. Then a device reports "failed" — even though the app is clearly installed — and you're back in the logs trying to work out what the Intune Management Extension actually did. This is the full picture: how Store app deployment works today, what lands on the device (registry, logs, services), how to read it, and the error codes that trip everyone up. Every device detail below was pulled read-only from a real Intune-managed Windows 11 machine.

What "Microsoft Store app (new)" actually is

"Microsoft Store app (new)" is an Intune app type backed by winget (the Windows Package Manager, winget.exe). Instead of packaging an .intunewin file, you search the Store catalogue inside Intune, pick the app, and assign it like anything else. Three things make it nicer than the old experience:

• One catalogue, three formats. It covers UWP apps, MSIX-packaged desktop apps, and now Win32 apps (.exe/.msi) published to the Store.
• Auto-populated metadata. When you search and select the app, Intune fills in the name, publisher, description and package identifier for you.
• Auto-updates. Intune keeps the app current as new versions land in the Store — no repackaging.

On the device, the work is done by the Intune Management Extension (IME) — the same agent that runs your Win32 apps, PowerShell scripts and remediations. The IME calls winget to do the install. That single fact explains everything you'll see on the device.

The package identifier — Package ID vs PFN

Two identifiers get confused constantly, so let's be precise:

You rarely type the Package ID — Intune handles it. The PFN is the one you'll reach for when troubleshooting. Find it with PowerShell:

Get-AppxPackage -Name Microsoft.CompanyPortal | Select Name,PackageFamilyName

Name              PackageFamilyName
----              -----------------
Microsoft.CompanyPortal   Microsoft.CompanyPortal_8wekyb3d8bbwe

# a few more, for reference
Microsoft.Paint           Microsoft.Paint_8wekyb3d8bbwe
Microsoft.WindowsNotepad  Microsoft.WindowsNotepad_8wekyb3d8bbwe

The deployment flow — portal to device

In the portal it's four clicks:

1. Apps › All apps › Create, choose Microsoft Store app (new).
2. Search the catalogue and select the app (metadata auto-populates).
3. Assign to user or device groups (Required or Available).
4. Intune syncs; the device installs and reports back.

On the device, the sequence is: the IME receives the app policy → downloads the encrypted content to its staging area → calls winget to install (as SYSTEM by default for device-targeted apps) → runs the detection check → reports the result to Intune. Hold onto that "SYSTEM by default" — it's behind a surprising number of failures.

What changes on the device — the real evidence

1. The IME tracks every app in the registry

The IME records its view of each deployment under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps. There's a sub-key per context — the device (00000000-0000-0000-0000-000000000000) and one per user (named by the user's Entra object ID) — and under each, one sub-key per app ID, plus a GRS (retry schedule) key. On the test machine:

00000000-0000-0000-0000-000000000000\   # device context — 19 apps
  <app-id>\
  <app-id>\
  GRS\                                   # Global Retry Schedule
<user-object-id>\                        # user context — 107 apps
  <app-id>\
  GRS\

Each app's last reported state shows up in the IME logs as a ReportingState JSON. This is the single most useful blob on the device — here's a real one (app ID redacted), lightly trimmed:

{
  "ApplicationId": "<app-id>",
  "DesiredState": 2,            # what Intune wants (e.g. installed)
  "DetectionState": 1,          # did detection find it
  "DetectionErrorCode": null,
  "ApplicabilityState": 0,      # did the app apply to this device
  "EnforcementState": 1000,     # install outcome
  "EnforcementErrorCode": 0,     # 0 = no error
  "InstallContext": 1,          # 1 = user, 2 = system
  "Intent": 3                   # required / available / uninstall
}

You don't need to memorise the enum numbers. The field names tell the story: did it apply, did it install (and with what error code), did detection find it, and in which context. When the portal and the device disagree, this is where the IME's "opinion" lives.

2. Where the bits actually land

The logs — and what to look for

All the IME logs live in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. The workflow that never fails you: grab the app's GUID from the Intune portal URL, open AppWorkload.log in CMTrace, search that GUID, and read the lifecycle in order — download → applicability → install command → exit code → detection.

The error codes everyone hits

PowerShell that earns its place

Confirm what's actually installed (the real device state, vs what the IME believes):

# Is the package actually present? (per-user and provisioned)
Get-AppxPackage -Name "Microsoft.PowerToys" | Select Name,PackageFamilyName,Version
Get-AppxProvisionedPackage -Online | Where DisplayName -like "*PowerToys*"

# Reproduce the install the way Intune does (winget)
winget search "PowerToys"
winget install --id Microsoft.PowerToys --source msstore --accept-package-agreements

And the fix everyone eventually needs — force the IME to retry a stuck app. This changes the device, so it's not in the read-only script below; do it deliberately:

See your own device in one readout

Rather than open three log files and a registry hive by hand, I wrapped the read-only checks into one script — Get-IntuneStoreAppStatus.ps1. It shows the winget engine, the IME service, every app the IME is tracking (with failures flagged), recent install errors, and your installed Store packages with their PFNs. It changes nothing.

[ Engine and agent ]
  winget (App Installer) : 1.28.240.0
  IME service            : Running
  Incoming / IMECache    : present

[ Apps tracked by IME (Win32Apps registry) ]
  Device context: 19 app(s) tracked, 0 with issues
  User a1b2c3d4…: 107 app(s) tracked, 0 with issues

[ Recent AppWorkload.log errors ]
  No recent install errors found. (clean)

[ Installed Store packages — use the PFN for detection ]
  Microsoft.CompanyPortal   Microsoft.CompanyPortal_8wekyb3d8bbwe
  Microsoft.Paint           Microsoft.Paint_8wekyb3d8bbwe

Best practices & a quick checklist

• Pilot first. Assign to a small ring before the fleet.
• Trust the PFN for detection. Wrong detection logic causes most "failed-but-installed" noise.
• Test in SYSTEM context (psexec -s -i) before assuming a package is broken.
• Keep winget healthy. The App Installer package must be present and current for Store apps to deploy.
• Watch the right report. Intune › Apps › the app › Device/User install status.

Store app deployment in Intune is winget wearing a portal. Once you know the IME does the work, that the device's opinion lives in the Win32Apps registry and AppWorkload.log, and that the PFN is your detection source of truth, most "mystery" failures stop being mysteries.

References & further reading

Microsoft Learn / official

• Add Microsoft Store apps to Microsoft Intune
• Troubleshoot Win32 app issues
• App installation error codes for Microsoft Intune
• Use WinGet to install and manage applications

Community & credit

• Inspired by a community infographic on Store app deployment & troubleshooting by Shankar Kumar Sony.
• Companion script: github.com/Imran76Awan/Intune-Store-Apps