HomeKb › Afw setup cope enrolment loop
Knowledge base · Android

afw#setup with a COPE token loops forever at 'Your work checklist' on Android 11+

If your Android enrolment sails through Google sign-in and then jams at "Your work checklist" with a Set up button that does nothing, you have hit a dead method: the afw#setup identifier is not supported with a corporate-owned work profile token on Android 11 and later. Nothing in the flow tells you. The only way out is a factory reset — then re-enrolling by a supported method.

The problem

You are enrolling a corporate-owned Android device into Intune. At the Google sign-in screen during out-of-box setup you type afw#setup — the old DPC identifier method — and the enrolment token you are using is for Corporate-owned devices with work profile (COPE). Everything appears normal: the DPC downloads (Google's Android Device Policy app), the wizard walks through its steps, and then the device lands on the Your work checklist screen at the step Register your device.

Tapping Set up does nothing, or cycles straight back to the same screen. Some devices show "Registration is taking longer than expected. Hang on while we keep trying" and never progress. Navigation buttons are typically unresponsive, so you cannot back out. There is no error message, no event in the Intune portal that explains it, and no way forward on the device.

The behaviour affects Android 11 and later regardless of manufacturer — timmyit.com reproduced it on both Samsung and Sony hardware. Because the flow fails silently and late, admins commonly burn a long stretch per device retrying, re-downloading the Company Portal, or swapping tokens before discovering the method itself is the problem.

Why it happens

afw#setup is the DPC identifier provisioning method: typing it in place of a Google account during setup pulls down the management app (the DPC — Google's Android Device Policy, which Intune uses for corporate-owned Android Enterprise modes; the Company Portal app is Intune's agent for personally-owned BYOD enrolments) and kicks off managed provisioning. It dates from the early Android Enterprise era and is still accepted by the setup wizard on current builds.

The catch: on Android 11 and later, the DPC identifier is not a supported provisioning method for corporate-owned devices with a work profile. Microsoft's and Google's documentation list the supported methods for that management mode as QR code, zero-touch enrolment and Samsung Knox Mobile Enrollment — the DPC identifier is not among them. As timmyit.com puts it:

"On Android 11 and newer the afw#setup option is no longer supported for COPE specifically tho you can still use it but you will end up in the scenario described in this article." — timmyit.com

Crucially, nothing enforces the restriction up front. The wizard accepts the identifier, provisioning proceeds most of the way, and the flow only breaks at device registration — where the unsupported method/mode combination cannot complete. Instead of an error you get an infinite loop at "Your work checklist". The device is part-provisioned with no supported path to finish and no supported path to abort.

The fix

1. Recover the stuck device — factory reset is the only exit

There is no on-screen escape from the loop. Reset via recovery mode:

  1. Force the device off (long-press power; on some models you need a button combination).
  2. Boot into recovery — the button combination is manufacturer-specific: on Samsung hold Volume Up + Power, and timmyit.com notes some models require a USB connection to a PC for the combination to work.
  3. Select Wipe data/factory reset, confirm, then reboot.

The device is mid-setup, so there is normally no user data to lose — but the reset is irreversible, so confirm you are holding the right device before wiping.

2. Re-enrol using a method that is supported for COPE on Android 11+

3. Stop the next person hitting it

Remove afw#setup from your runbooks and wiki pages for corporate-owned enrolments, and brief the helpdesk that the loop means "wrong method", not "broken device". Then keep a compatibility matrix next to your enrolment documentation so nobody starts down a dead path again:

Enrolment methodPersonal work profile (BYOD)Corporate-owned work profile (COPE)Fully managed / dedicated
Company Portal appSupported (this is the BYOD method)Not usedNot used
DPC identifier (afw#setup)Not usedUnsupported on Android 11+ — loops at "Your work checklist"Legacy — verify against current Microsoft documentation before relying on it
QR codeNot usedSupportedSupported
Zero-touchNot usedSupported (zero-touch reseller devices)Supported (zero-touch reseller devices)
Samsung KMENot usedSupported (Samsung devices)Supported (Samsung devices)

Minimum OS versions vary by method and management mode — check the current Microsoft Learn pages for your scenario before committing a rollout to one method.

How Decolla handles it

Straight answer first: Decolla does not fix this one. Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not manage Android enrolment, so an Android device looping at "Your work checklist" is outside what it touches. The steps above are your fix.

What Decolla is built against is the underlying failure pattern this niggle exemplifies: a provisioning flow that lets you start down an unsupported path, fails silently hours later, and leaves a wipe as the only exit. On the Windows side, Decolla works the opposite way round. You define the build through a wizard against a curated catalogue of 260+ items across 21 sections, and Decolla produces a written, itemised plan — with the delivery method and a reversibility class (automatically reversible, reversible, or explicitly flagged irreversible) for every item — which you approve before anything runs in your tenant. The Library behind the catalogue is pre-built and industry-tested, including recurring helpdesk fixes and built-in hardening, so known-dead combinations do not make it into a plan in the first place. And if something Decolla deployed does need to come back out, it offers per-item rollback of its own changes — not a factory reset.

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