Microsoft Intune: Win32 vs. Store App Deployment — Complete Guide

Every Intune deployment decision eventually comes down to the same question: Win32 or Store? Get it right and apps deploy silently, update automatically, and never appear in your remediation backlog. Get it wrong and you are spending Friday afternoon hunting a failed IME extension, chasing a detection rule that never fires, or explaining why a business-critical app didn't install during Autopilot. This guide covers both methods completely — what they are, when to use each, and how to operate them at scale.

The Core Distinction — Control vs Convenience

Before diving into specifics, understand the fundamental trade-off. Win32 app deployment routes everything through the Intune Management Extension (IME) — an agent that runs on the device and executes your installer with whatever switches, scripts, and detection rules you define. You have complete control. You also carry complete responsibility.

Store app deployment bypasses the local agent entirely. Intune sends a policy to Windows, Windows talks directly to the Microsoft Store (or Windows Package Manager), and the app installs and updates through that cloud channel. You give up fine-grained control. In return, you get automatic updates, no packaging overhead, and no IME dependency chain to debug.

Win32 App Deployment — The Control Engine

Supported types: .msi, .exe, PowerShell-wrapped installers, complex multi-file packages, and anything that runs as a standard Windows executable. If it has a setup.exe, you can deploy it as Win32.

Packaging requirement: Every Win32 app must be converted to the .intunewin format using the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) before upload. This tool compresses and encrypts the source folder into a single package file that Intune can distribute securely.

# Download Win32 Content Prep Tool from GitHub releases
# https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool

$sourcePath  = "C:\AppPackages\7zip"         # Folder containing setup files
$setupFile   = "7z2301-x64.msi"            # Primary installer filename
$outputPath  = "C:\IntunePackages"         # Where .intunewin will be saved
$prepTool    = "C:\Tools\IntuneWinAppUtil.exe"

& $prepTool -c $sourcePath -s $setupFile -o $outputPath -q

Write-Host "Package created: $outputPath\$($setupFile -replace '\.\w+$','.intunewin')"

Deployment mechanism: The IME agent (Microsoft.Management.Services.IntuneWindowsAgent.exe) polls Intune every 8 hours by default. When a Win32 app assignment is detected, IME downloads the .intunewin package from Azure CDN, decrypts it, and executes the installer silently in the SYSTEM context.

Detection rules: Intune will not mark a Win32 app as installed until the detection rule passes. You can use file/folder detection, registry key detection, MSI product code detection, or a custom PowerShell detection script. Missing or incorrect detection rules are the most common cause of Win32 apps showing as "Failed" even though the software installed successfully.

# Custom detection script — exits 0 (detected) or 1 (not found)
$appPath = "C:\Program Files\7-Zip\7z.exe"
$minVersion = [version]"23.01.0.0"

if (Test-Path $appPath) {
    $fileVer = [version](Get-Item $appPath).VersionInfo.FileVersion
    if ($fileVer -ge $minVersion) {
        Write-Output "Detected: $fileVer"
        exit 0
    }
}
exit 1

Store App Deployment — The Cloud-Native Route

Supported types: MSIX, Appx, and UWP applications published in the Microsoft Store. These are modern, sandboxed Windows application packages that install, update, and uninstall cleanly without registry sprawl.

