Friday, 12 April 2019

Managing Chrome in a serverless school (p2)

Deploying Google File Stream.


Anybody following this sequence of posts and expecting a simple deployment procedure along the lines of the Chrome browser is in for a bit of a surprise.

Unfortunately Intune for Education only recognises three native deployment types (web link, Windows Store item and packaged msi) and Google Drive Stream doesn’t fall into any of those categories so it’s time to roll up your sleeves and log into the Azure InTune portal.

The Azure InTune portal supports a wider range of application types including generic Win32 apps but these need to be converted to a specialised file format (.intunewin) before they can be used. As it turns out converting the Drive Stream executable into a .intunewin file is very straightforward.

The first step is to use the Microsoft Intune Win32 App Packaging Tool to pre-process the Google File Stream executable. The packaging tool wraps the application installation files into the .intunewin format and detects the parameters required by Intune to determine the application installation state.

Although this post references File Stream the process is much the same for any .exe installer.

Download the packaging tool and extract the executable (IntuneWinAppUtil.exe) onto a local subdirectory  - C:\Intune for example.

Download and copy the Google File stream exe installer file into the same directory.

Open a Command Prompt as administrator, navigate to C:\InTune, run IntuneWinAppUtil.exe and provide the following information when requested.

Please specify the source folder: C:\InTune
Please specify the setup file: googledrivefilestream.exe
Please specify the output folder: C:\InTune

Once the process is complete a file named googledrivefilestream.intunewin is created alongside the original file. This is your new “InTune friendly” install package for File Stream.

In Azure InTune navigate to Client Apps - Apps  - Add.



From the App Type dropdown select Windows app (Win32).



In the next section select the googledrivefilestream.intunewin file you have just created. In the App Information section fill out the relevant fields. Load up a logo file, it has no purpose but it looks nice in the console.


The Program section requires an install and uninstall command. Fortunately these are listed on the Google support site.

GoogleDriveFSSetup --silent --desktop_shortcut

%PROGRAMFILES%\Google\Drive File Stream\<VERSION>\uninstall.exe --silent --force_stop


In the requirements section check in both 16 bit and 32 bit operating system architectures and a minimum OS version of 1607 or whatever suits your deployment plan.



The detection rule is the only tricky thing left. This is the logic that InTune uses to determine if the software is installed. In this case we’ll look for a registry entry.

Select Rule Format - Manually Configure... and then Add.

Rule Type: Registry

Key Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{6BBAE539-2232-434A-A4E5-9A33560C6283}

Value Name: <blank>

Detection Method: Key Exists



The Tag section is not required. Select Save when complete and the installer file will be uploaded and the application prepared for deployment.




This normally takes a few minutes after which Google File Stream will be presented in the list of applications (type Win32) to be allocated in the same manner as the other apps.



It's important to realise that this process can only be managed using Azure InTune. Even after the app is created don’t expect it to appear within the InTune for Education portal.

In the next post we'll take a look at the new Chrome Managed Browser feature in G Suite and explain why things are about to get a whole lot easier for the serverless school.

Acknowledgements to Roger Nixon at Wheatley Park School UK for working through this example.

Tuesday, 9 April 2019

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.