TL;DR: If the same Apple Business Manager (ABM) location token is uploaded into more than one MDM, app updates can silently break — even though installs still work. Apple allows this configuration but doesn't coordinate license activity between MDMs. The fix requires a clean token migration: revoke licenses, remove the token from the old MDM, then re-upload to the new one. Better yet, use a dedicated ABM location per MDM.
The Problem: A VPP Token Shared Across Two MDMs
A customer recently hit what looked like a routine app deployment issue. VPP app updates were failing in their Esper tenant, but installs worked fine. No obvious sync errors. License counts looked normal.
The only visible clue was buried in the device error chain:
Error Chain: [
{1005 DeviceManagement.error Could not install app.}
{9610 ASDServerErrorDomain Unhandled exception}
]
That 9610 error — an App Store daemon exception — turned out to be the key. After investigation, the root cause was straightforward: the same Apple Business Manager (ABM) location token had been uploaded into two different MDMs.
Apple allowed it. No warnings appeared. And the system quietly broke.
Why Apple allows this (and why It still breaks)
Apple Business Manager is designed as flexible infrastructure. It intentionally does not lock a token to a single MDM, prevent downloading the same token multiple times, warn when multiple systems use the same location, or show which MDM is currently using a given token.
This flexibility exists for good reason. It supports MDM migrations, enterprise reorganizations, multi-region deployments, and parallel testing environments.
But Apple's implied architecture model is clear:
One ABM location = One license pool = One MDM authority
The system allows other configurations. It just doesn't coordinate them.
What actually happens when two MDMs share a token
Each Apps & Books location token corresponds to a single ABM location, a single shared license pool, and a single set of assignment records inside Apple's servers.
When an MDM syncs a token, it queries Apple for the current license inventory, assigns licenses to devices or users, and maintains its own internal record of which licenses it controls. The problem is that Apple processes these requests as they arrive, without any awareness that another MDM is doing the same thing against the same pool.
There is no locking mechanism to prevent concurrent management, no concept of a "primary" MDM, no conflict warnings if another system is assigned from the same pool, and no cross-platform visibility into license usage.
Each MDM operates as if it's the sole authority — and when they disagree, Apple's assignment state drifts out of sync with what either MDM expects.
How to Tell If You Have a Shared Token Problem
These are the most common symptoms of a VPP location token conflict between MDMs:
- App updates fail, but fresh installs succeed — the most telltale sign
- License counts don't match expectations in the MDM dashboard vs. ABM
- Random assignment failures that don't follow a pattern
- Apps stuck in "installing" state indefinitely
- Intermittent App Store daemon errors, particularly error 9610
- Uninstall/reinstall temporarily fixes the issue — a strong signal that the license assignment state is the problem, not the app or the device
If you're seeing this pattern, check whether the same ABM location token has been uploaded to more than one MDM.
Download: The MDM Migration Survival Guide
How to Fix It: Clean MDM Migration Without Breaking VPP
If you need to move from one MDM to another and a VPP token is involved, follow this sequence carefully. Skipping steps — particularly the license revocation — is where most migrations go wrong.
Step 1: Freeze assignments in the old MDM
Stop issuing new app assignments from the old MDM. Document which devices and users currently hold licenses so you have a migration reference.
Step 2: Revoke all licenses in the old MDM
Reclaim all device-based and user-based licenses. Confirm that license counts match what ABM shows as available. Then force a full token sync and verify that all license assignments have been cleared.
This is the most critical step. It clears Apple's server-side assignment records so the new MDM starts with a clean license state.
Step 3: Remove the token from the old MDM
Delete the token from the old system entirely. Confirm it is no longer syncing.
Step 4: Upload the token to the new MDM
Download a fresh copy of the location token from ABM. Upload it to the new MDM, perform a full license sync, and validate that license counts are correct.
Step 5: Reassign apps in the new MDM
Redeploy apps to devices. In some cases this may require an uninstall and reinstall cycle on the device. Monitor device logs to confirm successful installation and validate that updates work correctly going forward.
How to Avoid Sharing Tokens with a Dedicated ABM Location
For larger or more complex environments, the cleanest approach is to avoid sharing tokens entirely:
- Create a new ABM location specifically for the new MDM.
- Purchase or transfer licenses into that location.
- Use that location exclusively with the new MDM.
Pro tip: Use clear, descriptive naming conventions for ABM locations so that any administrator in ABM immediately knows which location maps to which MDM. This small step prevents the misconfiguration from recurring.
This approach eliminates cross-system historical state entirely and is the recommended path for any organization running multiple MDMs — whether permanently or during a transition period.
Key Takeaways
Apple Business Manager is designed to be flexible — but that flexibility assumes intentional architecture decisions on the customer's side. A VPP location token is not a shared utility. It's a management boundary. When two MDMs operate against the same token, subtle license conflicts are nearly inevitable: installs may work, but updates, reassignments, and sync operations degrade over time.
The fix is structural, not technical. Assign one ABM location per MDM, follow a clean migration sequence when transitioning, and name your locations clearly so the mapping is obvious to everyone on the team.
Need to get your migration process started? Check out our MDM migration help article. It's a step-by-step guide to make your migration to the Esper ecosystem as painless as possible.
Learn more: MDM solutions for iOS, Windows, Linux, and Android >
