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:
- The duplicate-apps trap. An admin downloads the fresh token from Apple Business Manager and, in Intune, adds it as a new token instead of renewing the existing entry. Intune then syncs the full app list for that location a second time: every VPP app now appears twice under Apps > All apps, with all the assignments and licence history still attached to the original set. As Brian Reid puts it: “renewing late (token already expired) or creating a new token rather than renewing the existing will result in all the apps appearing again (a second time) in Intune” — and, bluntly, “DO NOT create a new one in Intune.”
- The silent expiry. A token that has quietly lapsed does not make anything visibly break. Apps already installed on devices keep working, so nothing pages the helpdesk. What actually stops is everything management-plane: no new VPP app deployments, no app updates syncing, no licence assignment or reallocation. The failure only surfaces days or weeks later, when someone tries to push an app to a new starter and it never arrives.
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
- 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
.vpptokenfor the location. - 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.
- 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
- Establish which token each app set belongs to — every VPP app in Intune records its associated token — and verify your assignments live on the original set.
- Delete the newly created duplicate token entry. Deleting a VPP token removes the apps it synced, which clears the duplicate set in one move. Check twice before deleting: removing the wrong token deletes the app set carrying your assignments.
- If the original token has meanwhile expired, renew it in place first, confirm it is Active, and only then remove the duplicate.
Prevent the early-expiry surprises
- Hold the token against a dedicated service Managed Apple ID, not a named individual's account. When that individual leaves and the account is disabled, the token dies with it.
- Treat these as token-invalidating events, regardless of the printed expiry date: a password change on the owning Apple ID, the account being disabled or deleted, and domain or federation changes in Apple Business Manager. After any of them, re-download the token and renew in place straight away.
- Note the expiry date shown under Connectors and tokens and set a reminder comfortably ahead of it — renewing before expiry, in place, is the path with no side effects.
- Apply the same discipline to the Apple MDM push certificate and enrolment programme tokens: always renew the existing object, using the same Apple ID that created it.
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
- Brian Reid (C7 Solutions) — Renewing Apple tokens in Intune
- Microsoft Learn — Manage Apple volume-purchased apps in Intune
- CloudTekSpace — How to renew an Apple VPP token in Intune
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