Hello @mila_diaz ,
Since both sets of Android devices share the same Microsoft Entra domain, the domain alone should not be used as the only Dynamic Device Group criterion if different policies need to be applied.
A device should ideally match only one of the groups that has a policy assigned to it. Otherwise, the device may receive both policies, and settings from overlapping policy payloads can conflict.
You can handle this in either of these ways:
1. Use a unique device naming pattern for the new tablets If the new set can be enrolled using a separate QR code that applies a different device name format or prefix, you can use that naming pattern in the Dynamic Device Group criteria.
For example:
- Existing group: Entra domain matches “<domain>” and device name does not match the new naming pattern.
- New group: Entra domain matches “<domain>” and device name matches the new naming pattern. This keeps both groups dynamic while preventing overlap.
2. Use a Custom Device Group for manual assignment If there is no reliable attribute to distinguish the devices dynamically, place the required devices in a Custom Device Group after enrollment and associate the second policy with that group.
The important part is to update the original Dynamic Device Group as well. If the original group only checks for the Microsoft Entra domain, the newly enrolled tablets may still be added to it. Add an exclusion for the new device name pattern in the existing group criteria.
Then create or update the second group to include the new device name pattern. After that, associate the appropriate policy with each group.
Regards,
Simon Scott
Hexnode UEM