Exploring Intune ChromeOS support

Till now, you could have only managed ChromeOS devices with Intune loosely using Intune MAM App Protection and Azure AD Conditional Access policy. There was no way of MDM-managing a ChromeOS device with Microsoft Intune.

But the service release 2210 of Microsoft Intune saw ChromeOS popping up as a new platform in our tenants (the feature is in public preview!)

So with this latest development, can Intune finally MDM-manage ChromeOS devices?

The public preview announcement reads below

View company or school-owned devices that run on ChromeOS in the Microsoft Endpoint Manager admin center. Now in public preview, you can establish a connection between the Google Admin console and Microsoft Endpoint Manager admin console. Device information about your ChromeOS endpoints is synced into Intune and viewable in your device inventory list. Basic remote actions, such as restart, wipe, and lost mode are also available in the admin center. 

Essentially what this means is that unlike other platforms like Android, iOS/iPadOS, macOS, Windows, and Linux, you still cannot MDM-enroll a ChromeOS device to Intune natively.

Is that disheartening to you already? Well, we will have to go out and find ourselves what this new development really means.

So are you ready to get your ChromeOS devices inside Microsoft Intune? Let’s get started.

Getting started with Google Workspace

First thing first, if you only have a working Intune subscription (can be part of EMS or M365 licensing, or standalone with other required subscriptions) and want to get (or already have existing) ChromeOS devices for your environment and have them managed, then you will first need to get a Google Workspace subscription.

There are 4 pricing tiers to choose from – Business Starter, Business Standard, Business Plus, and Enterprise. But for the purpose of this blog, I will go with the free 14 days trial.

The sign-up process is rather simple and streamlined. You are asked for your Name, current email, the number of users, and finally, specify a domain name for the workspace.

One thing that I noticed here is when we sign-up for an M365 tenant, we can actually proceed with the default .onmicrosoft.com domain suffix and use that for dev purposes in case we don’t actually have a purchased public domain to use. But for Google Workspace, it seems we cannot create a workspace without having a public domain.

So you can

• either choose the existing domain option for which you will later need to verify the domain (this is also the case with M365 when we later add custom domain(s) to the tenant), or

• go with the new domain option and search for an available domain that you will need to purchase in the process of setting up the workspace.

In my case, I already have a public domain that I use with my M365 tenant as well, so went with the existing domain option.

Next step in the process of workspace creation is creating the first Google Admin user for the workspace. (Similar to the original Global Admin account that we create while signing up for an M365 tenant.)

Post completing the process, you will be asked to sign in using the admin account that you just created. Successful sign-in will take you to the Google Admin console.

Since I created the workspace with an existing domain, I am now asked to verify the domain

Click on PROTECT and you will get a pop-up window like below. All you need to do is click on the I’M READY TO PROTECT MY DOMAIN.

The process of domain verification is about adding a TXT HOST record to the domain DNS records.

In my case, the domain that I used to set up the workspace with (intunewithjoy.in) is hosted with GoDaddy, and the same was identified by the service. The rest of the process of adding the DNS record and verification was well automated. I did not have to do any manual edits to the domain DNS records.

However, when I tried with a domain (joymalya.com) that is hosted with BlueHost, the service could not identify the domain registrar and asked me to manually modify the domain DNS record with the domain host for verification purposes.

Domain verification can take time, sometimes up to 72 hours for the DNS records to be replicated. 

As such once you are done with your part of adding the DNS record, you are free to explore the Google Admin console.

Now, this blog is not intended to explore the Google Admin console, as such, I will not go into a detailed walkthrough of the same.

But the basics still remain the same - your users will need to have an identity within the Google cloud environment and have the required license assigned to them.

In most of our cases, we will already be having an Azure AD environment where we have all our users' accounts. Hence, instead of manually maintaining Google identities for each user which can add a lot of overhead, federating user identities between Google Cloud and Azure AD will be the most logical step forward.

For Azure AD SSO integration with Google Cloud, you can check the Google documentation here and the Microsoft documentation here.

Further, depending on your need/use case/organization structure, you may need to check the automatic licensing behavior in the Google Admin console.

Now that we have our Google Workspace created, it’s time to prepare for ChromeOS device management.

Preparing to manage Chrome OS device from Google Admin console

Before you can start enrolling your Chrome OS devices to the newly created Google Workspace for remote management via Google Admin console, you will need to go through a few more steps.

First in the Google Admin console, when you go to Devices > Chrome > Devices, there will be a Terms of Service (TOS) agreement screen popping up which you need to accept.

Next, you will be asked to sign-up for Chrome Enterprise upgrade for your Google Workspace.

