Last updated: 24/08/21
Welcome to part 2 of this series of posts which are intended on getting you started with managing Android devices using the Android Enterprise capabilities within Microsoft Intune.
Part 3 can be found here and covers the configuration of Personally-owned Work Profile devices
Part 4 can be found here and covers the configuration of Dedicated devices
Part 4 can be found here and covers the configuration of Dedicated devices
Part 5 can be found here and covers the configuration of Fully Managed devices
This series will get you up and running as quickly as possible, therefore if you require further detail and explanation on Android Enterprise please refer to my previous post here which I am ensuring is kept up to date as newer functionality is supported within Intune.
This series will get you up and running as quickly as possible, therefore if you require further detail and explanation on Android Enterprise please refer to my previous post here which I am ensuring is kept up to date as newer functionality is supported within Intune.
This post will talk about the creation of Azure AD (AAD) user and device groups, and provide some recommendations and considerations for your environment.
It must be clear before commencing an implementation to understand if, along with company issued devices, your organisation will support a BYOD policy for Android Enterprise. This is crucial for some decisions that need to be made on the creation of AAD groups and in some cases creates interesting scenarios. An example of which could be that a user has a company issued phone and they wish to enrol their personally owned Android tablet which they are fully entitled to do under their organisations IT policy. Do you wish to deploy a different set of apps between personal devices and company owned? If so then some apps will need to be assigned to devices groups rather than users.
Dynamic AAD Groups can be used for the above which can be created by the following process
Log into the Endpoint Manager admin center and select Groups
It must be clear before commencing an implementation to understand if, along with company issued devices, your organisation will support a BYOD policy for Android Enterprise. This is crucial for some decisions that need to be made on the creation of AAD groups and in some cases creates interesting scenarios. An example of which could be that a user has a company issued phone and they wish to enrol their personally owned Android tablet which they are fully entitled to do under their organisations IT policy. Do you wish to deploy a different set of apps between personal devices and company owned? If so then some apps will need to be assigned to devices groups rather than users.
Dynamic AAD Groups can be used for the above which can be created by the following process
Log into the Endpoint Manager admin center and select Groups
Select New group
Select Security for the group type and select an appropriate name with the Membership type of Dynamic Device
Select Add dynamic query
Use the rule builder to add the following Properties, Operators and Values:
deviceOSType Equals AndroidForWork
And deviceOwnership Equals Personal
Select Save to complete the changes
Note that you can also Edit the rule syntax directly
For convenience, I have added some queries below with which you can use to build some groups for yourself to cover most use cases. The names I have used are just suggestions, however the queries will need to be copied.
Personally-Owned Work Profile Devices
So I am going to start with the most confusing due to the terminology that is being used, which will highlight an important point - this enrolment type can indeed be used in Corporately owned scenarios.
Name: Android_Personally_Owned_Work_Profile_BYOD
Query: (device.deviceOSType -eq "AndroidForWork") and (device.deviceOwnership -eq "Personal")
Name: Android_Personally_Owned_Work_Profile_Corp
Query: (device.deviceOSType -eq "AndroidForWork") and (device.deviceOwnership -eq "Company")
Dedicated and Corporate-Owned Work Profile Devices
These can be created using the rule builder by very simply referencing the enrollmentProfileName property and then the name of the profile that was created back in part 1 of this series
Create as many as you need for each of your enrolment profiles
Fully Managed Devices
Name: Android_Fully_Managed
Query: (device.deviceOSType -eq "AndroidEnterprise") -and (device.enrollmentProfileName -eq null)
Please refer here for the AAD Dynamic Group documentation
The same methodology is valid for the creation of user groups, it may be a requirement to scope some user groups to different departments in order to differentiate app deployments or compliance requirements.
Another useful user query is to create an Intune_Users group
That concludes this post, many thanks for reading!