Category Archives: Endpoint Management

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

Using a FIDO2 Security Key Over RDP to Windows Server 2022: On-Prem, Hybrid and Entra-Joined

Posted on by
Reply

“I want to RDP into a Windows Server 2022 and log in with my FIDO2 security key instead of typing a password.” It sounds like a single feature you turn on. It is not. Whether it works at all depends on one thing most people skip past: what your server and your client are joined to.

Before you touch a single setting, you also need to be clear about which of two completely different things you actually want, because they share the word “FIDO2” and almost nothing else:

  1. Authenticate the RDP logon itself with a FIDO2 key – passwordless sign-in to the remote server.
  2. Redirect a FIDO2 key into the session so a web app or app inside the RDP session can use WebAuthn, while the key stays plugged into your local machine.

These have different requirements and different failure modes. Let me take them in order, and for the first one walk through all three join states.

First, the one that trips everyone up: a FIDO2 key is an Entra credential

This is the single fact that makes the rest of the post make sense. A FIDO2 security key is registered in Microsoft Entra ID. It is not, by itself, an on-premises Active Directory credential.

So when you log on to a remote server with a FIDO2 key, two things have to happen:

  • Entra ID authenticates the key.
  • Something has to turn that into a Kerberos ticket the on-prem world (and the server) understands.

That second step is where the join state decides your fate.

Scenario 1: FIDO2 sign-in to the RDP session

Entra-joined

The cleanest case. If both your client and the target are Microsoft Entra joined, FIDO2 sign-in over RDP works with the modern RDP stack (the web-account-selector flow) on current Windows 10, Windows 11 and Windows Server 2022 builds.

The catch with servers: pure Entra join is not supported on Windows Server. Server SKUs do not Entra-join the way a client does. So in practice “Entra-joined target” applies to Windows 10/11 remote hosts, and your Windows Server 2022 box lands in the hybrid scenario below even when the rest of your estate is cloud-first.

What you need:

  • Client (and where applicable the host) Microsoft Entra joined.
  • FIDO2 enabled as an authentication method in Entra ID > Authentication methods (see Microsoft’s FIDO2 enablement guide), with the user in scope and a key registered.
  • Current Windows builds on both ends and an up-to-date RDP client.

For an Entra-joined client signing into an Entra-joined Windows 10/11 host, there is no Kerberos-trust plumbing to configure – it largely just works once the method is enabled.

Hybrid-joined (this is where Server 2022 actually lives)

Because Windows Server 2022 cannot be pure-Entra-joined, hybrid is the realistic target join state for a server. Both the client and the server are Microsoft Entra hybrid joined – joined to on-prem AD and registered to Entra ID.

Here you must build the bridge that turns the Entra FIDO2 authentication into an on-prem Kerberos ticket. That bridge is Microsoft Entra Kerberos, deployed as cloud Kerberos trust:

  • Run the Entra Kerberos setup to create the Microsoft Entra Kerberos Server object in your on-prem AD. It shows up as a special computer object (effectively a read-only-DC-style KDC object) that lets Entra ID issue partial TGTs for your AD domain.
  • Configure Windows Hello for Business cloud Kerberos trust via Intune or Group Policy so the FIDO2/WHfB credential is allowed to request those tickets.
  • Enable the security key sign-in credential provider on the machines. On Entra-joined clients this is on by default; on hybrid-joined devices you turn it on explicitly – via Intune (Authentication method / “Enable security key sign-in”) or the equivalent ADMX policy Turn on security key sign-in under Computer Configuration > Administrative Templates > System > Logon.

With cloud Kerberos trust in place, the flow is: key authenticates to Entra, Entra issues a partial TGT, the on-prem DC completes it, and the server gets a Kerberos logon it trusts. Service tickets and authorization stay on your on-prem domain controllers – you are not moving authorization to the cloud, only the initial credential.

If FIDO2 RDP “authenticates but won’t log on to the server,” cloud Kerberos trust is almost always the missing piece.

On-prem only (no Entra at all)

Here is the honest answer: the native FIDO2 credential provider does not work for on-premises-only devices. Microsoft is explicit about this. No Entra, no FIDO2 sign-in – because there is nothing to issue the Entra side of the credential.

