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

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)