Managing Chrome in a serverless school (p1)

Deploying and managing Chrome.

In a series of three posts we’ll examine some of the challenges a school IT admin might face managing elements of the Google ecosystem in a school that has Microsoft Windows... but no servers.

In particular we’ll take a close look at installing and managing the Chrome browser and follow that up by deploying Google File Stream to Windows 10 clients. In the last post we’ll take an early look at the new Managed Browser feature of G Suite and see how this is set to make life a whole lot easier.

To adopt a true serverless strategy that includes Microsoft you need to manage your Windows 10 laptops and desktops using the InTune MDM rather than the Active Directory + GPO + SCCM combination that has been the de-facto standard for the last two decades.

It sure was fun but goodbye and happy retirement.

As we have noted in previous posts schools can access two versions of the management console. InTune for Education simplifies the user interface and streamlines some of the common workflows while Azure InTune exposes all of the working parts. At each stage we’ll point out what's possible in the schools version and when you might need to drop down into Tune ‘classic’.


Deploying Chrome.
This is easiest task and can be managed entirely within InTune for Education console . As we have seen in earlier posts InTune has a native workflow to deploy files in the Microsoft installer format (.msi) and fortunately Google provides the Chrome browser in just such a package.

Therefore the first task to download the Chrome msi installer file from the enterprise site. Once that's done it’s a simple job to work through the wizard.




Navigate to Apps - Desktops apps and + New app.

It’s worth noting that InTune for Education apps deployed in the .msi format are classified as Desktops apps but in Azure InTune the same apps are termed (LOB) Line-Of-Business apps.

The dialog allows you to select the Chrome installer msi file which includes metadata that fills out the app name field. All the other fields are optional. No command line is required for Chrome as InTune imposes a silent install. It’s worth creating and uploading an icon just because it makes Chrome easy to identify in the console and it looks cool. When installing Chrome make sure the “Don’t check version” option is enabled. Enabling means Intune won't try to install an older version of this app if a newer version is already found on the device.



Once accepted the install package is uploaded to the Azure repository and Chrome added to the list of desktop apps available to users or devices. Pretty straightforward.



Once the app is assigned to a user or device group don’t expect it to be available immediately. The installer file is downloaded on a trickle feed and then installed as a background task. So long as you remain patient the process is pretty reliable.


Managing Chrome.
Google admins who manage Chrome in a Windows environment will be familiar with the chrome.admx template file that's used to extend the standard Windows GPO policy set to include the Chrome browser. However when you open up InTune for the first time there's no sign of the Chrome policies in either of the two platforms.

Therefore before you can manage Chrome there is a separate process to ‘ingest’ the chrome.admx template file into inTune. Once Intune has the full listing, each setting has to be individually entered using a fairly arcane format but the end result is that the Chrome controls are pushed out in the same way as the established GPO model.

It’s important to note that this procedure can only be managed through the Azure InTune portal. The InTune for Education console has no visibility of this process at all.

The first step is to download the chrome.admx file from the enterprise support site.

Using Azure InTune open Device Configuration - Policies - Create Profile.




The new profile dialog needs to be filled out as shown below. It’s important that the profile type is set to Custom. Also note that this process is for Window 10 devices only.



The settings section allows you to add a configuration to the profile. Windows 10 custom profiles use Open Mobile Alliance Uniform Resource Identifier (OMA-URI) settings to configure different features. The first one loads the entire chrome.admx template into InTune. Subsequent entries are used to set specific policies within the template.

To import the chrome.admx template select the Add option.



Update the dialog with the values below.



The OMA-URI value is:

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx

Setting the Data type to String presents a list box.  Paste the entire contents of the chrome.admx file into the input field and save the dialog. This action provides InTune with enough information to understand the Chrome policy group but doesn’t set anything - that’s the next task.

Let's take a simple example, Forcing Safe Search.

Within the same policy add a second custom OMA-URI setting.



In this case the OMA-URI value is;

./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/ForceGoogleSafeSearch

with the value set to ;

<enabled/>

Setting each policy requires you to know the appropriate OMA-URI (the registry entry) and the contents of the Value field (the registry setting). Fortunately, Google has provided a sheet and some examples that run through some of the common policies but it’s not a comprehensive list.

What happens if the policy you require is not on the list?

If you look closely each policy has a fixed pattern and with a bit of detective work and using the existing policies as templates you can work them out.

The simple on/off policies are controlled by the value=<enable/> field with the final OMA-URL suffix replaced by the string identifier for the policy. The string identifiers can be found by typing chrome://policy from Chrome or by referencing the Chromium developers site.

It gets a bit tricky when the value field is not simply on/off but requires a data list. A good example is the  PluginsAllowedForUrls which requires a list of URL’s.

In this case the values are separated by the Unicode character 0xF000 which corresponds to the encoded version: &#xF000 which is what you see in the string examples.

Unfortunately two of the most popular Chrome policies are not on the Google list.

Chrome – ADMX – BrowserSignin
Chrome – ADMX – RestrictSigninToPattern

The first policy forces users to sign in and ensures that the Chrome policies and settings are applied on users’ computers. The second limits user logins to organisational accounts.

An amended version of the Google sheet includes these policies and will be extended as other policies are assessed.

In the next post we’ll take a look at using InTune to deploy Google File Stream.

Acknowledgements to Roger Nixon at Wheatley Park School UK for authoring the additional Chrome policies and testing the settings.