That does not leave you stuck, but it does mean changing the question. Your realistic options are:

  • Use the key as a smart card. Many FIDO2 keys also carry a PIV/smart-card applet. Stand up AD CS (your on-prem PKI), issue smart-card logon certificates onto the key, and you get certificate-based passwordless RDP using the long-standing smart-card logon path. RDP already knows how to redirect a smart card reader into the session. This is “passwordless RDP with a security key” in the literal sense, but the mechanism is smart-card logon, not FIDO2/WebAuthn.
  • Go hybrid. If passwordless-with-FIDO2 specifically is the goal, the supported route is to hybrid-join the estate and deploy cloud Kerberos trust as above. For most shops this is the better long-term answer than building out smart-card PKI just for RDP.
  • A third-party MFA-for-RDP product if you want a step-up factor on top of passwords without the PKI or Entra work.

So: pure on-prem FIDO2 sign-in is not a checkbox – it is either smart-card-via-PKI or a move to hybrid.

Scenario 1 at a glance

Join state (client + server)FIDO2 RDP logon?What you have to configure
Entra joined (Win10/11 host)YesFIDO2 method enabled in Entra; current builds
Hybrid joined (typical for Server 2022)YesEntra Kerberos (cloud Kerberos trust) + WHfB cloud trust + security key sign-in enabled
On-prem only (no Entra)Not nativelyKey-as-smart-card via AD CS PKI, or move to hybrid

Scenario 2: WebAuthn redirection into the session

Different problem, much smaller. You do not want to log into the server with the key – you want a website or app running inside the RDP session to use the FIDO2 key that is physically plugged into your local PC.

That is WebAuthn redirection, and the good news is:

  • It is supported on Windows Server 2022 (and Windows 10 1809+ / Windows 11).
  • It is on by default. There is no positive switch to flip – you only need to make sure nobody disabled it.

The control that matters lives on the server (the RDP host) as Group Policy:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection > Do not allow WebAuthn redirection

Set it to Disabled or Not Configured to allow redirection. If it is Enabled, redirection is blocked and any in-session FIDO2 prompt fails instantly.

This is the one I see bite people most often, and the cause is almost always the same: a hardened golden image. CIS benchmarks and a lot of corporate baselines set “Do not allow WebAuthn redirection” to Enabled. If your security key worked fine on the local desktop but dies the moment you are inside RDP, check this policy before anything else. The ADMX comes from the Windows 11 22H2 administrative templates or newer, so make sure your Central Store is current too.

On a current Remote Desktop client you opt in on the Local Resources tab by ticking WebAuthn (Windows Hello or security keys). For the full walkthrough of using your key inside the session – including Windows 11 client cross-device passkey support – see the companion post: Using Your FIDO2 Key From Inside the RDP Session.

Picking the right path

  • “I want to log into the server with my key.” → Scenario 1. Find your join state in the table. For a real Windows Server 2022, that almost always means hybrid + cloud Kerberos trust.
  • “I want to use my key for a website/app running on the server.” → Scenario 2. Confirm “Do not allow WebAuthn redirection” is not Enabled, and you are done.
  • “We are on-prem only and want passwordless RDP.” → It is not native FIDO2. Either key-as-smart-card via AD CS, or move to hybrid.

Wrap-up

The reason “enable FIDO2 over RDP” has no single answer is that the key is an Entra credential and your server probably is not pure-cloud. Sort out the join state first, then the rest follows: Entra-joined is nearly free, hybrid needs cloud Kerberos trust, and on-prem-only means smart-card PKI or a hybrid move. And if it is really just an in-session web app you are after, the whole thing collapses to one Group Policy that your hardening baseline may have already turned off.

Getting Ready for Windows 11, version 26H2: Upgrade Paths, Autopatch, and Tracking Pilot to Production

Posted on by
Reply

Microsoft has confirmed the next annual feature update, Windows 11, version 26H2, and the headline for IT is a familiar one: this is an enablement package (eKB), not a full OS swap. If you have been through the 24H2 to 25H2 cycle, the playbook is almost identical – but there are a couple of new wrinkles worth planning around. This post walks through the supported upgrade paths, how you drive it with Windows Autopatch and Intune, and how to actually track the rollout from pilot to production.

What 26H2 actually is

26H2 shares the same servicing branch as 24H2 and 25H2. That means for devices already on those versions, the upgrade is delivered as a tiny enablement package – around 174 KB – that simply flips the version and build number (build 26300) after a single restart. No multi-gigabyte download, no long offline phase, no feature-update reboot marathon. The new capabilities ship continuously through monthly cumulative updates and are switched on by the eKB.

Microsoft frames it as “a predictable, low-disruption update experience for organizations and IT professionals,” and from a deployment standpoint that is exactly what it is – an update ring approval rather than a migration project. Expect general availability in the fall of 2026, in line with previous H2 releases.

