Tag Archives: Application lifecycle

Auto-Updating Enterprise App Catalog Apps in Intune: What GA Actually Changes

Posted on by
Reply

Third-party app patching has been the quiet tax on every Intune estate I run. Chrome, 7-Zip, Notepad++, Zoom, the JDKs – none of them are hard to package, but multiplied across a catalog of apps and a monthly cadence, the packaging-and-supersedence treadmill eats real hours. Enterprise App Management (EAM) took the first bite out of that when it shipped the Microsoft-hosted Enterprise App Catalog. The auto-update option – now Generally Available – takes the rest.

I read the short write-up on Xplore the Cloud and it is a good primer on the toggle. This post goes a layer deeper: the licensing reality, how auto-update differs from guided supersedence, the caveats Microsoft tucks into the docs that will bite you in production, how to monitor it, and a rollout playbook I would actually follow with a customer.

On the visuals in this post. Rather than embed portal screenshots, I have linked each step to the exact Microsoft Learn page that shows the official UI – so the images you see are always current with the portal instead of going stale in a blog. If you are reproducing this internally, capture from your own tenant so the branding matches.

What EAM and the Enterprise App Catalog Actually Are

Enterprise App Management is an Intune capability that gives you a Microsoft-curated catalog of prepackaged Win32 apps (EXE and MSI) hosted by Microsoft. When you add one, Intune pre-fills everything you would normally reverse-engineer yourself:

  • Install and uninstall commands
  • Detection rules (file version, file size, registry)
  • Requirements (OS architecture, minimum OS)
  • Restart behaviour, return codes, install context (system vs user)

The catalog is large – well over a thousand titles today, from Adobe Acrobat and Google Chrome for Business to the whole Eclipse Temurin / Zulu JDK matrix, 7-Zip, Notepad++, Firefox, PowerToys and Wireshark. Content is served from *.manage.microsoft.com and installed by the Intune Management Extension (IME) – not winget, which is a common misconception.

See the current catalog and the add flow: Add a Windows catalog app (Win32) to Intune on Microsoft Learn lists every title and walks the wizard step by step.

The licensing reality (check this first)

EAM is not part of base Intune. It requires a subscription in addition to Intune Plan 1/Plan 2, and you get it one of three ways:

  1. As part of the Microsoft Intune Suite
  2. As the standalone Enterprise App Management add-on SKU
  3. Bundled into Microsoft 365 E5 – the change that makes this genuinely worth revisiting, because a lot of my customers already own E5 and were never using the feature

A quick way to confirm the entitlement is actually provisioned: go to Apps > Windows > Create and open the App type dropdown. If Enterprise App Catalog app is not in the list, the tenant does not have EAM enabled yet – licensing alone is not enough, the entitlement has to be present. (I checked a Plan-2-only tenant while writing this and the option simply is not there, which is the fastest tell.) See Microsoft Intune plans and pricing for the SKU details.

Two Update Models: Guided Supersedence vs Auto-Update

Before GA, keeping a catalog app current meant guided update supersedence: Intune surfaced available updates under Apps > Enterprise App Catalog apps with updates, you created a new app version, and you wired up a supersedence relationship to replace the old one. Controlled, reviewable – and manual. It is still fully supported and documented under Guided update supersedence for Enterprise App Management.

Auto-update collapses that loop. Enable it on a catalog app with a Required assignment and Intune detects new catalog versions and pushes them to targeted devices automatically. No new app, no supersedence relationship, no monthly click-through.

Here is the honest comparison:

Guided update supersedence Automatically update
Trigger You create the new version + supersedence Intune detects the catalog version
Review before deploy Yes No
Phased rollout / rings Yes (via assignments) No – all targeted devices at once
Assignment types Required and Available Required only
Rollback / uninstall remediation You control it None built in
Change-control friendly Yes Not really
Effort per update Manual, recurring Zero after setup

Neither is strictly better. Auto-update is fantastic for the low-risk long tail (utilities, runtimes, browsers on a fast ring). Guided supersedence still earns its keep where you need a maintenance window, a pilot ring, or a change record.

Enabling Auto-Update

The switch lives in the app-creation wizard, not in a global setting. When you add an Enterprise App Catalog app, the update method is presented as part of the flow:

  1. Apps > Windows > Add > Enterprise App Catalog and pick your app.
  2. Work through the app information and configuration (accept the pre-filled install/detection logic unless you have a reason not to).
  3. On the assignment step, set a Required assignment – auto-update does nothing for Available assignments.
  4. Choose the update method: the default is Update with Supersedence; select Automatically update instead.

The exact screen: the update-method choice appears on the assignments step. Microsoft documents it under Add a Windows catalog app – Step 6: Assignments, which shows the “Automatically update” option in context.

You can spot auto-update apps afterwards by adding the catalog/auto-update column or filter in the Windows apps list. Note that the list does not pin a static version number for these apps – the version is whatever the catalog currently serves, which is the whole point.

The Caveats That Will Bite You

