Setup guide · from scratch
Create an Entra dynamic device group for corporate Android Enterprise devices
Targets corporate Android devices automatically by attribute. Enrol one canary device FIRST and read its real deviceOSType — 'AndroidEnterprise' catches fully managed/dedicated but misses BYOD work profile ('AndroidForWork').
≈ 20 min
Google — Android · step 4 of 5 · ≈ 20 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 20 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- A spare corporate Android device you can factory-reset and enrol as the canary — the rule is built from what it actually reports, not from documentation.
- Admin rights to create Entra groups AND to read device attributes in Intune (Intune Administrator plus Groups write).
- Managed Google Play already connected and a corporate enrolment profile ready, so the canary enrols as Company rather than Personal.
- A clear list of which modes this group must catch (fully managed, dedicated, COPE, BYOD work profile) — they do not all report the same deviceOSType.
The steps
- Enrol ONE test corporate Android device first so you can read its real attributes.
- Go to Intune > Groups > New group; set type 'Security' and Membership type 'Dynamic…
- Click 'Add dynamic query' > 'Edit' to open the rule syntax box.
- Paste: (device.deviceOSType -eq "AndroidEnterprise") and (device.deviceOwnership…
- Save the rule and the group; wait several minutes for asynchronous evaluation.
- VALIDATE: open the test device, confirm OS/ownership and that it landed in Members;…
0 of 6 done
Step 1. Enrol ONE test corporate Android device first so you can read its real attributes.
Screenshot: Test device enrolled in Intune (captured during a live customer build — coming to this page)
Why: Reading a live device's real deviceOSType and deviceOwnership is the only reliable way to know what the rule must match — guessing the attribute is exactly how a fleet ends up silently untargeted.
Watch for: The attribute a device reports depends on how it enrolled (fully managed and dedicated report differently from BYOD work profile), so the canary must be enrolled the same way as the devices you actually want to catch.
Don’t: Do NOT build the rule from documentation values alone — enrol first, then read the device.
If this step errors: Android Enterprise: work profile vs fully managed vs COPE
Step 2. Go to Intune > Groups > New group; set type 'Security' and Membership type 'Dynamic Device'.
Screenshot: New group blade with Dynamic Device selected (captured during a live customer build — coming to this page)
Why: Only a Security group with 'Dynamic Device' membership can be populated automatically from device attributes; a static or Microsoft 365 group cannot.
Watch for: Membership type defaults to 'Assigned' — you must actively switch it to 'Dynamic Device' before the rule builder appears.
Don’t: Do NOT pick 'Dynamic User' — device attributes such as deviceOSType only exist on device rules and a user rule will never match your hardware.
If this step errors: Autopilot dynamic group lag: apps missing during ESP
Step 3. Click 'Add dynamic query' > 'Edit' to open the rule syntax box.
Screenshot: Dynamic rule syntax editor (captured during a live customer build — coming to this page)
Why: The raw-syntax 'Edit' box takes the exact attribute expression, which is more dependable than picking attributes by hand in the visual builder.
Step 4. Paste: (device.deviceOSType -eq "AndroidEnterprise") and (device.deviceOwnership -eq "Company").
(device.deviceOSType -eq "AndroidEnterprise") and (device.deviceOwnership -eq "Company")Screenshot: Membership rule pasted in the editor (captured during a live customer build — coming to this page)
Why: deviceOSType 'AndroidEnterprise' targets corporate-owned fully managed and dedicated devices, while the deviceOwnership 'Company' clause keeps personal devices out of a corporate-only group.
Watch for: 'AndroidEnterprise' catches fully managed and dedicated but NOT BYOD work profile, which reports as 'AndroidForWork' — this is the single biggest trap in the whole guide.
Don’t: Do NOT trust the expected strings over the observed ones — paste the exact values your canary reported in step 1, not the values you assume.
Step 5. Save the rule and the group; wait several minutes for asynchronous evaluation.
Screenshot: Group created, evaluation pending (captured during a live customer build — coming to this page)
Why: Dynamic membership is worked out by a background Entra process, not the moment you click Save, so the group is legitimately empty until that pass runs.
Watch for: On a busy tenant the first evaluation can take well over 'several minutes'; an empty Members list immediately after saving is normal, not a broken rule.
Don’t: Do NOT keep re-saving or re-editing the rule because it looks empty — each change just restarts the wait.
Step 6. VALIDATE: open the test device, confirm OS/ownership and that it landed in Members; if corporate devices are missed, check for a different deviceOSType and widen with -startsWith "Android" plus an ownership filter.
Screenshot: Group > Members with the test device; device Overview showing OS = Android (Enterprise) and Ownership = Corporate (captured during a live customer build — coming to this page)
Why: Confirming the canary actually landed in Members proves the rule matches production devices before you hang any apps or policies off the group.
Watch for: If the device is missing, read its real deviceOSType first — BYOD work-profile devices report 'AndroidForWork', which is why widening to -startsWith "Android" is the fix.
Don’t: Do NOT broaden to -startsWith "Android" without keeping the deviceOwnership filter, or you will sweep personal devices into a corporate-only group.
If this step errors: Intune device shows as personal despite corporate identifier
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Android Enterprise: work profile vs fully managed vs COPE — A decision tree for the four Android Enterprise modes — work profile, COPE, fully managed, dedicated — and why switching later means a factory reset.
- Autopilot dynamic group lag: apps missing during ESP — Autopilot devices join dynamic groups minutes to hours late, so the ESP runs before apps are assigned. Why the ZTDId rule lags and how to fix it.
- Intune device shows as personal despite corporate identifier — Windows corporate identifiers only apply at enrolment — devices can still show as personal in Intune. Why it happens, and how to fix ownership properly.
‹ Create an Android Enterprise corporate enrolment profile (QR/token)Enrol a test Android device (fully managed QR + BYOD work profile) ›
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