HomeKb › Vpp token renewal duplicate apps
Knowledge base · Cross-platform

Duplicate apps in Intune after a VPP token renewal

Apple VPP (Apps and Books) tokens expire every 12 months, and the renewal has one hidden wrong turn: add the fresh token as a new entry instead of renewing the existing one, and Intune duplicates every VPP app in your tenant. Here is how to renew safely, how to recover if you already have duplicates, and which account events kill a token before its printed expiry date.

The problem

Once a year, the Apple Volume Purchase Program token (the .vpptoken file that connects Intune to Apps and Books in Apple Business Manager) comes up for renewal. Two failure modes are common, and both are easy to walk into:

Anyone administering Apple devices through Intune hits this eventually — it is an annual ritual with a once-a-year opportunity to get it wrong, often performed by whoever happens to hold the console that month.

Why it happens

Each .vpptoken file identifies a specific location in Apple Business Manager, and the licences you have bought are held against that location. Intune, however, keys its synced VPP app inventory to the token object you created in the console, not to the underlying Apple location. Upload the same location's fresh token as a second token entry and Intune has no reason to treat it as the same connection: it is a new sync source, so it pulls the location's entire app list again. Result: a complete duplicate set of apps, while your group assignments remain pinned to the apps that came in under the original token. Renewing very late — after the old token has already expired — can produce the same re-appearance effect.

The silent-expiry half of the problem follows from how VPP licensing works. A device that already has an app installed holds both the binary and its licence association locally; nothing about day-to-day use touches the token. Only operations that go back through Apple — new installs, app updates, revoking or reassigning a licence — need the token to be valid. So an expired token produces zero symptoms until the next management action, which hides the failure precisely when it is cheapest to fix.

Finally, the token is bound to the Managed Apple ID that downloaded it. Certain account events invalidate the token immediately, well before the expiry date printed in the console: a password change on that Apple ID, the account being disabled or deleted, or domain/federation changes in Apple Business Manager. Tokens tied to a specific person's account are the classic casualty — the person leaves, the account is disabled, and the connector dies mid-year.

The fix

Renew in place — never create a second token

  1. In Apple Business Manager, sign in (ideally with the same Managed Apple ID that owns the token) and go to your account name > Preferences > Payments and Billing (Apps and Books). Download the current .vpptoken for the location.
  2. In Intune, go to Tenant administration > Connectors and tokens > Apple VPP tokens. Select the existing token row — do not use Create — and choose Renew, uploading the fresh file over the top.
  3. Confirm the token shows as Active with a new expiry roughly 12 months out, then trigger a sync and spot-check that app counts are unchanged.

If you already have duplicates

Prevent the early-expiry surprises

How Decolla handles it

Straight answer: Decolla does not manage Apple Business Manager or VPP tokens. Decolla is zero-touch Windows device provisioning, running over your own Intune and Autopilot tenant — so it will not renew or repair an Apple token for you, and we will not pretend otherwise.

We publish this article because the failure pattern is exactly the class of problem Decolla is built around on the Windows side: a routine operation with one undocumented wrong turn, where knowing the correct path in advance is the whole fix. Decolla works from a curated catalogue of 260+ items across 21 sections, and before anything runs it produces a written, itemised plan stating the delivery method and reversibility class of every item — automatically reversible, reversible, or explicitly flagged irreversible — for approval up front. After deployment, Decolla can roll back its own changes per item. Its library packages pre-built, industry-tested policies, scripts and fixes for recurring helpdesk problems, so the known traps are answered before they are sprung rather than diagnosed afterwards.

Decolla is pre-launch; the waitlist is open at decolla.app.

Sources

See it on a real device.

Decolla is in private build — early-access members see a build defined, deployed and rolled back first.

Get early access