Zero-touch enrolment dies right after Microsoft sign-in ('Page not found' at portal.manager.microsoft.com)
Your corporate-owned Android device sails through Google zero-touch, the user signs in with their work account — and setup dead-ends on a browser page that says "Page not found". The sign-in succeeding is the clue: zero-touch finished its job, and the block is on the Intune side.
The problem
You are enrolling a corporate-owned Android device into Microsoft Intune via Google's zero-touch portal. The device is recognised at first boot, provisioning starts, and the user signs in with their Entra ID work account without error. Then, instead of continuing Android Enterprise setup, the device opens a URL — portal.manager.microsoft.com — and shows "Page not found". Enrolment stops dead, with no error code and no obvious owner.
"The problem occurs AFTER I successfully sign in with my work account. Instead of continuing with Android Enterprise (intune) setup, the device opens this URL: portal.manager.microsoft.com. This page shows Page not found."
— an admin on the Android Enterprise community forum (link in Sources). The thread ended unresolved, and a second admin reported identical symptoms. That is the real cost of this failure: it sits on the boundary between two vendors, so admins bounce between Google's zero-touch support and Microsoft's Intune support, each side reasonably pointing at the other.
Why it happens
Zero-touch-into-Intune is not one system — it is a handoff chain, and each link is owned by a different party. Decode the chain and the broken link becomes identifiable:
| Step | Owned by | If it fails, you typically see |
|---|---|---|
| 1. Device checks in with Google's zero-touch service at first boot (matched by IMEI/serial uploaded by your reseller) | Google / reseller | No provisioning offered at all; the device goes to ordinary consumer setup |
| 2. The zero-touch configuration delivers the DPC plus its extras JSON, which carries the Intune enrolment token | You, in the zero-touch portal | Provisioning starts but errors before any Microsoft branding appears |
| 3. The Microsoft Intune app launches and runs Entra ID sign-in | Microsoft (Entra ID) | Credential, MFA or federation errors at the sign-in screen |
| 4. Intune decides whether to accept the enrolment: profile/token validity, licence, Conditional Access, device limits, restrictions | Microsoft (Intune / Entra ID) | A post-sign-in dead end — including this "Page not found" redirect |
| 5. The management profile applies and setup continues | Microsoft (Intune) | Policy or app failures after enrolment completes |
If the device reached the Microsoft sign-in screen and the sign-in succeeded, links 1–3 worked: zero-touch matched the device, delivered the configuration, and the embedded token was at least well-formed enough to launch the flow. The symptom in this article is step 4 refusing to continue. When Intune declines an enrolment mid-flow, the client can fall back to a web redirect rather than a usable diagnostic — and here that redirect lands on a page that does not resolve. (Note the address is one character away from portal.manage.microsoft.com, Intune's real web endpoint; whatever the redirect's intent, the effect is the same: the enrolment was bounced and the reason was swallowed.)
The usual Intune-side reasons for a bounce at exactly this point:
- Expired enrolment token — the token from your corporate-owned enrollment profile is embedded in the zero-touch configuration at the moment you created it. Tokens expire; the zero-touch config does not refresh itself.
- Broken managed Google Play connection — the Intune-to-managed-Google-Play binding has lapsed or been disconnected, so Android Enterprise enrolments cannot complete.
- Conditional Access — a policy requiring a compliant or registered device evaluates during enrolment, before the device can possibly be compliant: a chicken-and-egg block.
- No Intune licence on the signing-in user.
- Device limits — the Entra ID per-user device maximum or an Intune device limit restriction has been reached, often because of stale records from earlier failed attempts.
The fix
Work through these in order — each is a quick check, and together they cover the known causes of a post-sign-in bounce. (Microsoft's console labels use US spelling; they are quoted as they appear.)
- Stop the two-vendor loop first. Successful Microsoft sign-in means Google's side is finished. Do not spend more time in the zero-touch support queue for this symptom — everything below is on the Microsoft side.
- Check the enrolment profile token expiry. In the Microsoft Intune admin centre: Devices > Enrollment > Android, open the corporate-owned enrollment profile behind your zero-touch configuration and check the token's expiry date. If it has expired, generate a new token — and, crucially, paste the new DPC extras JSON into your zero-touch configuration. Regenerating the token in Intune does nothing on Google's side until you update the config that references it.
- Check the managed Google Play connection. Tenant administration > Connectors and tokens > Managed Google Play. If the binding shows an error or has lapsed, re-approve it; Android Enterprise enrolment cannot complete without it.
- Confirm the user is licensed for Intune. An unlicensed user gets through sign-in but is refused at enrolment.
- Review Conditional Access. In Entra ID, look for policies that apply to the Microsoft Intune Enrollment cloud app or that require a compliant device across all apps. Test by excluding a test account from the suspect policy and re-running enrolment; if it now completes, scope the policy so device registration can happen first.
- Check device limits. Entra ID Devices > Device settings > "Maximum number of devices per user", and Intune Devices > Enrollment > Device limit restriction. Delete stale device records left by previous failed attempts — repeated retries can themselves exhaust the limit.
- Check platform restrictions (if your profile type is user-affinity or work-profile based): Devices > Enrollment > Device platform restriction — confirm the highest-priority restriction that applies to the enrolling user allows the Android Enterprise method you are using.
- Isolate with a QR-code test. Enrol a spare device by scanning the QR code from the same enrollment profile. If QR fails identically, the Intune-side diagnosis is confirmed. If QR succeeds while zero-touch fails, your zero-touch configuration is carrying a stale or mistyped token — replace the extras JSON.
- Read what Intune already knows. The Troubleshooting + support blade in the admin centre shows enrolment failures per user, and the tenant status page will tell you if the service itself is degraded.
In the community thread that prompted this article, the failure pattern (successful sign-in, then a dead redirect) is consistent with steps 2, 5 and 6 above — check token expiry, Conditional Access and device limits first.
How Decolla handles it
Straight answer: it doesn't. Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not touch Android Enterprise enrolment, so it will not fix this Android issue. The steps above are the fix, and they work with or without us.
What Decolla does address is the same class of problem on the Windows side of your estate. Windows zero-touch is also a multi-party handoff chain (hardware registration, Autopilot profile, Entra join, Intune configuration), and it fails in the same maddening way: mid-flow, with the refusing step unnamed. Decolla's approach is to make every step explicit before anything runs: a wizard builds your deployment from a curated catalogue of 260+ items across 21 sections, and the output is a written, itemised plan — each item stating its delivery method and its reversibility class (automatic, reversible, or flagged irreversible) — which you approve before the unattended deployment starts in your own tenant. When something goes wrong, the failure maps to a named item rather than a blame loop, and Decolla can roll back its own changes item by item. The Library ships pre-built, industry-tested policies, scripts and fixes for recurring helpdesk problems, with hardening built in.
Decolla is pre-launch and currently waitlist-only 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