Packaging requirement: None. You add a Store app in the Intune portal using either a Direct Store Link (the app's Store URL) or an App URI (e.g., ms-windows-store://pdp/?ProductId=9NBLGGH4NNS1). No file preparation, no upload, no CDN.

Deployment mechanism: Intune sends a WinGet/Windows Package Manager policy to the device. Windows manages the download directly from the Microsoft Store cloud CDN and installs it natively. The Microsoft Store background sync service handles subsequent version updates automatically — no IME involvement, no detection rule required.

Head-to-Head Comparison

Win32 Deployment Lifecycle — Step by Step

1. Package: Run IntuneWinAppUtil.exe against your source folder to produce the .intunewin file.
2. Upload: Add the Win32 app in the Intune portal (Apps → Windows → Add → Windows app (Win32)). Configure install command, uninstall command, and detection rule.
3. Assign: Target a user or device group with Required, Available, or Uninstall intent.
4. IME check-in: On the target device, IME polls for new assignments. Trigger manually: restart the IntuneManagementExtension service.
5. Download and decrypt: IME downloads the .intunewin from the Azure CDN URL and decrypts it using the embedded key.
6. Execute: IME runs the install command in the SYSTEM context, capturing stdout/stderr.
7. Detect: IME runs the detection rule. If it passes, the app is marked Installed. If it fails, the app is marked Failed regardless of exit code.
8. Maintain: For updates, upload a new .intunewin version and supersede the old assignment.

Store App Deployment Lifecycle

1. Direct Store link: Find the app in the Microsoft Store, copy its URI or product ID.
2. Add in Intune: Apps → Windows → Add → Microsoft Store app (new). Search or paste the Store link.
3. Assign: Target user or device groups. Set install context (user or device).
4. MDM sync: At next MDM check-in, Windows receives the Store app policy.
5. Direct cloud install: Windows contacts the Microsoft Store CDN directly and streams the package. No IME involved.
6. Automatic updates: The Store background sync service checks for new app versions and applies them silently.

Deployment Choice Tree — Which Method to Use

Autopilot & App Ingestion Order

When a new device goes through Autopilot provisioning, applications are not installed simultaneously. Intune follows a strict precedence order determined by app type and assignment. Understanding this prevents the most common Autopilot failure: a user reaching the desktop before critical apps finish installing.

Checking Deployment Status via PowerShell

# Get Win32 app deployment status for all devices via Graph API
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"

$win32Apps = Get-MgDeviceAppManagementMobileApp -Filter "isOf('microsoft.graph.win32LobApp')"

foreach ($app in $win32Apps) {
    Write-Host "`n=== $($app.DisplayName) ===" -ForegroundColor Cyan
    $states = Get-MgDeviceAppManagementMobileAppDeviceStatuses -MobileAppId $app.Id
    $states | Select-Object DeviceName, InstallState, LastSyncDateTime |
        Sort-Object InstallState | Format-Table -AutoSize
}

# Force IME to re-evaluate app assignments on local device (requires local admin)

# Method 1: Restart the IME service
Restart-Service -Name "IntuneManagementExtension" -Force

# Method 2: Trigger the IME scheduled task
Get-ScheduledTask | Where-Object { $_.TaskName -like "*Intune*" } |
    Start-ScheduledTask

# Method 3: Check IME logs for recent activity
$logPath = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log"
Get-Content $logPath -Tail 50 | Select-String "Win32App|Install|Error|Failed"

IME Log — Reading Win32 App Failures

When a Win32 app reports Failed, the IME log at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log is your primary diagnostic source.

Community Perspective

From Detection to Fleet-Wide Triage — Three More Scripts for This Guide

Everything above tells you how Win32 and Store deployment work. These three scripts, added after publishing based on reader feedback, answer a different question: across your whole app catalog, which apps are actually failing, and why? The Intune portal can only show you this one app at a time — click into every app individually and note the numbers by hand. These scripts do it for the whole fleet in one run.

Script 5 — Rank every app by failure rate, with day-over-day trend

05-Win32AppFleetHealthSummary.ps1 pulls install-state counts for every Win32 app, ranks them worst-to-best by failure rate, and — because it saves a timestamped CSV snapshot every run — automatically diffs against your last run to show which apps got worse or better. None of that exists in the Intune portal; it only ever shows you the current moment for one app.

=== Ranked by Failure Rate (worst first) ===

DisplayName                            TotalDevices OutcomeTotal Installed Failed FailRatePct
-----------                            ------------ ------------ --------- ------ -----------
Adobe Acrobat DC (64-bit) 24.002.20857        16849        16849     16276    330  2
Adobe Acrobat DC (64-bit) 25.001.21223        13581        13581     13374    207  1.5
1E Client Uninstaller 1.0                      3482         3482      3473      9  0.3

No apps at or above the 5% failure threshold (with at least 10 devices).

Script 6 — Decode WHY installs are failing, with a real fix per error code

06-Win32AppFailureAnalysisReport.ps1 pulls per-device install records for one app (or your whole catalog), decodes every failure's error code through three layers — the documented Windows Installer (MSI) codes, Microsoft's official Intune app-install error reference, and .NET's own Windows system-error table — and outputs a self-contained HTML report with a donut chart and a ranked "top failure reasons" table. Each reason comes with an actual fix, not just a diagnosis.

Script 7 — Chain them together: rank first, then auto-drill into the ones that matter

07-Win32AppFleetTriage.ps1 runs the cheap fleet-wide ranking pass first, then automatically pulls the full failure breakdown for every app in the ranking — not just the ones that cross your threshold — and combines it into one HTML page. Click any app name in the ranking table and it jumps straight to that app's donut chart, decoded failure reasons, and a full per-device table (device, user, state, error code, platform, and how many days since that record last changed) with names masked by default.

Every non-Installed state also gets a plain-English explanation baked into the report — NotInstalled, PendingInstall, NotApplicable and Unknown aren't errors, so there's no error code to decode, but an engineer still needs to know what each one means and what (if anything) to check.

Official Resources

• Win32 app management in Microsoft Intune
• Prepare Win32 app content for upload
• Add Microsoft Store apps to Microsoft Intune
• Add apps to Microsoft Intune
• Set up the Enrollment Status Page
• Troubleshoot Win32 app installations with Intune
• Microsoft Win32 Content Prep Tool (GitHub)