Samsung KME enrolment stalls at 'Please click here to continue' (One UI firmware bug)
Galaxy S23s pushed through Knox Mobile Enrolment hang on a dead 'Please click here to continue' link in Chrome, while older models on the exact same profile enrol fine. The cause is a One UI firmware bug, not your configuration — here is how to prove that quickly and what to do about it.
The problem
You push a batch of Samsung Galaxy S23s through Knox Mobile Enrolment (KME) into Microsoft Intune. Each device gets partway through provisioning, then Chrome opens https://play.google.com and lands on a page that says "Please click here to continue". Tapping the link does nothing. The device is wedged mid-enrolment and cannot be completed.
The confounding detail: older models enrol perfectly on the same KME profile. As the admin who reported this in the Android Enterprise community described it: "Chrome browses to https://play.google.com. The page says: Please click here to continue. No matter how many times you tap that link, nothing happens." In that case, S20s enrolled fine while every S23 stalled — nothing in the Knox portal or the Intune enrolment profile had changed.
Who hits this: Android Enterprise administrators provisioning Samsung fleets through KME, typically when a new model or a new One UI firmware build enters the fleet. In the reported case, an entire device model was effectively un-provisionable via KME for months.
Why it happens
This is not a configuration error. If the same KME profile enrols other models cleanly, the profile, the Intune enrolment settings and the Knox portal registration are all exonerated. The remaining variable is device firmware.
During KME provisioning, the Samsung setup wizard hands off to Google Play services and Chrome to continue the managed-provisioning flow — fetching the device policy controller and resuming enrolment. On the affected S23 firmware, that handoff chain breaks: the interstitial page renders, but the continuation link is dead, so provisioning never resumes.
Samsung confirmed the root cause to the affected customer. From the community thread, verbatim:
"Samsung told us it was a bug in 6.0. We had to wait for the S23s to start shipping with 6.1 pre installed."
The general lesson is worth internalising: KME enrolment failures are frequently firmware-version-specific, not configuration errors. A particular model / One UI / security-patch combination can be broken for enrolment while adjacent models and builds work — and the failure mode looks, at first glance, exactly like a misconfigured profile.
The fix
Isolate the variable first
- Same profile, different model. Enrol a different Samsung model against the identical KME profile. If it completes, your Knox and Intune configuration is not the problem — stop editing it.
- Same model, different method. Run a control enrolment on the failing model using the QR-code method instead of KME. If the device enrols by QR but not by KME, the fault sits in the KME/firmware interaction, not in Intune.
- Record the firmware level out of the box. Note the One UI version and security-patch level on a failing unit, then search the Android Enterprise community and Samsung Knox forums for that exact model-and-build combination before spending hours on your own tenant. Someone has often hit it first.
Work around it
- Update firmware before enrolling. Setup-wizard bugs are typically fixed in a later One UI build. Take the over-the-air update during setup where the wizard offers one, or flash the latest firmware via Samsung Smart Switch, then factory-reset so the device re-triggers KME on the new build.
- Escalate with evidence. If no fixed firmware exists yet, raise it with Samsung through your reseller or Knox support, attaching the model, build number and enrolment behaviour. In the reported case Samsung acknowledged the One UI 6.0 bug; the practical resolution was new stock shipping with 6.1 preinstalled.
- Keep an internal register. Log model + firmware + enrolment method + outcome every time you provision a new combination. The known-bad combination gets recorded once instead of being rediscovered per batch.
What not to burn time on
Rebuilding the KME profile, re-uploading the enrolment configuration, or re-syncing the Knox portal will not help once the control tests above have exonerated your configuration. The bug is on the device, and only a firmware change removes it.
How Decolla handles it
Straight answer: it doesn't. Decolla provisions Windows devices over your own Intune/Autopilot tenant. It does not touch Android, Knox Mobile Enrolment or Samsung firmware, so it cannot fix or work around this bug.
The reason this article is in our knowledge base is that the failure pattern is exactly the one Decolla is built against on the Windows side: a platform bug that looks like a configuration error and gets rediscovered one fleet at a time. Decolla's Library — pre-built, industry-tested policies, scripts and fixes, including recurring helpdesk fixes — exists to capture that kind of field knowledge once, so individual admins don't have to relearn it. Every Decolla deployment starts from a written, itemised plan you approve before anything runs, and Decolla's own changes can be rolled back per item.
Decolla is pre-launch. If Windows provisioning is your side of the fleet, you can join the waitlist 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