Packaging Chrome, 7-Zip or a JDK as a Win32 app is not hard, but doing it again for every new version is where the hours go. Enterprise App Management gives you a Microsoft-hosted catalog of prepackaged Win32 apps with install commands, detection rules and return codes already filled in, plus two ways to keep them current. In this post I'll walk through adding a catalog app, the settings worth checking before you assign it, the update options, and how to verify and troubleshoot on the device.
How it works#
The Enterprise App Catalog is a feature of Enterprise App Management (EAM), one of the Intune advanced capabilities. Microsoft prepares and hosts the apps; your devices download the content from *.manage.microsoft.com, and the Intune Management Extension (IME) installs it exactly like any other Win32 app. EAM does not use winget. The catalog contains both Microsoft and non-Microsoft apps as .exe and .msi installers, and Microsoft publishes service level objectives for update availability: most updates pass automated validation and appear within 24 hours, while updates that need manual testing typically take up to seven days.
Prerequisites#
- Licensing: EAM requires a subscription in addition to Intune Plan 1 or Plan 2. It's sold as part of the Microsoft Intune Suite or as a standalone SKU, and Microsoft Learn now also lists advanced capabilities as available through select Microsoft 365 bundles. Check Tenant administration › Intune add-ons: if the capability isn't active, the Enterprise App Catalog app type simply doesn't appear when you create an app.
- Devices: managed Windows devices running a 64-bit version of Windows. Co-managed clients can receive catalog apps when targeted from Intune; Configuration Manager itself doesn't support them.
- Network: the standard Intune endpoints, plus whatever the vendor's own updater needs if you rely on self-updating apps.
Step-by-step#
Step 1: Pick the app and package#
Go to Apps › All apps › Create, choose the Windows platform and the Enterprise App Catalog app type, then Search the Enterprise App Catalog. After you select the app, you choose a specific package by name, language, architecture and version. The App information step is then prefilled; adjust the name, description, category and logo as you would for any app, because that's what users see in the Company Portal.
Step 2: Review the Program settings#
The install and uninstall commands are prepopulated with Microsoft-recommended values. Leave the Installer type on Command line unless you have a real reason to switch to a PowerShell script installer (maximum 50 KB, and if Multi-Admin Approval is enabled you can only add scripts after the app is created). The other fields to check:
| Setting | What to know |
|---|---|
| Installation time required | Default 60 minutes, maximum 1440. Exceeding it reports a failure but doesn't stop the installer. |
| Allow available uninstall | Lets users remove the app from the Company Portal. |
| Install behavior | System or user context is chosen by EAM from the installer and can't be changed. |
| Device restart behavior | Determine behavior based on return codes, No specific action, App install may force a device restart, or Intune will force a mandatory device restart. |
| Return codes | Prefilled; a Retry code makes the agent try three times, five minutes apart. |
Watch out: changing the install command or swapping in a custom script can break both installation and future updates. Intune still enforces the prefilled detection rules, so if your script installs something different the app shows as failed.
Step 3: Requirements and detection#
Architecture and minimum OS are prefilled, and you can add disk, memory, registry, file or script requirement rules. Detection rules are also prefilled (file, registry or MSI based) and you can have up to 25; all of them must match for the app to count as installed. Self-updating apps in the catalog use a minimum version detection, so a device that already runs a newer version is still reported as installed.
Step 4: Assign, and decide how updates arrive#
Assignments are the usual Required, Available for enrolled devices and Uninstall, with end-user notifications, deadlines and a delivery optimization priority. For Required assignments you can enable auto-update, which tells Intune to install newer catalog versions on targeted devices without you creating a new app or a supersedence relationship. Catalog apps can also be selected as blocking apps in Enrollment Status Page and Autopilot device preparation profiles, but not when auto-update is enabled.
Keeping apps current: three models#
| Model | Who updates | Good for | Limits |
|---|---|---|---|
| Self-updating app | The vendor's own updater; Intune only checks a minimum version | Browsers and similar apps that patch themselves | Needs outbound access to the vendor; Intune reports the detected version only |
| Auto-update | Intune, when a new version reaches the catalog | The long tail of utilities and runtimes | Required assignments only; no rings or phased rollout; no rollback; catalog data is cached for up to an hour; reporting keeps only the latest state per device |
| Guided update supersedence | You, from the Enterprise App Catalog apps with updates report | Apps that need a pilot ring or change record | Creates a new app; scope tags, assignments and scripts aren't copied, so set them again |
The updates report is reachable from the tile on the Apps overview page and lists app name, publisher, provisioned version and latest available version. Selecting an app and choosing Update › Supersede app walks you through a new app with the supersedence relationship already in place.
Note: don't manage the same application through two deployment types at once. Microsoft documents a race condition where, for example, a line-of-business app installing version 2 fights with an auto-update catalog app for the same product.
How it compares#
- Your own Win32 package: full control and any installer you like, but you own packaging, detection and every update. Use it for apps that aren't in the catalog or that need custom configuration baked in.
- Microsoft Store app (new): simplest for packaged Store apps and winget-sourced apps, with Store-driven updates, but less control over commands, detection and restart behaviour.
- Enterprise App Catalog app: Win32 flexibility without the packaging, Microsoft-validated settings, and an update path that scales. The trade-off is licensing and the fact that you can only deploy what's in the catalog; you can request additions through the Microsoft Feedback Portal, with no guaranteed timeline.
Verify#
- In Apps › All apps, add the Version column to see which catalog version each app object carries, and open the app's Device install status for per-device results.
- On a specific device, the Managed Apps report shows installed, not installed and available apps with version, resolved intent and status.
- On the device, the IME logs under
C:\ProgramData\Microsoft\IntuneManagementExtension\Logsrecord the download, the install command and the detection result, just as they do for a hand-built Win32 app. - After an auto-update, confirm the detected version changed on a pilot device before trusting the tenant-wide numbers; Intune doesn't keep a per-device version history.
Tips & gotchas#
- Content still being prepared: if an app shows that its content isn't ready after several hours, Microsoft's guidance is to delete the app and add it again.
- User-targeted installs that need admin rights fail when the installer runs in a standard user's context. Target devices, or confirm EAM picked the system context.
- Removed apps: when a vendor asks Microsoft to pull an app from the catalog, existing deployments keep working but you can't create new ones; plan a Win32 fallback.
- Revoked versions: if Microsoft removes a malicious version, you get a notification in the admin center, but identifying affected devices and remediating them is still your job.
- Licensed software is in the catalog too, and Intune doesn't check licences; buying and distributing them remains your responsibility.
- Standard Win32 troubleshooting applies: requirement rules not met, detection rules failing, or a return code mapped to Failed are the usual reasons for an install that "worked" but reports as failed.