The Google Admin console is like the command center from where you get to manage the different Google services, the enterprise features and policies for your organization. To get access to the Google Admin console, you need to sign up for a Google Workspace subscription. (The 14 days trial that I did in my case!)

But then to enroll Chrome OS devices to your Google Workspace and have them managed remotely from the Google Admin console, you need to sign-up for the Chrome Enterprise Upgrade program (or Chrome Education Upgrade, or Kiosk & Signage Upgrade).

Luckily again, the Chrome Enterprise upgrade can also be availed on a trial of 30 days, so you don’t need to shell out anything to test the scenario!

Clicking on the Start trial button above takes you to the Add a new subscription workflow as below.

Since for my purpose, I am more interested in carrying this out manually, I am happy with the limited 50 licenses. If you are also like me, click on GET STARTED button and the subscription gets added to your Google Workspace instance.

From the Google Admin console, you can navigate to Billing > Subscriptions to check the details of the subscriptions added to the Workspace.

Now that we have created our Google Workspace (and hopefully you have added in your users either creating them manually in the Google Admin console or via the Azure AD SSO federation) and have added in the Chrome Enterprise upgrade subscription that makes the Google Workspace eligible to enroll and manage ChromeOS devices, let us get to the next step that is…

Connecting Intune with your Google Workspace

To connect your Intune tenant to the Google Workspace instance, in the MEM Admin center, navigate to Devices > Chrome OS (preview) > Chrome Enterprise (preview)

Or you can also navigate to Tenant administration > Connectors and tokens > Chrome Enterprise (preview)

From either of the above location, you will get the Connect button which will show you the Client ID and OAuth scopes that will be required to make the connection between Intune and Google Workspace.

You need to be signed in to the MEM Admin center with an account that either has the Intune Service Administrator role assigned to it, or a custom Intune role with Chrome Enterprise update connection settings permission.

There’s a hyperlink in there to sign in to the Google Admin console. Once you are in there, navigate to Security > Access and data control > API Controls and select MANAGE DOMAIN WIDE DELEGATION.

Click on Add new to create the API client for Intune connection.

Copy the ClientID and Oauth scopes value from the MEM Admin center and paste it here.

Post authorization, you should have the Intune API client created in Google Workspace.

Now head back to the MEM Admin center where we left it, and click on Launch Google to connect now button.

You will be prompted for a Google Admin account sign-in. After you authenticate, the connection between your Intune tenant and Google Workspace gets established.

The Google Admin account you use here must have at least Read-only permission to manage Chrome OS devices along with access to Google Workspace Admin SDK Directory API.

If you have ChromeOS devices already enrolled in your Google Workspace prior to establishing this connection, those devices will start to sync into Intune slowly. Sync time varies and depends on the number of ChromeOS devices you have in the Google Admin console.

Monitoring Intune – Google Workspace connection

You can monitor the connection status between Intune and Google Workspace from the MEM Admin center from either

• Devices > Chrome OS (preview) > Chrome Enterprise (preview), or

• Tenant administration > Connectors and tokens > Chrome Enterprise (preview)

Both locations give the exact same view that shows you the below details.

• Status: Shows up as Syncing when devices are still being synced upon initial connection. The status changes to Active when syncing is complete.

• Last check-in: This shows the last time new devices, device details, or remote actions were synced between Microsoft Intune and the Google Admin console.

• Chrome devices synced: This shows the number of ChromeOS devices synced with Intune.

• Connected account: This shows the Google Admin account that’s connected to Microsoft Intune.

Enrolling ChromeOS device to Google Workspace

You can get your ChromeOS devices enrolled in Google Workspace quite easily by following Google’s enrolment procedure guide here.

Enterprise enrollment can only be triggered during initial device setup before any user sign-in. This is because only devices without an owner can be enrolled. Ownership of the device is established either during Enterprise Enrollment (the organization becomes the owner of the device) or during the first user sign-in (in this case this user becomes the owner of the device).

So it starts as usual by powering on your Chromebook device. You get the Welcome screen where you click on Next.

Connect the device to an available network.

Accept the Terms of Service.

The device then quickly performs an update check.

During initial setup, the device also queries the management service to check if it was previously enrolled and if Forced re-enrolment is enabled for the device.

This is set from the Google Admin console under Enrollment & Access section on Devices > Chrome > Settings > Device settings page.

If forced re-enrollment is turned on, device provisioning post wipe action (Powerwash) is a bit different as such a device would automatically re-enroll into your organization, without users having to enter their username and password. Later the user will eventually be asked to sign in which then creates the user profile on the device, doing the user-device association.

If the device is a new device purchased from the retail channel that has never been enrolled (like the one I have) or if the device was previously enrolled and you have wiped the device to set it up again, but forced enrolment is disabled, then the user gets presented with the usual sign-in screen as below.