Upgrade paths – know your starting point

The delivery method depends entirely on the version a device is sitting on today:

  • Windows 11 24H2 / 25H2 – direct eKB upgrade. ~174 KB, one restart. This is the easy 95% for most managed fleets.
  • Windows 11 23H2 and older – different servicing branch, so no eKB. These need the full feature-update media path (~6.5 GB download and the full upgrade experience).
  • The 26H1 caveat – 26H1 sits on a separate Windows core branch and does not roll forward to 26H2 via the standard enablement path. If you have any 26H1 (specialized/insider) devices, plan a different route for them.
  • Windows 10 – no shortcut here. These are full upgrades (or, frankly, replacements) and should already be on your end-of-support migration plan.
Windows 11 26H2 upgrade paths: 24H2/25H2 via enablement package, 23H2 and older via full media, 26H1 on a separate branch
Upgrade paths to 26H2 depend on the version a device sits on today.

Action before fall: run an inventory split by OS version now. Anything not already on 24H2/25H2 is your long-tail – get those onto a current branch first so 26H2 becomes a one-restart eKB rather than a 6.5 GB project.

Driving it with Windows Autopatch

If you are on Autopatch, 26H2 is close to trivial to approve – it appears in the feature update flow like any other release, and because the payload is tiny, distribution can complete in a day rather than weeks.

The mechanics you already rely on still apply. Autopatch groups split your estate into deployment rings – Test, First, Fast, and Last. If you do not define extra rings, Test acts as your pilot and Last as production. Releases flow sequentially through the rings, and Autopatch monitors device telemetry the whole way – if failure or compatibility signals spike, it can automatically pause progression to the next ring.

  • Pilot: keep Test/First small but representative – mix hardware models, key line-of-business apps, and a few power users who will actually report friction.
  • Soak time: because the eKB is so small, the temptation is to rush. Resist it – the value of a pilot is the soak window, not the download time. Give each ring a real bake period to surface app and driver issues.
  • Safety net: you retain Pause, Resume, and Rollback for feature updates directly from Intune if a ring goes sideways.

Not on Autopatch? The same model is available with Intune Feature Update profiles plus Update Rings – you target 26H2 as the feature update version and stagger deferrals/rings manually. You lose the automatic ring progression and telemetry-driven pause, but the staged approach is the same.

Autopatch deployment rings Test, First, Fast, Last with telemetry-driven pause and rollout tracking
Autopatch rings, the telemetry safety net, and what to watch as you promote from pilot to production.

Tracking pilot to production

This is where most rollouts get loose. “We deployed it” is not the same as “we can prove the estate moved.” Here is the reporting stack I lean on:

  1. Reports > Windows Autopatch – the two Autopatch reports give you ring-level rollout status and quality/feature update health. This is your primary “where is each ring” view.
  2. Reports > Device management > Windows Updates – the feature update report and readiness reporting validate which devices are eligible and which are blocked, before and during the push.
  3. Email notifications – make sure your Autopatch admin contacts are current so you actually receive the proactive alerts rather than discovering issues in a dashboard.
  4. A simple version-count KQL/report – track devices reporting build 26300 over time as your single “percentage on 26H2” number for management. Watch the curve per ring, not just the total.

Define your exit criteria before you start: e.g. pilot ring at >95% success with zero unresolved Sev-1 app issues for X days before releasing the next ring. Let the telemetry and your soak window – not the trivial download size – gate each promotion.

Support lifecycle

The usual split applies: Enterprise, Education, IoT Enterprise and Enterprise multi-session get 36 months of support, while Home, Pro, Pro Education and Pro for Workstations get 24 months (support running to roughly October 2028). Factor that into whether 26H2 is a “move now” or a “this fall” decision for each ring.

A short pre-flight checklist

  • Inventory by OS version – identify anything not on 24H2/25H2.
  • Get the long-tail (23H2 and older, Windows 10) onto a current branch first.
  • Flag any 26H1 devices for a separate path.
  • Confirm Autopatch groups / Intune feature update profiles and rings are sane.
  • Verify Autopatch admin contacts and reporting access.
  • Write down your per-ring exit criteria and soak windows.

Further reading and references

Bottom line: 26H2 is an approval, not a migration – for the devices that are on a current branch. Spend your effort on the long-tail and on a disciplined pilot-to-production cadence, and the eKB itself will be the least interesting part of the project.

Fix the iTunes Sign-In Prompt on Intune-Managed iPhones: iOS Store App vs VPP Device Licensing

