Intune Android Enterprise Fully Managed Devices

Microsoft have recently announced the public preview release for the initial support of the Fully Managed Device solution set within Intune, I thought that for a change I would write up a little something on this 😁

As a recap, this is now the 3rd solution set to be supported, to see how the different solutions are applicable for different use case scenarios I would recommend as a refresher to take a look at my previous post on Intune and Android Enterprise

Now just to be clear, at the time of writing, this is what is currently supported along with the caveat  of the public preview tag;

• App config and deployment
• Device restriction config profiles
• Deployment of the above config to user groups only

Now this doesn't sound a lot to get excited about but actually the device restrictions are the same  settings as what has been available for the dedicated device solution set which has matured over the past 6 months. So there are ample options to get started with a small test group of users, also I am sure you will see support for more features in the coming months.

Now at this point I would like explain a term you will see within the Intune portal associated to creating config with AE devices, Device Owner. 

On an Android device, the App that applies policies to the device is called the Device Policy Controller. When the DPC is operating in a way that it has control over the whole device, this is called Device Owner. It now kind of makes sense that the same device restrictions are available for both Fully Managed and Dedicated, one would assume the same group of settings for Fully Managed with Work Profile / COPE

The term "Work Profile Only" in the screenshot above I believe is actually incorrect and should be changed to "Profile Owner Only". This the correct term for when the DPC is operating in a mode which only controls the Work Profile and has limited access to the remainder of the device.

Okay so lets give this a whirl along with deploying some additional config to the device

Navigate in the M365 Device Management Portal to Device Enrollment > Android Enrollment > Corporate owned, fully managed user devices (Preview)

Select yes

Now remembering at the moment we can only scope configurations to users, let's create a user group, navigate to Groups > New Group

Populate using the below information, also ensuring that the group has the appropriate users added to it

Click create

Now lets provision two apps so we deploy both an available and required app deployment to the device to observe the experience. Log into the Managed Google Play store, lets find the Outlook and Edge apps. Approve them.

Back in the portal navigate to Client Apps > Managed Google Play and select Sync

The apps with now be available in Client Apps > Apps

Now deploy them by selecting the app, Assignments > Add group > Specify the assignment type (required for one app and available for the other)

Now lets create some devices restrictions config and deploy it to the user group. Device Configuration > Profiles > Create profile.

Input a suitable name, select Android Enterprise for the platform and then select device restrictions under the device owner only menu

Select settings, I have included various settings in this profile but I would just like to highlight the block factory reset option I have selected here

Click on OK then assign the profile to the same group we created previously.

Now lets enrol the device, ensure that it is in a state where it has been recently been factory reset, or is brand new out of the box. I will enrol the device use the QR code reader method, which requires Android 7.0 or newer

Tap on the screen multiple times to reveal the QR code reader setup. Select next

Connect to a Wifi network

Wait for a few seconds and the QR reader will now install

Now its ready to go and scan the QR code from the portal, which we enabled previously

Follow through the wizard and enrolment will commence

Accept the terms

Enrolment will continue

Accept the terms for chrome and then you are prompted for credentials. Enter the username and password.

Click the link when prompted

The device is then enrolled

You will now see the required app install

On launching the Google play store you can see the available app we deployed, so literally the only apps that a user can install on the device are what have been made available by the organisation

You will also notice that there are no apps with the badge symbol on them, like you may have already seen with a Work Profile enrolled device.

Okay so lets check our device config and attempt to factory reset the device

Cool, so the restriction has applied.

Now remember, this feature is in public preview so it is not recommended for production deployments, I would recommend reviewing the documented considerations here

Thanks for reading!

Removing CMG Settings from Configuration Manager

Just a quick post this evening, thought I would take a break from the MD-101 Study, which I am taking the Beta exam for soon. Actually this issue was preventing me being able to create a CMG in my lab so I really needed to get it sorted before continuing.

So I first ran into this issue yesterday when I was trying to remove a CMG from my test lab, I had the following error;

I reached out to one of my cool twitter dudes, Jake Stoker, who is an EM+S warrior, to say that I may need some help and would give him a shout.

I carried out some research first this evening and stumbled across a couple of posts Microsoft MVP Anoop C Nair created on how to Clean up SCCM CMG and Cloud Services from SCCM and then saw Anoop comment at the bottom of the post with a link to FIX – Error SCCM Azure AD Web App Already Exists 

This sounded promising because I had previously experienced the issue described in the title of the second post but it would appear that I had already removed the Azure Service for Cloud Management.

I then noticed that the Server (1) and Client (2) applications were still showing under the actual connection to the Azure tenant 

Okay so maybe I needed to delete the app registrations manually in Azure AD.

Nope still the same issue.