From the sign-in screen, the way to bring up the Enterprise Enrolment screen can vary from device to device due to the version differences of ChromeOS.

• Usually, the user should see the More options button on the sign-in screen from where the user can bring up the Enterprise enrolment screen. Or,
• In the recent version of ChromeOS, the Enterprise Enrolment option can be found as a button at the bottom of the screen. Or,
• The user can simply press CTRL + ALT + E shortcut on this sign-in screen to bring up Enterprise Enrolment.

The user is prompted for authentication. The account needs to have proper Enrolment permissions assigned.

This is done in the Google Admin console from under the Enrollment controls section on Devices > Chrome > Settings > Users & browsers page.

Post auth, the device continues with the enrolment process.

The enrolment process is pretty quick. It takes just a couple of seconds before the Chromebook completes enrolling to the management service, unlocking Chrome enterprise policies and management capabilities.

The user will again be prompted to sign in. This is to get started with the OS. At this point, the device has become a managed device, as can be seen from the sign-in screen which reflects the management organization name.

Post successful auth, the user is all set to get started working with the Chromebook.

Post enrollment, here is how my HP Chromebook looks in the Google Admin console.

It takes some time for the Intune – Google Workspace sync to happen. In the MEM Admin center, I went to Devices > Chrome OS (preview) > Chrome Enterprise (preview) and clicked on the Refresh button a couple of times before it finally updated to show me the result I was waiting for.

Devices synced from your Google Workspace are viewable from within the MEM Admin center here at Devices > Chrome OS (preview) > Chrome OS devices (preview).

Things that I noticed!

Notice that the Managed by parameter in the above snap for the synced ChromeOS device shows up as Intune. This is somewhat misleading I would say.

ChromeOS devices are enrolled in the Google Workspace and managed from the Google Admin console, and not Microsoft Intune.

Compliance state shows as Not evaluated which is pretty much what I have expected, since, at the time of writing this, we still don’t have the option to create a compliance policy in Intune for the ChromeOS platform. So my best guess at the moment is that probably the device(s) would be subjected to the tenant-wide compliance setting. (?) I don’t know at this point.

You can obviously click on the device to see further details and trigger the 4 available remote actions as made available – Restart, Deprovision, Lost mode, and Wipe.

Strangely the overview section does not show the Primary user and Enrolled by details. However, the Primary user detail is available from within the System info if you drill down further. Refer to below snap.

Performing remote actions on ChromeOS devices from Intune

• Restart: As mentioned, works for kiosks and managed guest session devices only.

• Deprovision: As mentioned, this will not wipe/remove the user profile from the device and the user can actually continue to use the device. However, the device will stop receiving policies, and device-level printers configured from the Google Admin console will be removed. To run this remote action, you need to provide a reason which can be any 4 as shown in the drop-down menu.

• Lost Mode: This lets you enable/disable Lock Mode for lost/stolen device scenarios. The message that you want to be displayed needs to be configured from the Google Admin console.

• Wipe: Provides you with two option which is very similar to what we get for Windows in Intune.
  • Remove user profiles only will only remove the user account data for all user profiles on the device but will keep device data and enrolment policies intact.
  • Factory reset or Powerwash as it is called in ChromeOS world deletes everything and will bring back the device to a completely new state.

Intune ChromeOS support – Time for a reality check?

In reality, this new development does not allow you to MDM-enrol ChromeOS devices to Intune natively. You require Google Workspace to MDM-manage your Chrome OS devices.

The Chrome OS devices will be managed from the Google Admin console and then this new feature of Intune lets you set up the Chrome Enterprise connection to create a binding between your Intune tenant and the Google Workspace instance (only one connection per tenant!) which will cause the Google Workspace managed ChromeOS devices to sync to your Intune tenant, thereby providing you with device inventory info and also allowing you to trigger some remote actions.

Maybe in the future, compliance policy will be added for the purpose of Conditional Access so that you can have your ChromeOS devices evaluated for compliance.

All in all, this sounds pretty similar to what we have with the Intune-JAMF integration for macOS devices. But wherein for macOS, you can also natively have them MDM-enrolled to Intune if you don’t have JAMF, for ChromeOS, sadly that is not the case!

But then, maybe this development was not intended to manage ChromeOS devices natively with Intune, but only to help Intune bolster its position further as the most complete UEM solution in the market.

As an Unified Endpoint Management tool that Intune is, you now do get a “single pane of view” for all the end-user devices across your environment, be it Android, iOS/iPadOS, macOS, Windows, or Linux.

And now you also have Chrome OS joining that list!