Posted on by
Reply

You manage a fleet of corporate iPhones through Microsoft Intune. Enrollment is automated through Apple Business Manager (ABM), apps deploy silently through the Volume Purchase Program (VPP), and users never see an App Store login. Then one day, your service desk starts getting tickets:

“Sign in to iTunes Store. Sign in to allow Contoso A/S to manage and install apps.”

A handful of devices show the prompt at first. A few days later, dozens. Users tap Cancel, the dialog disappears, and a few hours later it reappears. Some users sign in with personal Apple IDs to make it go away, which is exactly what you do not want on a corporate device.

This is one of those issues that looks like an Apple ID, ABM, or enrollment problem – but almost never is. In every case I have worked, the root cause was the same: somewhere in the tenant, an app was added as an iOS Store App when it should have been added as an iOS Volume Purchase Program app. This post walks through why those two app types behave so differently, how to confirm which one is causing the prompt, and how to fix the issue across a large device estate without disrupting users.

Why iOS Devices Ask for an Apple ID in the First Place

Intune offers several iOS app types in the admin center. Two of them install the same app from the same App Store listing, but they have completely different licensing and installation behavior:

  • iOS Store App – A direct link to a public App Store listing. The app installs into the user’s iCloud account. The device must be signed in to the App Store with a personal or managed Apple ID for the install to complete. There is no concept of device-based licensing.
  • iOS Volume Purchase Program app (VPP) – An app license that your organization owns through Apple Business Manager. With Device licensing, the license is assigned to the device itself – no Apple ID is required on the device for the install. The app simply appears.

The two app types look almost identical in the admin center. Both can point to the same App Store URL. Both can be assigned as Required, Available, or Uninstall. The difference is invisible until a device tries to install the app and discovers it has no Apple ID signed in.

When an iOS Store App is assigned as Required to a supervised device with no Apple ID, iOS does what it is told – it prompts the user to sign in so the install can proceed. That is the prompt your users are seeing.

Why You May Not Have Seen This Before

A fresh ABM enrollment with VPP apps assigned through Device licensing never triggers an Apple ID prompt because no app on the device needs one. The issue surfaces when somebody adds the same app a second time – as an iOS Store App – usually because they pasted the App Store URL into the wrong “Add app” wizard. The VPP version may still be present, but the iOS Store App duplicate is now competing for the same slot on the device, and only one of them can win.

How to Confirm This Is Your Issue

Before you start changing assignments, confirm the diagnosis. Three quick checks usually settle it.

Check 1: List All iOS Apps with Required Assignments

In the Intune admin center, go to Apps > iOS/iPadOS and filter the list. Look at every app where the App type column shows iOS store app. For each one, open the app and check Properties > Assignments.

Any iOS Store App with a Required assignment is a candidate for the prompt. iOS Store Apps assigned only as Available or Uninstall do not trigger the prompt – they sit quietly in the company portal or only act when the user actively removes the app.

Check 2: Cross-Reference with VPP

For each suspect iOS Store App, search for a VPP version of the same app. The naming will be similar but not identical – the VPP version typically shows the publisher and a different icon variant. If both versions exist, the iOS Store App is almost certainly redundant.

Check 3: Look at the Audit Log

Intune’s audit log will tell you exactly when each app was added and by which admin account. Go to Tenant administration > Audit logs and filter on the Mobile App category. Search for the app name and check the Create entries. In one recent case, an admin had bulk-added a dozen iOS Store App duplicates within a 20-minute window – clearly someone working through a list using the wrong wizard.

If checks 1 and 2 confirm the duplication and check 3 confirms when it happened, you have your root cause.

Why You Cannot Just Delete the iOS Store App

The natural reaction is to delete the iOS Store App duplicate and be done with it. Resist that urge until you have a rollout plan, because three things can go wrong:

  1. Users still see the prompt until iOS finishes its install queue. iOS does not automatically discard a pending install when its source is removed. The user has to Cancel the prompt at least once – sometimes more than once – before the MDM channel processes the change.
  2. Required and available install intent on a managed device is sticky. If the VPP version is not already assigned and licensed at the device level, removing the iOS Store App leaves users with no app at all.
  3. Filters and groups can overlap in non-obvious ways. If the iOS Store App is assigned to a broad group and the VPP version is assigned to a different broad group, deleting one may pull the app from devices that should still have it.

The safe sequence is: assign the VPP version with Device licensing first, validate on a single device, then remove the iOS Store App.

The Pilot Approach: Validate on One Device Using Assignment Filters