After having a DM conversation on Twitter with Jake again this evening it was established that if there are other Azure Services Configured, like the OMS and Microsoft Store for Business, these also need to be removed, before trying to remove association with the Azure Tenant. (Kind of sounds really basic now doesn't it?) Anyway the additional steps I carried out were as follows

Navigated to Administration > Cloud Services > Azure Services then removed the OMS and MSFB connections one by one

I was then able to remove Azure AD Tenant connection from Config Manager, realising that the Applications within Azure AD could remain in place and in fact, that I didn't need to delete the CMG Server and Client Apps.

This post may help someone, but I actually just wanted to point out why I absolutely love collaborating within the EM+S community, everyone is so helpful. Thanks Jake and Anoop!

Android Enterprise and Intune: An Overview

Last updated: 23/08/21

The purpose of this post is to act as a main point of reference for anyone wanting to understand the Android Enterprise functionality that is supported within Microsoft Intune. It was initially based on a presentation that I gave at the Windows Management User Group in London at the end of October 2018, however the platform is developing all of the time so my aim is to keep this post as up to date as possible. I will also link any appropriate posts I create to provide you further information in specific areas

History

It has always been promoted that the open source Android OS is very flexible which makes it an attractive prospect for use within the Enterprise, it also enables OEM's such as Sony or Samsung to add their own value adds to the OS before shipping it with their devices. This in itself brings its own challenges and has been a contributing factor to the fragmentation we see within the Android space today.
For an EMM  to be able to control things on a device, such as disable the Bluetooth or camera, requires access to Device Management API's. These were traditionally not included within the source code of Android, hence the inclusion of this kind of functionality would not only be at the discretion of the OEM's, but also would mean additional development time for the EMM vendor to support the functionality, if indeed it would at all. This has led to inconsistent behaviour across devices when trying to manage them by an EMM within the enterprise

Device Admin / "Legacy" Android Device Management

Device Admin API's were introduced as far back as Android 2.2 which were originally designed to give certain apps admin privileges on a device. For example facilitating remote wipe when configuring a device to connect to Exchange Active Sync. Other than a few basic settings, on a Non-Samsung device, there was very little available. Samsung on the other hand over the years have developed their Knox API set on top of the Android OS and provide far more management functionality than any other OEM. You only have to look in the Intune console at the "Knox Only" settings that are available and ultimately only applicable to Samsung devices;

 Device Admin is now considered as legacy Android device management with Google deprecating certain functionality in Android 9 with it being removed in Android 10. Microsoft made a statement here which also explains the current stance on this and in addition further considerations are discussed here where there is still some scenarios where Device Admin is currently the only option for managing a device

Android Enterprise

So what does this solution bring to the table? Well in a nutshell, lots. Also I just want to add at this stage from an Intune perspective that Microsoft, even though they are very late (in comparison to other EMM's) to the game in releasing some AE features, they seem to be making some sensible moves. An example being that they have utilised the Android Management API for leveraging native management functionality provided and developed natively by Google. This is applicable to the Fully Managed scenarios. I am going to echo the words of a super cool Android guru I have met called Jason Bayton "This makes me happy"

Solution Sets

Probably the most important thing to understand with AE is there are various ways of managing devices through different "Solution Sets", which address common enterprise scenarios rather than the single way of management we had previously with the "one size fits all" of Device Admin. I will explain what these are;

Personally-Owned Work Profile

This was the first solution set to be supported within Intune and is primarily designed for use in BYOD / Employee owned device scenario. A profile containing apps and company data is deployed to the device

Key points

• The device is not fully managed by Intune
• You cannot carry out a full factory reset / wipe
• Simple to control access to and from the profile - so may be suitable for a company owned use case in some organisations

Dedicated Devices

This solution set is designed for use in kiosk scenarios, both customer facing (e.g. kiosk tablet in a hotel room) and employee facing (e.g. field service management)

Key points

• Not for use in scenarios where users affinity is required (no emails, device isn't assigned to a specific user)
• AKA COSU (Corporate Owned Single Use)

Fully Managed Device

This solution set is designed for managing company owned devices and gives the ability to fully control the device, also the administrator has the option of allowing access to the Public Google Play store. In addition system apps can be enabled on the device at the package level.

Key Points

• To transition to this from company owned devices enrolled with Work Profiles will mean factory resetting the device
• AKA COBO (Corporate Owned Business Only)

Work Profile on Fully Managed Device

This is designed for company owned scenarios where the organisation wants to be able to secure company apps within a profile but have the ability to be able to give the user limited access for personal use. This is not supported within the Android Management API and therefore not available within Intune. Google have announced that as of Android 11 this specific solution set will no longer be supported

Key points

• AKA COPE (Corporate Owned Personally Enabled)
• Not supported in Intune

Corporate-Owned Work Profile

This recently implemented solution set has been back ported to support Android 8 and later and also also designed for scenarios where personal usage is permitted on company owned devices. It is similar to the Work Profile solution other than the provisioning process is different and further control is available within the personal profile of the device

Key points

• Available in public preview for Intune
• Is also a COPE use case
• Intune's iteration of COPE is different to the Work Profile on Fully Managed Device functionality that is available on other MDM platforms

Managed Google Play

Another significant benefit of AE is the integration available with the Managed Google Play store. This prevents the need for a Google account to be created on the device in order to install company apps, in addition it also provides a silent app deployment experience for required deployments. Also managed configs are available which enable provisioned settings to be deployed with apps in order to pre configure them.

Improvements to the way managed Google Play integrates with Intune have now been implemented which facilitate the approval or unapproval of apps within the Managed Google Play Store, directly from the Intune portal.

Zero-Touch Enrolment

The Android Enterprise ZTE program introduces the ability to purchase devices from an approved reseller and the devices are provisioned within the Zero Touch portal, thus facilitating bulk enrolment. It is an equivalent of Apple's Device Enrolment Program. Note that only certain OEM's are supported for this and not Samsung - they have their own equivalent to this called Knox Mobile Enrollment, which is also supported within Intune

OEM Config

OEM Config is now supported within Intune across various platforms and with it brings a whole new concept of Android device configuration. It is a standard that has been developed by the app config community and its is based around the concept of a single app developed by the OEM which is deployed via Managed Google Play. Various device configuration settings are then bundled with the app via the standard app config channels in order to configure the device, bringing new functionality to Intune pretty much as soon as the OEM has released it without the delay for development time usually required.