Working with Enrolment time grouping for Android Enterprise

-

Enrolment time grouping for Android Enterprise is finally here. I had been using it for Autopilot Device Preparation (APDP) and now that it supports Android OS, I wanted to experience it first hand and capture all the caveats or gotchas. For those who are not familiar with the feature, enrolment time grouping was first introduced for Windows OS as part of Autopilot Device Preparation to speed up app and policy provisioning during device enrollment. The feature allows enrolment time grouping when you can add a Microsoft Entra security group in the enrolment profile so that devices are added to the group during enrolment, rather than after. This pre-knowledge of the security group that the device will become member of after enrollment enables Intune to deliver the configurations to the device quickly on enrollment, not only reduces post-enrolment latency but also improves productivity.

If you don't configure enrolment time grouping, then Microsoft Intune can only determine the apps and policies a device needs after the device is grouped, so devices grouped this way often aren't ready for immediate use. It can take up to 8 hours post enrollment for devices to receive all apps and policies. So it is a no brainer to configure this feature, especially now that the functionality supports cross platform.

Now that we know what enrolment time grouping is, here are some of caveats that I came across during my testing -

1. The not so obvious one is that you end up with a common security group for both Android and Windows devices that are being evaluated under enrolment time grouping. This may not be a big deal from a policy assignment perspective as Intune differentiates between the platform OS before assigning policies. However, can be an issue if the enrolment group is being used for reporting and\or also specific scope tags for let's say Android OS devices only as part of Role Based Access Control (RBAC) configuration in Intune. Although, both of these scenarios can be addressed by creating separate security groups, but still something to be mindful of.
2. The enrolment time grouping is device based so if your organizations uses user based groups for policy assignments, then you may have to re-evaluate this approach. Many of my customers use user based groups with Intune device filters for policy assignments, especially mobile OS to maintain consistency between MDM and MAM scenarios. Obviously, with enrolment time grouping, this approach changes. 
3. As of writing this blog post, Enrolment time grouping does not support staging scenario. It only  supports Android Enterprise fully managed, Android Enterprise corporate-owned work profile and Android Enterprise dedicated.
4. As of writing this blog post, there is no support added for Apple just yet.
5. Lastly, one needs to add Intune first party app in form of service principal Intune Autopilot ConfidentialClient or Intune Provisioning Client as the security group owner. In my case, I had Intune Autopilot ConfidentialClient added in the tenant, and while this is usable, it didn't sit well with me. Intune Autopilot ConfidentialClient doesn't really read well when you are using the same group to enrol devices. Therefore, I decided to delete the service principal and create it from scratch. If you are as finicky as I am, then this is how you can go about it -

I used Azure cloud shell which was already prepped and ready for use in my tenant. However, if you are interested in knowing about the process, then I have covered the steps in one of my earlier blog posts which you can read all about it over here.

Launch the Azure Cloud shell and run the following commands -

1. Install the Microsoft.Graph.Authentication module by running Install-Module Microsoft.Graph.Authentication. If you are prompted to give consent and then type Y to allow the installation. I already had a slightly old version installed, so I ignored the warning message.


2. Install the Microsoft.Graph.Applications module by running Install-Module Microsoft.Graph.Applications. Just as before, if you are prompted to give consent and then type Y to allow the installation. I already had a slightly old version installed, so I ignored the warning message.


3. Connect to Microsoft Entra ID by running Connect-MgGraph -Scopes "Application.ReadWrite.All". If not already authenticated to Microsoft Entra ID, finish the sign in process when prompted to do so. Use the account that has permissions to add service principals.


4. Run Get-MgServicePrincipal -Filter "Appid eq 'f1346770-5b25-470b-88bd-d5744ab7952c'" | Format-List Id, DisplayName, AppId, SignInAudience to list the currently registered service principal.


5. Make a note of the id and run the command Remove-MgServicePrincipal -ServicePrincipalID '0bc9b933-30e8-4a6a-9bb3-9699235eba8d' to remove the service principal.

You can then run the Get-MgServicePrincipal again to confirm whether the service principal has been removed successfully or not.


6. Next step is to re-create the service principal by running New-MgServicePrincipal -AppID f1346770-5b25-470b-88bd-d5744ab7952c. This time, the application display name will be created under the recent & more importantly the correct name of Intune Provisioning Client.😉



Next up is creating the security group for enrolment time grouping itself. Here are the steps -

2. Browse to Groups –> New group
3. Leave Group type to default value as Security.
4. Populate the Group name.
5. Leave membership type as Assigned. Note: This is an important step as we want group to automatically populate through the security group ownership service principal. Post enrolment, you have the option to delete or add device objects manually.
6. Click on No owners selected and add the service principal that we created before. See below -


7. Click on Create to finish creating the group..

The last step is to make sure we assign this group against an enrolment profile in Intune. For all intents and purposes, I assigned the enrolment time grouping security group against a Corporate-owned devices with work profile. To do this, simply follow the steps below -

2. Go to Devices and under Device Onboarding, select Enrolment.
3. Select Android and under Enrolment Profiles, select Corporate-owned devices with work profile. Either create a profile or edit the existing profile. In case of an existing profile, click on edit against Group settings as shown below -


4.  Then select Microsoft Entra Group and click on Select a group and add the enrolment time security group we created earlier.

That's it. Android devices that use this enrolment profile, will automatically get added to the enrolment time grouping security group at the time of the enrolment.




Thanks for reading. Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

-
Image
I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you. There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below. Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more