This is where the vendor blogs stop and production begins. Microsoft documents these limitations, but they are easy to miss (see the Limitations and known issues section of the Enterprise Application Management docs):

  • You cannot flip the update method on an existing app. Supersedence -> auto-update (or back) is not editable. To move an already-deployed app onto auto-update you create a new catalog app with auto-update, then use supersedence to uninstall the old one. Plan the migration; there is no in-place switch.
  • No rollback or automatic uninstall remediation. If a bad version ships, auto-update will not pull it back. Remediation is manual – an Uninstall intent or a remediation script.
  • Malicious-version revocation is on you to remediate. If Microsoft pulls a compromised version from the catalog, it posts a notice in the admin center, but you have to find and fix affected devices.
  • Catalog cache lag of up to one hour. The catalog is cached, so a revoked or new version can take up to 60 minutes to reflect – a real exposure window during a security event.
  • No rollout rings or phased deployment. New version out = every targeted device, simultaneously. There is no built-in ring. If you want staging, you build it yourself with separate assignment groups, or you stay on guided supersedence.
  • Reporting shows latest state only. Intune keeps the current reported state per device, not a full version history. Mid-rollout, different devices legitimately show different states.
  • Not supported as a blocking app in the Enrollment Status Page or Autopilot Device Preparation. Use a fixed-version catalog app for ESP gating.
  • No running-app detection. Intune cannot tell whether the app is open when it updates. For an editor or browser mid-session, that can mean a forced close. This is the caveat I would flag hardest to end users.
  • Do not double-manage a title. If a separate LOB/Win32 assignment targets the same app, you get a version race condition. One app, one deployment type.

Monitoring Auto-Update

You lose the pre-deploy review gate, so lean harder on reporting:

  • Enterprise App Catalog apps with updates (Apps blade) – shows which catalog apps have newer versions available. For auto-update apps this is informational, but it is your catalog-freshness pulse.
  • Managed Apps report (per device) – lists installed/not-installed/available apps for a device with application, version, resolved intent, and install status. This is your ground truth for “what version is actually on this machine right now.” See Intune reports overview – Managed Apps report.
  • Per-app device install status – the standard app monitoring blade still applies; expect churn while a version rolls out because reporting reflects only the latest state.

Automating with Graph

Everything above is Graph-addressable through the deviceAppManagement/mobileApps surface (win32CatalogApp / mobile app supersedence resources). If you manage app deployments as code, you can query which catalog apps are on auto-update and audit assignments in bulk rather than clicking through the portal – handy across a multi-tenant MSP estate.

# Requires Microsoft.Graph, scope DeviceManagementApps.Read.All
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"

# List Enterprise App Catalog (Win32 catalog) apps and their assignment intent
Get-MgDeviceAppManagementMobileApp -Filter "isof('microsoft.graph.win32CatalogApp')" -ExpandProperty assignments |
  Select-Object DisplayName, Id,
    @{n='Intent';e={ ($_.Assignments.Intent) -join ',' }} |
    Format-Table -AutoSize

Treat the exact resource types as version-dependent – check the current Intune Graph reference before you build automation on them, because the catalog-app schema is still evolving.

A Rollout Playbook

This is roughly how I would introduce auto-update to a customer rather than flipping everything at once:

  1. Confirm licensing and entitlement. Intune Suite, the EAM add-on, or M365 E5 – and verify the Enterprise App Catalog app type actually appears in the Create wizard. If it is E5, you already paid for it.
  2. Pick the safe long tail first. Utilities and runtimes where a forced update mid-use is a non-event: 7-Zip, Notepad++, PowerToys, the JDKs, CLI tools. Leave user-facing editors and browsers for later.
  3. Deploy as a new Required app with Automatically update to a pilot group. Remember you cannot convert existing supersedence apps in place – build new and supersede the old.
  4. Watch the Managed Apps report for a cycle to confirm devices land on the expected version.
  5. Communicate the no-running-app-detection reality. Tell users that catalog apps may update and close silently, so they should save work. This single message prevents most of the support tickets.
  6. Keep guided supersedence for anything that genuinely needs a maintenance window, a phased ring, or a change record. Auto-update is a tool, not a religion.
  7. Do not double-manage. Retire any legacy LOB/Win32 package for a title before you put it on auto-update.

FAQ

Is EAM auto-update free?
No. It needs the Enterprise App Management entitlement – via the Microsoft Intune Suite, the standalone EAM add-on, or a Microsoft 365 E5 subscription that includes it. Base Intune Plan 1/Plan 2 alone does not surface the catalog.

Can I switch an existing catalog app from supersedence to auto-update?
No. The update method is fixed at app creation. Create a new catalog app with Automatically update, then use supersedence to uninstall the old one.

Does auto-update support update rings or phased rollout?
No. When a new version is published, it goes to all targeted devices at once. If you need staging, use separate assignment groups or stay on guided supersedence.

Does it work for apps assigned as “Available”?
No. Auto-update applies only to Required assignments. Available apps continue to use the existing update workflow.

Will Intune wait if the app is running?
No. There is currently no running-application detection, so an update can close an app that is in use. Warn your users.

Can I roll back a bad version automatically?
No. There is no built-in rollback. Remediate manually with an Uninstall intent or a remediation script.

The Bottom Line

Auto-update turns EAM from a faster packaging tool into something closer to a managed patch service for a large slice of your third-party Windows estate. For the low-risk long tail it is close to set-and-forget, and if you are on Microsoft 365 E5 it costs you nothing extra to start. Just go in eyes-open: there is no rollback, no native ring model, and no running-app detection, so match the update model to the risk of each app rather than reaching for the switch on everything. Start with the boring utilities, watch the reporting, and expand from there.

References and Further Reading