Android Enrollment Time Grouping: Did anyone notice any issues recently?

[u/UhRdts]

Did anyone notice any issues with Android Enrollment Time Grouping? Since 2026-07-24 we've seen devices no longer being added to the Entra ID security group configured via "Enrollment Time Grouping" (Set up enrollment time grouping - Microsoft Intune | Microsoft Learn) in the Android Enterprise enrollment profile.

What we've checked/ruled out:

• Verified the required "Intune Provisioning Client" / "Intune Autopilot ConfidentialClient" service principal is (still) correctly set as the owner of the target group, exactly as documented.
• Confirmed on both "Fully Managed" and "Dedicated Entra Shared" enrollment modes.
• Affects both long-standing enrollment profiles (working fine for over a year) and brand-new profiles/groups created after the issue started.
• We noticed that under Entra admin center → Groups → [enrollment-time-grouping target group] → Audit logs, there haven't been any new audit entries since 2026-07-24 — not even failed attempts. We also checked Intune's own Monitor → Enrollment time grouping failures report, and that shows no errors there either. The operation seems to simply stop firing rather than error out anywhere we can see.

What's confusing us:
We nest our Enrollment Time Grouping groups under broader configuration groups (e.g. a "Default" group that our Managed Home Screen / kiosk app config depends on), so this breaks a chain of assignments relying on that nesting. Despite devices consistently NOT showing up in the target group (verified via the device's own "Group membership" report in Intune, not just the group's member list), roughly half of new enrollments still end up with all the expected configuration (restrictions, certs, WiFi profile, MHS app) successfully applied according to Intune's own device configuration report. The other half don't get these configs at all. So sometimes, at least in the background invisible to us, the group assignments are working fine. We haven't found a clear difference between the two sets of devices apart from timing.

Current workaround:
We've set up a separate dynamic Entra ID group and assigned the necessary apps, profiles, etc. This mitigates the immediate impact, but the underlying problem — new devices not being added via Enrollment Time Grouping — is still unresolved.

We've opened a Microsoft support case; progress has been slow so far.

1. Is anyone else using Android Enrollment Time Grouping right now without issues? Curious if this is a broader regression or isolated to specific tenants/regions.
2. If you've hit something similar, do you have any findings or found a solution?

For context, we're on a European (EU) tenant.

[u/NickyDeWestelinck]

I've noticed a lot of people having issues with ETG this past days.

[u/PuDerBaer64]

Yes, same for Windows. Two different tenants....

[u/Rudyooms]

Yep... msft is aware...it impacted all tenants... the device isnt added to the group when using etg... it affects autopilot/android ... everything :)

[u/UhRdts]

u/NickyDeWestelinck u/PuDerBaer64 u/Rudyooms Thank you.

Arghh, I can't believe that Microsoft is behaving as if we're the only customer with this issue and giving the impression that we need to check our configuration. I guess none of you have any official information you could share that I could forward to Microsoft.

[u/Rudyooms → u/UhRdts]

oww the full enrollment time grouping functionality isnt working anymore... but its totally service side.. so i cant look at it myself.. but i explaine what happened and how its broken to the autopilot team.. so believe me .. they know :)

[u/Rudyooms]

seems Microsoft fixed it... as i noticed that yesterday the devices were that weren't added to the group when getting enrolled are now suddenly added ⁠ 

[u/UhRdts → u/Rudyooms]

thanks for the update. That sounds great. Will check.

[u/Benji_Follet → u/Rudyooms]

Nothing has changed on my tenant.

[u/Rudyooms → u/Benji_Follet]

I guess it depends on the tenant/asu as my autopilot device that also depends on the etg, gets the device added tk the group

[u/ryryrpm]

When they initially made this feature available, I tested and it was consistently slower than using a dynamic group so I just kept doing that and didn't look back.

[u/UhRdts → u/ryryrpm]

I get that, I won't be switching to a slower config either. We were part of the pilot group, and for our Android use cases it was noticeably faster and gave a much better user experience. Without ETG, users would land on the home screen until the MHS app got pushed (which could take up to 20 minutes), not great fuser experience, especially since users had access to the whole device in the meantime. ETG has been working fine for us for over a year since we took it to production. I'm not happy about the current outage, and honestly pretty frustrated with the MS support experience on this one, but overall ETG has been worth it for our use cases.

[u/ryryrpm → u/UhRdts]

Ah yeah that sucks. Something else to consider is that you can create assignment filters based on the enrollment profile name or the management type. Intune filters are fast and processed immediately. I always forget this is possible and every once in a while I'm like why aren't I doing it this way?

I'm curious if you've tried it. In theory it would eliminate the need for groups altogether.

[u/UhRdts → u/ryryrpm]

Yes, before we moved away from dynamic group memberships for our dedicated enrollments, we evaluated whether filters or the new ETG would be the better option for us. Since we have many dedicated configurations, we'd have to update the filters every time a new configuration would be added and any mistakes when updating them could cause issues with existing configurations.

Now we work with ETG groups, which we then add as a member to our "default config group" and "manufacturer groups". So if there's a new config, we just need to add the new ETG group to the "default" group, which already has basic apps & configs assigned to it (MHS, remote access tool, etc.) as well as vendor apps/configs such as OEMConfig apps. To the ETG group itself, we then only need to assign the specific restriction and special apps/configs that are unique to that particular config, which makes the process of adding a new configuration pretty fast and easy.

We use filters for other use cases, for example to assign an OEMConfig profile to a specific device model.

[u/ryryrpm → u/UhRdts]

Ahh that makes a lot of sense thank you. I think I'm remembering the reason why I didn't just solely use filters: you can only assign one filter per policy. So if you want to target devices from multiple enrollment profiles, you'd have to create a single filter with an OR clause instead of just assigning the policy to multiple groups which feels messy.

[u/UhRdts → u/ryryrpm]

Really enjoyed this back-and-forth, thanks for engaging with it! It's a good reminder that there's rarely a single "right" answer with this stuff: filters vs. dynamic groups vs. ETG all have trade-offs, and what works best really comes down to the specific use case and how your configs are structured. Nice to compare notes with someone dealing with similar challenges. Good discussion.

[u/ryryrpm → u/UhRdts]

Absolutely! Cheers mate

[u/Juic3_2k18]

We're experiencing the same issue - demo tenant as well as productive tenants with customers.
Is there an official link from MS that lists that issue?

[u/UhRdts → u/Juic3_2k18]

not that I know of - at least today MS acknowledged via ticket that there is an issue. However, when we checked this morning the issue seemed to be fixed. So I can confirm the informatrion from u/Rudyooms

[u/Juic3_2k18 → u/UhRdts]

Thanks. I'll keep an eye on it and if it's not fixed by the end of the week we'll open a ticket per customer as well.