Before you touch a production assignment, prove the fix on one device. Intune’s Assignment Filters make this clean.

Step 1: Create a Single-Device Filter

In the Intune admin center, go to Tenant administration > Filters > Create.

  • Platform: iOS/iPadOS
  • Name: Something obvious like Pilot-iPhone-XYZ123-only
  • Rule syntax:
(device.deviceName -eq "XYZ123")

Replace XYZ123 with the actual device name from Devices > iOS/iPadOS devices. Use Edit in advanced mode if you prefer to write the rule directly.

Step 2: Exclude the Pilot Device from the iOS Store App Assignment

Open the problematic iOS Store App in Intune. Go to Properties > Assignments > Edit. On the existing Required assignment, click Filter and set:

  • Filter mode: Exclude
  • Filter: Pilot-iPhone-XYZ123-only

This tells Intune to apply the iOS Store App’s Required assignment to everyone except the pilot device. The pilot device is now isolated from the prompt – existing prompts may still need to be dismissed once, but no new ones will queue.

Step 3: Assign the VPP Version with Device Licensing to the Pilot Device

Open the VPP version of the same app. If it does not yet have a Required assignment to the same target group, create one:

  • Assignment type: Required
  • Group: The same group the iOS Store App was assigned to
  • License type: Device
  • Filter: Pilot-iPhone-XYZ123-only
  • Filter mode: Include

This is the inverse of Step 2 – the VPP assignment now applies only to the pilot device. The rest of your estate still gets the (about to be removed) iOS Store App version; the pilot device gets the VPP version with a device-bound license.

Step 4: Have the Pilot User Dismiss the Prompt and Sync

Walk the pilot user through these exact steps:

  1. When the iTunes sign-in prompt appears, tap Cancel.
  2. Open Settings > General > VPN & Device Management > the MDM profile.
  3. Tap Sync to force a check-in.

Within a minute or two, the VPP version of the app installs silently. No Apple ID prompt. The app shows the small organisation marker indicating it was installed by MDM.

If the install fails or the prompt comes back, stop and investigate before going further – usually the cause is a missing VPP license assignment or an expired VPP token (more on tokens below).

Rolling Out the Fix to the Rest of the Estate

Once the pilot is green, the rollout is mechanical. For each affected app:

  1. On the VPP version, remove the Pilot-XYZ123-only filter so the Required + Device-licensing assignment applies to the full target group.
  2. On the iOS Store App version, remove the existing Required assignment entirely. Do this before deleting the app to avoid an Intune sync that might re-prompt users.
  3. Delete the iOS Store App entirely once no devices reference it. This also makes sure nobody re-uses it accidentally later.

If you have several apps to fix, work through them one at a time. iOS handles MDM commands serially, so a batch change can produce more prompts than you would expect.

What Users Should Expect

Communicate clearly to end users before you flip the assignment. A short email along these lines works well:

Over the next 24 hours, you may see a sign-in prompt on your work iPhone asking you to log in to iTunes or the App Store. Please tap Cancel. Do not enter any Apple ID. The app you are missing will install automatically within a few minutes after you cancel the prompt.

The behaviour is non-obvious: iOS only processes the next MDM command after the current prompt is dismissed. Until the user taps Cancel, the device is effectively stuck waiting for the user.

Cleanup: Filters, Duplicates, and Audit Trail

After the rollout is complete, do not leave the scaffolding in place:

  • Delete the pilot assignment filter (Pilot-iPhone-XYZ123-only) so it does not get reused accidentally.
  • Confirm both iOS Store App duplicates are deleted – keeping them around “just in case” invites the same mistake again next quarter.
  • Document what happened in your change log so future admins know the difference between iOS Store App and VPP and which to use.
  • Run a tenant-wide review of remaining iOS Store Apps. Any iOS Store App with only Uninstall or Available (without enrollment) assignments is safe. Any iOS Store App with a Required assignment to a device group should be evaluated.

A Quick Reference: iOS Store App vs VPP at a Glance

AspectiOS Store AppiOS VPP App (Device licensing)
SourcePublic App Store URLApple Business Manager (purchased)
Requires Apple ID on deviceYesNo
Required-install on supervised devicesTriggers iTunes sign-in promptInstalls silently
License consumedNone tracked by MDMOne per device
Revoke licenseNot possibleYes, from Intune
Update behaviorSame as App StoreSame as App Store
CostFree apps only (in practice)Free and paid apps
Recommended for managed iOSNoYes

The short version: on a corporate-owned iOS device managed through Apple Business Manager, VPP with Device licensing is the only app type that should appear as Required for first-party and approved third-party apps.

How to Prevent This from Happening Again

The root cause is almost always procedural – an admin selected the wrong app type from the Intune wizard. A few controls reduce the chance of recurrence:

  • Document the standard. Add a one-line rule to your Intune operations doc: “All Required iOS apps must be added as iOS Volume Purchase Program apps. iOS Store Apps may only be used for Available or Uninstall assignments.”
  • Restrict app creation with RBAC. Use scope tags and Intune’s role-based access control to limit app creation to a small group of admins who know the difference. The principle of least privilege applies to MDM tenants too.
  • Use audit log alerts. Microsoft Graph + a small Logic App can email you whenever a new iOS Store App is created. Quick to set up, quick to react.
  • Check the VPP token expiry. A frequent secondary cause is an expired VPP token. When a token expires, Intune cannot create or renew Device licenses, and admins reach for “iOS Store App” as a workaround that turns into a permanent footgun. Renew the token annually and set a calendar reminder a month in advance.

Healthy VPP Token Practices

A VPP token has a 12-month validity. When it is close to expiry, Intune shows a banner in the Tenant administration > Connectors and tokens > Apple VPP Tokens view. After expiry:

  • Existing licensed apps continue to function.
  • New licenses cannot be assigned.
  • Token renewal requires a new .vpptoken file from Apple Business Manager.

If your token has just been renewed and apps are stuck in Failed state, revoke and re-assign licenses one app at a time. Bulk re-assignment occasionally fails for individual apps, and the only way to clear the failed state is a manual revoke + reassign cycle.

Troubleshooting: When the Prompt Will Not Go Away

If you have applied the fix and a specific device is still prompting, work through these in order:

  1. Has the user tapped Cancel at least once? iOS sometimes queues multiple install commands – the user may need to dismiss two or three prompts before the queue drains.
  2. Force a sync. From the device: Settings > General > VPN & Device Management > MDM profile > Sync. From Intune: Devices > select device > Sync.
  3. Confirm the device is licensed for the VPP version. Open the VPP app in Intune > Device install status. The device should be listed with Installed or Pending. If it is Not applicable, the assignment is not reaching the device – check group membership and filters.
  4. Check the VPP token health. Tenant administration > Connectors and tokens > Apple VPP Tokens. If the token shows any warning, address that first.
  5. Reboot the device. Last resort, but occasionally clears a stuck MDM channel.

If you have exhausted these, look at the device’s Managed Apps report. An app that should be VPP-licensed but appears under iOS Store App lineage indicates the old assignment is still active somewhere – usually a forgotten filter or a duplicate group assignment.

FAQ

Will users lose any data when I switch from iOS Store App to VPP?

No. The App Store install and the VPP install are the same app binary from the same listing. Local data and settings are preserved across the transition because iOS treats them as the same bundle ID.

Do I need a managed Apple ID for VPP with Device licensing?

No. Device licensing is the entire point – the license is bound to the device hardware identity, not to any Apple ID. The device can have no Apple ID signed in at all, and VPP apps will still install.

Can I keep using iOS Store Apps for some apps?

For apps you want to make optionally available to users through the Company Portal, yes – assign them as Available. For Required deployment to corporate-owned devices, no. Switch them to VPP.

What about iPadOS devices?

The same rules apply. iPadOS uses the same MDM commands and the same VPP licensing model as iOS. If you have iPads in the same affected group, they will exhibit the same prompt behaviour and be fixed by the same approach.

It can be. A token renewal sometimes leaves individual app licenses in a Failed state until they are re-assigned. This is a separate issue from the iOS Store App vs VPP problem, but you may encounter both at once if the same admin tried to “work around” the failed VPP state by adding iOS Store App versions. Treat the VPP licensing failures as a separate workstream once the prompt is gone.

Summary

If iOS devices managed by Microsoft Intune are showing an iTunes or App Store sign-in prompt, do not start with Apple ID configuration, ABM enrollment, or DEP profiles. Start with your app inventory. Look for iOS Store Apps with Required assignments that overlap with VPP versions of the same app. Fix one device first using assignment filters, then roll the change out to the rest of the estate, and finish by deleting the iOS Store App duplicates entirely.

The technical fix is simple. The harder part is preventing the next admin from making the same selection in the same wizard – so document the standard, restrict who can add apps, and keep your VPP token healthy. Your users will never see another iTunes prompt, and your service desk will get its mornings back.

References