Customizing the Microsoft Intune Company Portal app and website

This week is all about customizing the Microsoft Intune Company Portal app and website. The main trigger for this subject are the recently introduced additional customization options. Besides configuring default branding and support information, the list of actual specific customization configurations is growing and providing more and more options for an organization specific look-and-feel. That includes the option for creating multiple different customization policies. In this post I’ll go through the different customization options and policies. I’ll end this post by having a quick look at the end-user experience.

Company Portal app and website customization options

Now let’s have a look at the Company Portal app and website customization options. To do that, I want to walk through the different customization options and explain the usage. Let’s start with the following steps for editting or creating a customization policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Tenant administration > Customization to open the Tenant admin | Customization page
  2. On the Tenant admin | Customization page, click Edit to edit the Default Policy or click Create to create a new custom policy

Editting the Default Policy will provide the administrator with all the available settings as I’m going through below, while creating a new customization policy will provide the administrator with the Create customization policy wizard that doesn’t contain the Hide features section mentioned below. Either way, the customization options are divided into three categories: 1) Branding customization, 2) Support information customization and 3) Configuration customization.

Branding customization

The first category contains the Branding customization, which enables the administrator to configure customizations related to the branding that is shown to the user via the Company Portal app and website. Below, in Figure 1, is an overview of the Branding customization options and a short explanation of those customization options is described below that figure.

  • Organization name: The organization name field is used for configuring the name of the organization and is limited to 40 characters. The organization name can be displayed in the Company Portal app and website.
  • Color: The color selection is used for configuring a Standard color, which provides the selection of five standard colors, or a Custom color, which provides the option to configure a custom color code.
  • Theme color: The the color field changes based on the initial color selection. The configured theme color is shown in the Company Portal app and website. This can be any color and the text color is automatically adjusted to the selected color.
  • Show in header: The show in header selection is used for configuring the header of the Company Portal app and webiste. The options are self-explaining: the Organization logo and name, the Organization logo only, or the Organization name only.
  • Upload logo: The upload logo field comes in different variations (not shown in Figure 1) and is used to upload a custom logo. That logo can be displayed displayed in the Company Portal app and website.

Support information customization

The second category contains the Support information customization, which enables the administrator to configure customizations related to the support information that is shown to the user via the Company Portal app and website. The information will be displayed on the contact pages in the end-user experience. Below, in Figure 2, is an overview of the Support information customization options and a short explanation of those customization options is described below that figure.

  • Contact name: The contact name field is used for configuring the name of the support contact for users in the Company Portal app and website. The name is limited to 40 characters.
  • Phone number: The phone number field is used for configuring the number of the support contact for users in the Company Portal app and website. The number is limited to 20 characters.
  • Email address: The email address field is used for configuring the email of the support contact for users in the Company Portal app and website. The address is limited to 40 characters.
  • Website name: The website name field is used for configuring the friendly name of the support website in the Company Portal app and website. The name is limited to 40 characters.
  • Website URL: The website URL field is used for configuring the URL of the support website in the Company Portal app and website. The URL is limited to 150 characters.
  • Additional information: The additional information field is used for providing additional support-related information for the users in the Company Portal app and website. The information is limited to 120 characters.

Configuration customization

The third category contains the Configuration customization, which enables the administrator to configure multiple customizations related to the available configuration options via the Company Portal app and website. The Configuration customization options actually change the options and the behavior provided to the user and are divided into five sections: 1) the Enrollment section, 2) the Privacy section, 3) the Device ownership notification section, 4) the App Sources section and 5) the Hide features section.

Enrollment section

The first section contains the Enrollment customization options, which enables the administrator to configure customizations related to the enrollment experience that will be provided to the user via the Company Portal app. Below, in Figure 3, is an overview of the Enrollment customization options and a short explanation of those customization options is described below that figure.

  • Device enrollment: The device enrollment selection is used for specifying if and how users should be prompted in the Company Portal app to enroll their iOS/iPadOS and Android devices. The options are: Available, with prompts, which will prompt the user to enroll the device; Available, no prompts, which will provide the option to enroll the device but will not prompt the user and Unavailable, which will not enable the user to enroll the device.

Privacy section

The second section contains the Privacy customization options, which enables the administrator to configure customizations related to the privacy statement and messages that will be shown to the user via the Company Portal app. Below, in Figure 4, is an overview of the Privacy customization options and a short explanation of those customization options is described below that figure.

  • Privacy statement URL: The privacy statement URL field is used for configuring the URL that links to the privacy statement of the organization in the Company Portal app and website. This URL is limited to 79 characters.
  • Privacy message in Company Portal for iOS/iPadOS: The privacy message selection is used for configuring the privacy message that is shown in the Company Portal app on iOS/iPadOS devices. That can be used to inform the user about what the organization can and cannot see on the device of the user. The options are to use the Default or a Custom message and when using a custom message that message is limited to 520 characters.

Device ownership notification section

The third section contains the Device ownership notification customization options, which enables the administrator to configure customizations related to the push notifications about the device ownership changes that will be automatically sent to the user via the Company Portal app. Below, in Figure 5, is an overview of the Device ownership notification customization options and a short explanation of those customization options is described below that figure.

  • Send a push notification to users when their device ownership type changes from personal to corporate (Android and iOS/iPadOS only): The send push notification selection is used to select whether a push notification should be send to the Company Portal app on Android and iOS/iPadOS devices after changing the device ownership from personal to corporate. The options are Yes or No.

App Sources section

The fourth section contains the App Sources customization options, which enables the administrator to configure customizations related to the additional app sources that will be shown in the Company Portal app and website (currently website only). Below, in Figure 6, is an overview of the App Sources customization options and a short explanation of those customization options is described below that figure.

  • Azure AD Enterprise Applications: The Azure AD enterprise applications selection is used to select whether Azure AD enterprise applications should be shown in the Company Portal app and website (currently website only). The options are Hide and Show.
  • Office Online Applications: The Office online applications selection is used to select whether Office online applications should be shown in the Company Portal app and website (currently website online). The options are Hide and Show.

Hide features section

The fifith section contains the Hide features customization options, which enables the administrator to configure customizations related to the available self-service actions on devices that users can perform via the Company Portal app and website. Below, in Figure 7, is an overview of the Hide features customization options and a short explanation of those customization options is described below that figure.

  • Hide remove button on corporate Windows devices: The hide remove button checkbox is used to select whether the remove button is hidden in the Company Portal app and website for corporate Windows devices.
  • Hide reset button on corporate Windows devices: The hide reset button checkbox is used to select whether the reset button is hidden in the Company Portal app and website for corporate Windows devices.
  • Hide remove button on corporate iOS/iPadOS devices: The hide remove button checkbox is used to select whether the remove button is hidden in the Company Portal app and website for corporate iOS/iPadOS devices.
  • Hide reset button on corporate iOS/iPadOS devices: The hide reset button checkbox is used to select whether the reset button is hidden in the Company Portal app and website for corporate iOS/iPadOS devices.

Company Portal app and website experience

Now let’s end this post by having a look at the end-user experience. I’m not going to show all the branding, support information and configuration customizations, but just a few that really standout. Below, in Figure 8, is a side-by-side of the Company Portal website on the left and the Company Portal app on the right. Both show the same look-and-feel. A few detail that can be spotted are:

  • The branding theme color
  • The branding header of organization logo and name
  • The configuration app sources of Office online apps
  • The configuration hide features of Windows devices

More information

For more information about configuring the Microsoft Intune Company Portal app and website, refer to this article about customizing the Intune Company Portal apps, Company Portal website, and Intune app

Installing applications by using Windows Package Manager

This week is all about installing applications via Microsoft Intune by using Windows Package Manager. A few years ago I wrote a post about something similar by using Chocolatey. That time the idea was to simply leverage the PowerShell script functionality that was just introduced. This time the idea is to leverage the Win32 app functionality together with the Windows Package Manager that is just introduced. Leveraging the Win32 app functionality provides me with a few advantages above simply leveraging the PowerShell script functionality. In my opinion the main advantages are the flexibility of the Win32 app model (think about requirements, detection rules, dependencies and notifications) and the ability to use Win32 apps during the Enrollment Status Page (ESP). Creating the Win32 app would cost a little bit more work, but comes with big rewards. In this post I’ll start with a short introduction about Windows Package Manager, followed by the actions and steps for creating a Win32 app that will use Windows Package Manager to install Microsoft PowerToys (as an example app). I’ll end this post by having a look at the end-user experience.

Introduction to Windows Package Manager

Let’s start with a short introduction to Windows Package Manager. Windows Package Manager is a package manager, like any other package manager. It basically provides an administrator (or actually any user with administrative rights) with a set of software tools that help with automating the process of getting apps on a device. The administrator (or user with administrative rights) can specify which apps should be installed, and the package manager does the work of finding the latest version (or a specifically specified version) and installing it on a device. That provides a streamlined experience for installing, updating and uninstalling apps. However, at this moment Windows Package Manager is in its early stages. That means that it doesn’t provide all the expected functionality yet. At the moment of writing this post, Windows Package Manager only provides installation functionality.

Using Windows Package Manager

Now let’s have a look at how we can use Windows Package Manager, in its current shape, in combination with Microsoft Intune. Similar to any other package manager, Windows Package Manager provides a nice repository with apps that can be deployed to devices in an automated way. My suggestion is to use three steps for installing apps by using Windows Package Manager with Microsoft Intune: 1) create a small PowerShell script that will trigger Windows Package Manager, 2) wrap the PowerShell script with the Win32 content prep tool and 3) create and assign the Win32 app in Microsoft Intune.

Prerequisites for using Windows Package Manager

Before looking at the actual configuration steps, let’s start by scoping this post a little bit. This post is focussed on using Windows Package Manager and is not focussed on installing Windows Package Manager. I do provide some guidelines of working with this. Especially as I’m using the Win32 app functionality, it provides all the room for adding functionalities and depending installations. For now it’s important to know how to install Windows Package Manager (winget) tool.

Besides that keep in mind that the Windows App Installer is installed per user, which means that the availability of the Windows Package Manager is also per user. That is important to know when installing apps by using Windows Package Manager, as it would require to run in the user context and it would require the user to have administrative permissions to install apps. Also, as mentioned earlier, at this moment creating an update or uninstall for an app requires creativity.

Creating a PowerShell script

Now let’s use Microsoft PowerToys as an example app for using Windows Package Manager. Also, I’m deliberately using a single app, as that provides me with more flexibility for installing other apps and more insights for reporting. The first step is creating a small PowerShell script that will simply use Windows Package Manager for installing Microsoft PowerToys. The following snippet will silently install Microsoft PowerToys, by looking at an exact match of the provided name, and log the installation details to the provided location.

winget install --exact --silent "Microsoft.PowerToys" --log "C:\Windows\Temp\Install-MicrosoftPowerToys.txt"

Note: It’s also possible to use abbreviations of the specified parameters, but I thought that using the full names would provide a more clear example. In this command -e can be used instead of –exact, -h can be used instead of –silent and -o can be used instead of –log.

Using the Win32 content prep tool

The second step is to use the Win32 content prep tool to convert the just created PowerShell script into the .intunewin format. That enables me to upload the .intunewin file into Microsoft Intune and to create a Win32 app of the installation of Microsoft PowerToys. The following three steps walk through the required steps for converting the PowerShell script into the .intunewin format. As the setup file I can simply refer to the PowerShell script.

  1. Download the Microsoft Win32 Content Prep Tool
  2. Create a folder that contains the just created PowerShell script (and potentially an uninstall script)
  3. Open the Windows Terminal by using Run as administrator and run the Microsoft Win32 Content Prep Tool by using a command similar to the following
.\IntuneWinAppUtil.exe -c C:\Temp\PowerToys -s Install-wingetPowerToys.ps1 -o C:\Temp -q

Note: In this command -c is used to specify the source folder, -s is used to specify the setup file, -o is used to specify the output folder and -q is used to run in quiet mode.

Creating and assigning the Win32 app

The third step is to add the .intunewin file of Microsoft PowerToys to Microsoft Intune as a Win32 app. The main reasons for using a Win32 app, are the power of the Win32 app model and the integration with the ESP. The Win32 app model can be used to detect the availability of Windows Package Manager (and eventually configure it as a dependency), or simply verify for the correct version of Windows 10 that contains Windows Package Manager by default. The following seven steps walk through the steps of creating and assigning the Win32 app in Microsoft Intune that will install Microsoft PowerToys by using Windows Package Manager.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > All apps to open the Apps | All apps page
  2. On the Apps | All apps page, click Add to open the Select app type page
  3. On the Select app type page, select Other > Windows app (Win32) and click select to open the Add App wizard
  4. On the App information page, click Select app package file, select the just created .intunewin file, provide at least the following and click Next
  • Name: Provide a valid and unique name for the Microsoft PowerToys app
  • Description: Provide a description for the Microsoft PowerToys app
  • Publisher: Provide a publisher for the Microsoft PowerToys app
  1. On the Program page, provide at least the following information and click Next
  • Install command: Provide an install command similar to the following that will simply call the PowerShell script within the .intunewin file that will be used to install Microsoft PowerToys by using Windows Package Manager (winget) – PowerShell.exe -ExecutionPolicy Bypass -Command .\Install-wingetPowerToys.ps1
  • Uninstall command: Provide an uninstall command similar to the following that will be used to uninstall Microsoft PowerToys. Keep in mind that Windows Package Manager (winget) currently doesn’t support the uninstall of an app, which means that at this moment the uninstall would require some additional custom scripting (not the scope of this post) – PowerShell.exe -ExecutionPolicy Bypass -Command .\Uninstall-wingetPowerToys.ps1
  • Install behavior: Select User as the install behavior to make sure that the installation can actually use Windows Package Manager (winget) for installing Microsoft PowerToys. The App Installer app will make sure that winget is available on the device, but as it’s a Store app (or appxbundle) it will be installed for the user and not for the system.
  1. On the Requirements page, provide at least the following information and click Next
  • Operating system architecture: Select the applicable operating system architectures for the Microsoft PowerToys app
  • Minimum operating system: Select Windows 10 1803 as the operating system for the Microsoft PowerToys app (the minimum operating system for winget is not relevant in this case as it’s Windows 10 1709)
  • Configure additional requirement rules: (Optional) Configure a custom requirement that will detect a specific minimal Windows 10 version that includes Windows Package Manager
  1. On the Detection rules page, provide at least the following information and click Next
  • Rule format: Select Manually configure detection rules
  • Click Add to add a detection rule for the Microsoft PowerToys app that can be similar to the following configuration and click OK
  • Rule type: Select File
  • Path: Type C:\Program Files
  • File or folder: Type PowerToys
  • Detection method: Select File or folder exists
  • Associated with a 32-bit app on 64-bit clients: Select No
  1. On the Dependencies page, configure any required dependencies for the Microsoft PowerToys app or Windows Package Manager (winget), which can also be used to make sure that Windows Package Manager is always automatically installed as a dependency and click Next
  2. On the Scope tags page, configure any required scope tags for the Microsoft PowerToys app and click Next
  3. On the Assignments page, configure the applicable assignments for the Microsoft PowerToys app (make sure to show the default notifications to the end-user) and click Next
  4. On the Review + create page, review the configuration of the Microsoft PowerToys app and click Create

End-user experience

Let’s end this post by looking at the end-user experience (and mentioning the best places to look from an administrator perspective).

The best place to look at for the end-user experience is the action center in Windows. Action center contains all the different notifications, including those that are provided by the Microsoft Intune Management Extension. Those notifications are one of the reason why I like to use a Win32 app, as it provides a very plain and simple interaction with the end-user. As soon as the user receives the required assignment of Microsoft PowerToys, the user will be notified. After that the user will receive notifications when downloading and installing Microsoft PowerToys and when the installation is successfully performed. All of those notifications are shown on the right.

From an administrator perspective, the log files would probably be more interesting. To follow the installation of Microsoft PowerToys, which is started via Windows Package Manager, the administrator can look at the location provided in the winget command (in my case: C:\Windows\Temp\Install-MicrosoftPowerToys.txt). To follow the process of the Win32 app, the administrator can look at the standard log file of the Microsoft Intune Management Extension (IntuneManagementExtension.log).

More information

For more information about the usage and the introduction of the Windows Package Manager and working Win32 apps in Microsoft Intune, refer to the following articles.

Quick tip: Allow access to unlicensed admins

This week a quick extra blog post about a small nice new feature that became available in Microsoft Intune. That feature is the setting to allow access to Microsoft Intune for unlicensed admins. That setting enables an organization to toggle a tenant-wide setting that removes the Intune license requirement for administrators when accessing the Microsoft Endpoint Manager admin console (and Microsoft Graph). Once toggled it can never be reinstated.

The following two steps walk through the process of allowing access to unlicensed admins

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Tenant administrationRoles > Administrator Licensing to open the Intune roles | Administrator Licensing page
  2. On the Intune roles | Administrator Licensing page, click Allow access to unlicensed admins
  3. On the Allow access to unlicensed admins verification window, click Yes

After following these steps all unlicensed administrators have access to Microsoft Intune. To revoke the access of an unlicensed administrator, simply remove their membership of any Intune role.

Configuring eSIM profiles on Windows devices

This week is all about configuring eSIM profiles on Windows 10 devices by using Microsoft Intune. An eSIM is an embedded digital version of a SIM card that enables the user to connect to the mobile network provider, without an actual physical SIM card. It can be programmed to the mobile network provider and data plan of choice. That can provide an Internet connection over a cellular data connection on an eSIM-capable device. Even though the eSIM functionality is available for most platforms, Microsoft Intune currently only supports the configuration of eSIM profiles on Windows 10 devices. In this post I’ll start with a short introduction, followed by the steps to import and assign eSIM profiles. I’ll end this post by having a look at the end-user experience.

Introduction to eSIM profiles

Windows 10 provides programmatical support for provisioning an eSIM profile on the device and Microsoft Intune enables organizations to use that functionality to automatically provision eSIM profiles on the device. Microsoft Intune provides organizations with the capability to import the activation codes that are provided by the mobile network operator. That can be used to configure the related cellular data plans on the eSIM module by deploying those activation codes to the Windows 10 devices. When Intune installs the activation code, the eSIM hardware module uses the data in the activation code to contact the mobile network provider. Once completed, the eSIM profile is downloaded to the device, and configured for cellular activation. To deploy eSIM profiles to the Windows 10 devices by using Microsoft Intune, the following are needed:

  • eSIM capable device – such as the Surface Pro X
  • Windows 10 version 1709 or later that is enrolled and managed by Microsoft Intune
  • Activation codes provided by the mobile operator (more about those later)

Deploying eSIM profiles on Windows devices

The deployment of eSIM profiles by using Microsoft Intune can be divided into three actions. The first action is creating the CSV-file, the second action is importing the CSV-file and the third action is assigning the eSIM profile.

Creating the CSV-file

Let’s start with the first action, which is creating the CSV-file. This is an important step, as the CSV-file as to contain specific information and the CSV-file is not the same on every line. When creating the CSV-file be sure to be familiar with the following

  • The activation codes in the CSV-file are used one time, but can be imported multiple times by using different CSV-files – Importing an activation code multiple times may cause problems when deploying the same activation code to multiple devices.
  • The CSV-file should be specific to a single mobile network operator and the activation codes should be specific to the same billing plan. 
  • The CSV-file can contain a maximum of 1000 activation codes that can be imported.
  • The name of the CSV-file should be unique – Importing a CSV-file with an existing name will cause problems.
  • The structure of the CSV-file must follow the format as described below. 
  1. The name of the CSV-file becomes the cellular Subscription pool name
  2. The first row of the CSV-file contains the URL of the mobile network operator eSIM activation service, also known as the Subscription Manager Data Preparation server (SM-DP+).
  3. The second and all later rows of the CSV-file contains the unique one-time use activation codes that include two values:
    1. First column contains the unique ICCID (the identifier of the SIM chip)
    2. Second column contains the Matching ID (the actual activation code)

Importing the CSV-file (adding the cellular subscription)

The second action is importing the created CSV-file, which will add cellular subscriptions to Microsoft Intune. This can be achieved by simply following the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > eSIM cellular profiles to open the Devices | eSIM cellular profiles (Preview) page
  2. On the Devices | eSIM cellular profiles (Preview) page, click Add to open the Add cellular subscription blade
  3. On the Add cellular subscription blade, browse to the created CSV-file that contains the activation codes and click OK to add them.

Adding cellular subscriptions by using the Graph API can be achieved by using the embeddedSIMActivationCodePools object.

https://graph.microsoft.com/beta/deviceManagement/embeddedSIMActivationCodePools

Assigning the eSIM cellular profile

The third action is assigning the eSIM cellular profile, which will deploy the eSIM profile to the devices. It’s important to know that this should always be a device group. An eSIM profile is only applicable to devices. Once the eSIM profile is assigned to a group of devices, Microsoft Intune randomly distributes the activation codes to members of the group. There isn’t any guarantee which device gets a specific activation code. Also, when a device has another assignments of different eSIM profile, the device will also add an eSIM profile of that assignment. That makes it possible to provision multiple eSIM profiles on a single device. Assigning the eSIM profile to a group of devices can be achieved by following the next three steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > eSIM cellular profiles to open the Devices | eSIM cellular profiles (Preview) page
  2. On the Devices | eSIM cellular profiles (Preview) page, and select the created cellular subscription followed by Assignments to open the {{CellularSubscriptionName}} | Assignments blade
  3. On the {{CellularSubscriptionName}} | Assignments blade, select the required device group and click Save to assign them

Note: Removing a device from the assignment, or deleting the eSIM cellular profile, will trigger Microsoft Intune to remove the eSIM profile from the device.

Assigning the cellular subscriptions by using the Graph API can be achieved by using the assignments object for a specific cellular subscriptions pool.

https://graph.microsoft.com/beta/deviceManagement/embeddedSIMActivationCodePools/{embeddedSIMActivationCodePoolId}/assignments

The eSIM profile experience

Let’s end this post by having a look at the experience for the end-user and the administrator. First the end-user experience. After the device checks-in, receives the eSIM profile and is successfully activated, the user receives the notification that a new eSIM profile is available (as shown in Figure 2). As mentioned in the notification, the user still needs to select the profile to use. To achieve that, the user can click in that notification on Settings > Manage eSIM profiles. That will bring the user to the place to manage the eSIM profiles (as shown in Figure 3). The user can select the applicable profile and click on Use. That will enable the user to actually use the eSIM profile.

The administrator experience is a little bit different from normal policy assignments. The best administrator experience is available by navigating to Devices > eSIM cellular profiles selecting a specific profile and selecting the Device status. That provides an overview as shown below (in Figure 4). The information of the different columns is explained below.

  • Device Name – The name of the assigned device
  • User – The name of the user whom enrolled device
  • ICCID – The unique code provided by the mobile network operator within the activation code installed on the device (this information is also part of the imported CSV-file)
  • Activation Status – The delivery and installation status of the activation code on the device by Microsoft Intune
  • Cellular status – The state provided by the mobile network operator
  • Last Check-In – Date the device last communicated with Intune

More information

For more information about configuring eSIM profiles on Windows devices, refer to this article about configuring eSIM cellular profiles in Intune (public preview).

Using sensitivity labels to manage access to SharePoint sites on unmanaged devices

This week is a follow-up on my post of a few weeks ago about accessing SharePoint and OneDrive content on unmanaged devices. That post showed how to use the SharePoint admin center to manage the organiztion-wide access control for unmanaged devices and showed how to use PowerShell to manage the site-level access control for unmanaged devices. This post will show something similar to that PowerShell configuration, in a way that this will also provide a method for managing access for unmanaged devices on a site-level. The main difference is that this post will look at a new (currently in public preview) feature that is added to sensitivity labels. That feature enables the administrator to configure Site and group settings for sensitivity labels. Within that configuration the administrator can define the level of access for unmanaged devices when a sensitivity label is applied to a SharePoint site. In this post I’l start with a short introduction about that functionality, followed by the configuration steps. Those configuration steps contain the steps for configuring the sensitivity labels, the steps for applying the sensitivity labels to a SharePoint site and the steps for configuring a basic conditional access policy to provide the device management information to SharePoint Online. I’ll end this post by showing the end-user experience.

Important: This information shown in this blog post relies – at the moment of writing – on preview functionality for sensitivity labels that must be specifically enabled. Without specifically enabling this preview functionality, the mentioned Site and group settings will not be available for sensitivity labels.

Site and group settings for sensitivity labels

Before looking at the configuration options, it’s good to first have a quick look at the new feature of sensitivity labels. By enabling the preview functionality, the administrator receives an additional configuration step when creating (and editing) sensitivity labels, named Site and group settings. The main focus for this post is the configuration section for unmanaged devices in the Site and group settings. That configuration section enables the administrator to provide the user with the option to configure access for unmanaged devices per site by using sensitivity labels. The administrator determines the configuration of the sensitivity labels based on the company policies and the user applies the sensitivity label to SharePoint sites based on the company policies.

When applying a sensitivity label to a SharePoint site, only the settings of the Site and group settings apply to the site. Other settings, such as encryption and content marking, aren’t applied to the content within the SharePoint site. The content within the SharePoint site is also not automatically labeled with the sensitivity label that’s applied to the site. It’s currently still required to use the existing manual and automatic options for applying sensitivity labels to content. The the priority of sensitivity labels is also really important for this

Note: I’m constantly specifically mentioning access of unmanaged devices to SharePoint sites as the focus of this post. However, as the mentioned configuration also enables the user to apply these sensitivity labels to Teams sites, the same behavior for unmanaged devices also applies to the related SharePoint sites.

Configuring the sensitivity labels

The configuration of sensitivity labels, for applying the behavior for unmanaged devices to a SharePoint site, contains an administrator configuration for the sensitivity labels and a user configuration for applying the sensitivity label to new (and existing) SharePoint sites. If needed an administrator can also adjust the applied sensitivity label.

Configuring the site and group settings for sensitivity labels

Let’s start by looking at the steps for an administrator of creating a sensitivity label and configuring the Site and group settings. The eight steps below walk through the creation of a new sensitivity label. Most steps simply describe the usage of the configuration step, as the focus is on the Site and group settings (step 6). After creating the sensitivity label, it can be published like any other sensitivity label by using a Label policy. Keep in mind that after creating and publishing the sensitivity label, it can take up to 24 hours for the sensitivity label to become available for users in the creation and adjustments of SharePoint sites. 

  1. Open the Microsoft 365 compliance center and navigate to Solutions > Information protection (or use the Microsoft 365 security center, or the Security & Compliance center) to open the Information protection page.
  2. On the Information protection page, click Create a label to open the New sensitivity label wizard.
  3. On the Name & description page, configure a name and tooltip for the sensitivity label and click Next.
  4. On the Encryption page, configure the encryption to control who can access the content that have this sensitivity label applied and click Next.
  5. On the Content marking page, configure any custom headers, footers, and watermarks that should be added to content that have this sensitivity label applied and click Next.
  6. On the Site and groups settings page, configure the settings that should take effect when this sensitivity label is applied to SharePoint site (or Office group) and click Next. Specifically looking at the scope of this post, it’s all about the Unmanaged devices section. That section enables the administrator to control the level of access for unmanaged devices when this sensitivity label is applied to a SharePoint site. Similar to the unmanaged devices access control in the SharePoint admin center, the administrator can choose between full access, limited access and block access.
  7. On the Auto-labeling for Office apps page, configure the automatic labeling behavior for Office apps when sensitive content is detected and click Next.
  8. On the Review your settings page, verify the configuration and click Submit.

Note: Keep in mind that the organization-wide configuration for unmanaged devices, in the SharePoint admin center, should be set to the least restrictive configuration to have a configuration that works as expected. If not, and a sensitivity label should apply a less restrictive experience, the organization-wide configuration will overrule the applied configuration of the sensitivity label.

Using the sensitivity labels for SharePoint sites

Once the administrator configured the sensitivity labels, the user can apply the different sensitivity labels to the different SharePoint sites. That can be achieved by the user during the creation of new SharePoint sites or by editing the Site information of existing SharePoint sites. The following three to four steps walk through the process of creating a new SharePoint site and applying a sensitivity label to it.

  1. Open SharePoint and click Create site to open the Create site page.
  2. On the Create site page, choose between a Team site and a Communication site. A sensitivity label can be applied to both type of SharePoint sites.
  3. No matter what the type of SharePoint site, provide a name for the site to enable the remaining settings of a new SharePoint site. Those settings include an Advanced settings section. That section contains the sensitivity labels that the user can choose from. By clicking on the help icon, the user can view the tooltip information of the different sensitivity labels. Now choose the applicable sensitivity label and click Next to continue to the Add group members page (or click Finish for Communication sites).
  4. (Only for Team sites) On the Add group members page, add any additional administrators and click Finish.

Note: For existing SharePoint sites the user can select the SharePoint site and click Site information to edit the sensitivity label by selecting a different sensitivity label in the Sensitivity selection box.

Configuring conditional access policy

The conditional access policy configuration is required to make sure that Azure AD will pass the device management information on to SharePoint Online. That can be achieved by using the Use app enforced restrictions session control. That in combination with the configuration of the sensitivity labels can provide the organization with the required level of access control on unmanaged devices. For this post the focus is on the Use app enforced restrictions session control. That session control can be configured by following the next seven steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Security > Conditional access Policies to open the Conditional Access | Policies blade
  2. On the Conditional Access | Policies blade, click New policy to open the New blade
  3. On the New blade and provide a unique name
  4. Select Users and groups to configure the assigned users of this conditional access policy
  5. Select Cloud apps or user actions and select Office 365 SharePoint Online as the assigned app of this conditional access policy
  6. Select Conditions > Client apps and select Browser as the applicable client app of this conditional access policy
  7. Select Session and select Use app enforced restrictions to make sure that the configured limited experience will be applicable to this session

Note: This configuration can also be used in a conditional access policy that uses a grant controls to make sure that for example MFA is also always required for access to SharePoint Online for unmanaged devices. 

The sensitivity label experience

Let’s end this post by having a look at the end-user experience and little bit of administrator experience. For testing the experience, I’ve created the following four different sensitivity labels (with the mentioned behavior for unmanaged devices) for the users in my environment:

  • Public – This sensitivity label allows full access for unmanaged devices.
  • Internal – This sensitivity label allows limited access for unmanaged devices.
  • Confidential – This sensitivity label also allows limited access for unmanaged devices.
  • Secret – This sensitivity label blocks access for unmanaged devices.

When a user now navigates on an unmanaged device to a SharePoint site with a sensitivity label of Internal (or Confidential), the user will receive a limited experience as shown below in Figure 3. The user will be notified about the limited experience and the user will see the applied sensitivity label. When a user now navigates on an unmanaged device to a SharePoint site with a sensitivity label of Secret, the user will receive a blocked experience as shown below in Figure 4. As the sensitivity label of Public simply provides a full experience, I’m not showing that example.

When quickly looking from an administrator perspective in the SharePoint admin center, the administrator can now see an additional column for the active sites that contains the applied sensitivity label (as shown in Figure 5). By selecting a site and navigating to the policies section, the administrator can also adjust the applied sensitivity label.

More information

For more information about managing access to SharePoint sites with sensitivity labels, refer to the article about using sensitivity labels to protect content in Microsoft Teams, Microsoft 365 groups, and SharePoint sites (public preview).

Pushing notifications to users on iOS and Android devices

This week is all about the different options in Microsoft Intune to send push notifications to users on iOS (and iPadOS) and Android devices. The trigger of this post is the option to send push notifications as an action for noncompliance, which was introduced with the 2005 service release of Microsoft Intune. Besides that, it was already possible to send custom notifications to a single device, to the devices of a group of users, or as a bulk action to multiple devices. In this post I want to go through the different options for sending push notifications, followed by showing the end-user experience.

Send custom notifications

Custom notifications can be used to push a notification to the users of managed iOS (including iPadOS) and Android devices. These notifications appear as push notifications from the Company Portal app (or Microsoft Intune app) on the device of the user, just as notifications from other apps. A custom notification message includes a title of 50 characters or fewer and a message body of 500 characters or fewer. Besides those message limitations, the following configurations should be in place for a device to be able to receive push notifications.

  • The device must be MDM enrolled.
  • The device must have the Company Portal app (or Microsoft Intune app).
  • The Company Portal app (or Microsoft Intune app) must be allowed to send push notifications.
  • An Android device depends on the Google Play Services.

Send custom notification to a single device

The method for sending a custom notification to a single device is by using device actions. To use device actions for sending a custom notification to a single device, simply follow the three steps below.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > All devices {{select Android or iOS device} to open the Overview page of the specific device
  2. On the Overview page, select the Send Custom Notification device action (when the option is not available, select the  option first from the upper right side of the page) to open the Send Custom Notification pane
  3. On the Send Custom Notification page, specify the following message details and select Send to send the notification to the device
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to a single device can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices('{IntuneDeviceId}')/sendCustomNotificationToCompanyPortal

Send custom notification to a group of devices

There are actual two methods for sending a custom notification to a group of devices. The first method for sending a custom notification to a group of devices is by using the tenant administration. That can be achieved by using the four steps below. The twist is that those steps will enable the administrator to send a notification to a group, which will only target the users of that group. The notification will then only go to all the iOS (and iPadOS) and Android devices that are enrolled by that user.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Teant administration Custom notifications to open the Tenant admin | Custom notifications blade
  2. On the Basics page, specify the following message details and select Next
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the group that should be used to send this notification to and click Next
  2. On the Review + Create page, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to the devices of a group of users can be achieved by using the sendCustomNotificationToCompanyPortal object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/sendCustomNotificationToCompanyPortal

The second method for sending a custom notification to a group of devices is by using bulk actions. That can be achieved by using the four steps below. Those steps will enable the administrator to send a notification to multiple selected iOS (and iPadOS) and Android devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices All devicesBulk Device Actions to open the Bulk device actions blade
  2. On the Basics page, specify the following details and select Next
  • OS – Select the platform of the devices that should receive this notification (Android (device administrator), Android (Work Profile), or iOS/iPadOS)
  • Action – Send custom notification
  • Title – Specify the title of this notification
  • Body – Specify the message body of the custom notifcation
  1. On the Assignments page, select the devices to send this custom notification to and click Next
  2. On the Review + Create tab, review the information and click Create to send the notification

Note: Microsoft Intune will process the message immediately. The only confirmation that the message was sent, is the notification that the administrator will receive.

For automation purposes, automating pushing a custom notification to multiple selected devices can be achieved by using the executeAction object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/managedDevices/executeAction

Send noncompliance notification

Noncompliance notifications can be used to push a notification to a device about the noncompliance state of the device. These notifications appear as push notifications from the Company Portal app on the device of the user, just as notifications from any other app. The notification is pushed to the device, the first time after the device is noncompliant and checks in with Microsoft Intune (depending on the configured schedule of the push notification). The message of the notification contains the details about the noncompliance and can’t be customized. Also, the notification is only pushed a single time. To push multiple notifications, simply add multiple actions. The four steps below show how to add a noncompliance action that will send a push notification to a compliance policy.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Endpoint security Device compliancePolicies to open the Compliance policies | Policies blade
  2. On the Compliance policies | Policies page, either create a new policy, or edit an existing policy (this example is of editing an existing policy)
  3. On the Actions for noncompliance page, select Send push notification as an additional action
  1. On the Review + save page, click Save

For automation purposes, automating updating a device compliance policy can be achieved by patching the specific deviceCompliancePolicies object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies/{policyId}

End-user experience

Let’s end this post by having a look at the end-user experience. The push notifications will show on the lock screen just as notifications from any other app. Below on the left (Figure 5) is showing an example of the lock screen that contains a custom notification and a noncompliance notification. Below in the middle (Figure 6) is showing an example of a custom notification when the Company Portal app was open. The user will go to the same page in the Company Portal app, when clicking on the custom notification on the lock screen. Below on the right (Figure 7) is showing an example of the page in the Company Portal app, when clicking the noncompliance notification. That will enable the user to immediately take action.

Note: The experience on Android devices is similar. However, keep in mind that on Android devices, other apps might have access to the data in push notifications.

More information

For more information about the different options to send push notifications to users on iOS and Android devices, refer to the following docs:

Configuring the OneDrive sync app basics for Windows devices

This week is all about configuring the OneDrive sync app basics for Windows devices. The main component for accessing OneDrive for Business content on Windows devices, is the OneDrive sync app. By default the OneDrive sync app is available on Windows devices and installed per user. In this post I’ll have a look at the installation of the OneDrive sync app and the basic configuration that I think that should be applied to get the best user experience. All by using Microsoft Intune for managing the Windows devices. I’ll end this post by having a quick look at the configuration on the Windows device.

OneDrive sync app installation

The first thing that should be addressed is the installation of the OneDrive sync app. By default, the OneDrive sync app is available on Windows devices and installs per user. That means that the OneDrive sync app will be installed in the %localappdata% directory, for each user that signs in on the Windows device. That’s not always the most optimal method for addressing the OneDrive sync app installation, as it also often means that during the initial sign in of the user, an update of the OneDrive sync app will be downloaded and installed. To address that, especially on shared and multi-user devices, I like to install the OneDrive sync app with the per-machine installation option. That effectively means that the OneDrive sync app will be installed in the %Program Files% directory (keep in mind that it’s a 32-bit app) and that will make sure that all profiles on the Windows device will use the same OneDrive binaries. Besides the installation location, the behavior of OneDrive is similar.

To make sure that the OneDrive sync app is up-to-date during the initial sign in of to user – to make sure that the different available policies will apply immediately an that conditional access will work – the OneDrive sync app should be up-to-date after provisioning the device. Ideally during the Out-of-the-Box experience (OOBE), with or without using Windows Autopilot. That can be achieved by using a simple PowerShell script, of which an example is shown below.

#Download OneDrive per-machine installer
$downloadLocation = "https://go.microsoft.com/fwlink/?linkid=844652"
$downloadDestination = "$($env:TEMP)\OneDriveSetup.exe"
$webClient = New-Object System.Net.WebClient
$webClient.DownloadFile($downloadLocation, $downloadDestination)

#Run OneDrive per-machine installer
$installProcess = Start-Process $downloadDestination -ArgumentList "/allusers" -WindowStyle Hidden -PassThru
$installProcess.WaitForExit()

That script will download the latest version of OneDriveSetup.exe and will install it with the per-machine installation option. To make sure that it will be installed during the OOBE, wrap it as a Win32 app. As a detection method simply use the installation directory (as the directory will change) of the OneDrive sync app. The reason to go for a Win32 app is simple: a Win32 app will be installed and tracked during the Enrollment Status Page (ESP) and that will make sure that the OneDrive sync app is up-to-date before the user signs in to the Windows device.

Note: For further tuning the initial sign in of the user, have a look at this section of a post by Ben Whitmore.

OneDrive sync app basic configurations

The second thing that should be addressed is the configuration of the OneDrive sync app. The idea of configuring the OneDrive sync app on the Windows device, is to make sure that the user can be productive as fast as possible without any user interaction. The following settings are my preferred configurations that should be performed to achieve that goal. The list also contains some settings to limit potential data loss, which might not apply to all organizations. All of these settings are now available as a part of the Administrative Templates that are available in Microsoft Intune. As these settings are configured via Administrative Templates, the configurations are eventually done by using registry key values (device settings at HKLM\SOFTWARE\Policies\Microsoft\OneDrive and user settings at HCU\SOFTWARE\Policies\Microsoft\OneDrive). To configure Administrative Templates, simply open the Microsoft Endpoint Manager admin center portal, navigate to Device > Configuration profiles and create a new profile.

Silently sign in users to the OneDrive sync client with their Windows credentials – This setting is a must for every organization, as it’s used, on (hybrid) Azure AD joined devices, to set up the OneDrive sync app for the user that signs in on the Windows device.

When using the following configuration, the OneDrive sync app will be automatically (and silently) set up for the user that signs in on the Windows device, without the need for the user to provide credentials. That configuration will set the registry key value SilentAccountConfig to 1.

  • Setting type: Device
  • Setting value: Enabled

Silently move Windows known folders to OneDrive – This setting is strongly advised for every organization, as it’s used to set up the redirection of the known folders (Documents, Pictures, and Desktop) of the user to OneDrive.

When using the following configuration, the known folders will automatically (and silently) redirected to OneDrive without user interaction. Besides that, the user receives a notification after the folders have been successfully redirected. That configuration will set the registry key value KFMSilentOptIn to {{yourTenantId}} and KFMSilentOptInWithNotification to 1.

  • Setting type: Device
  • Setting value: Enabled
  • Tenant ID: {{yourTenantId}}
  • Show notification to users after folders have been redirected: Yes

Prevent users from redirecting their Windows known folders to their PC – This setting is strongly advised for every organization (especially in combination with the previous setting), as it’s used to prevent the user from redirecting the known folders (Documents, Pictures, and Desktop) back to the Windows device.

When using the following configuration, the user is prevented from redirecting the known folders back to the Windows device. It forces users to keep their known folders redirected to OneDrive. That configuration will set the registry key value KFMBlockOptOut to 1.

  • Setting type: Device
  • Setting value: Enabled

Use OneDrive Files On-Demand – This setting is strongly advised for every organization, as it’s used to configure OneDrive Files On-Demand. Files On-Demand will help organizations with saving storage space on the Windows device and minimizes the network impact of the OneDrive sync.

When using the following configuration, Files On-Demand is automatically configured for the user. The user will see online-only files in File Explorer, by default, and de file contents don’t download until a file is opened. That configuration will set the registry key value FilesOnDemandEnabled to 1.

  • Setting type: Device
  • Setting value: Enabled

Set the sync client update ring – This setting is strongly advised for every organization, as it’s used to configure the update ring for the OneDrive sync app. It enables the administrator to choose one of the following update rings.

  • Enterprise: In this ring the user gets new features, bug fixes, and performance improvements last.
  • Production: In this ring the user gets the latest features as they become available. This is the default.
  • Insider: In this ring the user receives builds that let them preview new features coming to OneDrive.

When using the following configuration, the update ring will be configured to the production ring and the OneDrive sync app will get the latest features as they come available. That configuration will set the registry key value GPOSetUpdateRing to 5 (Insider=4, Enterprise=0)

  • Setting type: Device
  • Setting value: Enabled
  • Update ring: Production

Allow syncing OneDrive accounts for only specific organizations – This setting is advised for organizations in specific scenarios, as it’s used to prevent the user from uploading files to other organizations by whitelisting allowed organizations.

When using the following configuration, the user will be prevented from adding an account of a different organization. The user receives an error if they attempt to add an account from an organization that is not whitelisted. When a user is already syncing files from another organization, the files stop syncing. That configuration will set the registry key AllowTenantList with a value of {{yourTenantId}} to {{yourTenantId}}.

  • Setting type: Device
  • Setting value: Enabled
  • Tenant ID: {{yourTenantId}}

Prevent users from syncing personal OneDrive accounts – This setting is advised for organizations in specific scenarios, as it’s used to prevent the user from uploading files to their personal OneDrive account.

When using the following configuration, the user will be prevented from adding a personal OneDrive account. When the user is already syncing files from a personal OneDrive, the files stop syncing. That configuration will set the registry key value of DisablePersonalSync to 1.

  • Setting type: User
  • Setting value: Enabled

End-user experience

Now let’s end this post by having a quick look at the end-user experience after applying these configurations. Let’s start by having a look a the last two settings that can be used to prevent easily “losing” data to personal and other organizational accounts. When the user will try to add a personal account, the user will be provided with a message as shown in Figure 8 (below on the left). When the user will try to add another work account, the user will be provided with a message as shown in Figure 9 (below on the right).

The experience of the other more common OneDrive sync app configurations is shown below in Figure 10. OneDrive is automatically configured (see number 1), the known folders are automatically moved to OneDrive (see number 2), the files are on-demand available (see also number 2) and the user is notified about the successful configurations (see number 3).

From an administrator perspective there are also some interesting registry and file locations to look at. To see that the per-machine installation worked as expected, a OneDrive folder should exist in the %ProgramFiles% directory (keep in mind that it’s a 32-bit app). And to see that the device configurations are applied, the corresponding registry keys should be available in HKLM\SOFTWARE\Policies\Microsoft\OneDrive. The user configurations should be available in HCU\SOFTWARE\Policies\Microsoft\OneDrive.

More information

For more information about configuring OneDrive for Business for Windows devices, refer to the following docs:

Accessing SharePoint and OneDrive content on unmanaged devices

This week is all about accessing SharePoint sites and OneDrive accounts on unmanaged devices. More specifically, limiting access to SharePoint and OneDrive content on unmanaged devices. Configuring (limited) access to SharePoint sites and OneDrive accounts starts by using conditional access. For applying conditional access to SharePoint sites and OneDrive accounts, the Office 365 SharePoint Online cloud app, or the recently introduced Office 365 (preview) cloud app can be used. The first cloud app is applicable to all services that depend on SharePoint Online (including OneDrive and Teams). The second cloud app is applicable to all productivity and collaboration services of Office 365. An all-in-one app. However, both of these cloud apps don’t provide really granularity to only apply specific behavior for accessing specific SharePoint sites, or OneDrive accounts. In this post I’ll focus on the Use app enforced restrictions session control and the options that it provides for differentiating between SharePoint sites and OneDrive accounts. About three years ago, I did a post on the basic configurations options of that sessions control.

The Use app enforced restrictions session control can be used to require Azure AD to pass device information to the SharePoint Online. That enables SharePoint Online to know whether the connection was initiated from a managed device. In this case a managed device is an Intune managed and compliant device, or a hybrid Azure AD joined device. SharePoint Online can use that information to provide a limited experience to unmanaged devices. Adjusting the experience can be achieved by using the Unmanaged devices access control in SharePoint Online. In this post I’ll have a look at the standard and advanced configuration options of that access control (including a brief look at the future). I’ll end by having a look at the end-user experience.

SharePoint unmanaged devices standard configuration

The Unmanaged devices access control in SharePoint Online can be used to provide full or limited access on unmanaged devices. It’s even possible to completely block access on unmanaged devices. Limiting the access on unmanaged devices allows the end-user to remain productive while minimizing the risk of accidental data loss. With limited access, users, on unmanaged devices, will have browser-only access with no ability to download, print, or sync files. It won’t be possible to access content through apps, including the Microsoft Office desktop apps. This does require the use of modern authentication. An additional reason to block legacy authentication.

The Unmanaged devices access control standard configuration is available via the SharePoint admin center. This access control can be configured for the complete organization by following the next two steps.

  1. Open the SharePoint admin center and navigate to Policies > Access control > Unmanaged devices
  2. On the Unmanaged devices blade, select the experience for the end-user on unmanaged device by choosing between full access, limited access and block access.

When configuring the Unmanaged devices access control with a limited or blocked experience, by following the mentioned steps, the Apps that don’t use modern authentication access control will automatically change to blocked. The main reason for that is that those apps can’t enforce a limited or blocked experience. Also, these configuration will automatically create corresponding conditional access policies.

SharePoint unmanaged devices advanced configuration

The advanced configuration options of the Unmanaged devices access control in SharePoint Online are only available via PowerShell. The standard configuration via the SharePoint admin center can only configure the access control organization-wide, while PowerShell enables the administrator to configure the access control on site-level. That includes OneDrive accounts. That enables the administrator to configure a limited or blocked experience for specific SharePoint sites and OneDrive accounts. That can be achieved by using the Set-SPOTenant cmdlet for organization-wide configurations, or by using Set-SPOSite cmdlet for site-level configurations. Those cmdlets contain the ConditionalAccessPolicy parameter that can be used to configure the Unmanaged devices access control. That parameter can be used with one of the following values:

  • AllowFullAccess – This value will make sure that the configuration of Allow full access from desktop apps, mobile apps, and the web is applied to the tenant or site. This is the default configuration and allows full access for unmanaged devices.
  • AllowLimitedAccess – This value will make sure that the configuration of Allow limited, web-only access is applied to the tenant or site. This is the limiting configuration that will only allow web access and doesn’t allow the user to print, download or synchronize for unmanaged devices.
  • BlockAccess – This value will make sure that the configuration of Block access is applied to the tenant or site. This will completely block access for unmanaged devices.
  • ProtectionLevel – This value is a preview feature that can be used for configuring authentication tags.

For configuring the Unmanaged devices access control for specific SharePoint sites or OneDrive accounts, the Set-SPOSite cmdlet can be used in combination with the ConditionalAccessPolicy parameter and the Identity parameter. The latter parameter is used for specifying the specific SharePoint site or OneDrive account. An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess

When using the ConditionalAccessPolicy parameter, it enables the administrator to apply even more restrictions. It enables the administrator to combine the limited access with also removing the ability to edit files and the ability to copy and paste from files. That can be achieved by using the AllowEditing parameter with the value $false (default is $true). An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess -AllowEditing $false

Besides limiting the editing abilities for the user, it’s also possible to further limit the preview functionality. That can be achieved by using the LimitedAccessFileType parameter. That parameter can be used with one of the following values:

  • OfficeOnlineFilesOnly – This value will make sure that users can only preview Office files in the browser. This limiting configuration increases security on unmanaged devices, but may decrease user productivity.
  • WebPreviewableFiles – This value value will make sure that users can preview Office files and other file types (such as PDF files and images) in the browser. This is the default configuration and is optimized for user productivity on unmanaged devices, but offers less security for files that aren’t Office files. 
  • OtherFiles – This value will make sure that users can download files that can’t be previewed (such as .zip and .exe) in the browser. This option offers less security on unmanaged devices.

The LimitedAccessFileType parameter enables the administrator to limit the preview functionality, by using one of the three mentioned values. An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess -AllowEditing $false -LimitedAccessFileType WebPreviewableFiles

Note: Keep in mind that the site-level configuration will only work as expected when it’s more restrictive than the organization-wide configuration.

Conditional access configuration

The conditional access configuration is required to make sure that Azure AD will pass the device information to the SharePoint Online. That can be achieved by using the Use app enforced restrictions session control. This configuration can be used next to other conditional access policy that use grant controls to make sure that for example MFA is also always required for access to SharePoint Online or OneDrive for Business on unmanaged devices. That in combination with the limited configuration can provide the organization with the required level of access control on unmanaged devices. For this post the focus is on the Use app enforced restrictions session control. That session control can be configured by following the next seven steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Security > Conditional access Policies to open the Conditional Access | Policies blade
  2. On the Conditional Access | Policies blade, click New policy to open the New blade
  3. On the New blade and provide a unique name
  4. Select Users and groups to configure the assigned users of this conditional access policy
  5. Select Cloud apps or user actions and select Office 365 SharePoint Online as the assigned app of this conditional access policy
  6. Select Conditions > Client apps and select Browser as the applicable client app of this conditional access policy
  7. Select Session and select Use app enforced restrictions to make sure that the configured limited experience will be applicable to this session

What the future brings

Before having a look at the end-user experience, it might be good to briefly mention that the near future will bring some more possibilities. While writing this post new MFA and other granular policies for SharePoint sites and OneDrive are introduced by using a new user action in conditional access. The Accessing secured app data user action. That user action is already configurable in conditional access by using this url for configuring the conditional access policy. It enables the administrator to configure a few protection levels for data. Those protection levels can be added to SharePoint sites and OneDrive accounts and can be assigned with different conditional access policies. That eventually might provide the administrator with a more granular control over the access to the data in the different locations. Jan Bakker already wrote some more details about that functionality at his blog. More about that subject in the future.

End-user experience

The mentioned configurations enable the administrator to provide different limited experiences to different SharePoint sites and OneDrive accounts. Let’s bring these configurations together to provide a limited experience for accessing OneDrive on unmanaged devices and by blocking access to specific SharePoint sites on unmanaged devices. Below in Figure 3 is an example of the end-user experience when opening a Word document in OneDrive on an unmanaged device, when limited access is configured with web previewable files and no editing options. That will enable the user to only preview the document in the browser. Below in Figure 4 is an example of the end-user experience when opening a TXT-file in OneDrive on an unmanaged device and when the same limited configurations apply. That will block the user from accessing the file.

Below in Figure 5 is an example of the end-user experience when accessing a SharePoint site when that specific site is blocked on unmanaged devices. That will provide the user with the message that the access is denied for untrusted devices, due to organizational policies.

More information

For more information about conditional access, SharePoint Online and OneDrive for Business, refer to the following docs:

Android Enterprise and Microsoft Intune

This week is all about the device management jungle of Android Enterprise. I should have discussed this subject a long time ago, but better late than never. Especially when I’m still seeing many question marks when discussing Android Enterprise. With the release of Android 10.0 coming to the different existing Android devices now, the purpose of this post is to create an overview of the different enterprise deployment scenarios of Android Enterprise, including the Microsoft Intune specific additions, and the different related enrollment methods. Everything focussed on providing a good starting point for managing Android devices. The main trigger is the nearing end of Android device administrator with the release of Android 10.0. Earlier I provided the steps for simplifying the migration of Android device administrator to Android Enterprise work profile management with Microsoft Intune, but that was a specific scenario for migrating away of Android device administrator. That doesn’t answer the question if Android Enterprise work profile management is the best deployment solution for your organization.

With this post I hope to provide a better overview of the different deployment scenarios, the requirements and the enrollment methods. All to make a good start with Android Enterprise. Before I’ll dive into Android Enterprise, I’ll start with a little bit of history about Android device administrator. After going through the Android Enterprise deployment scenarios and enrollment methods, I’ll end with a short note about the (crazy) future. I won’t compare or discuss the different configuration options for the different deployment scenarios, as I think that a deployment scenario should be chosen based on the use case first and not directly based on the available configuration options.

A little bit of history

Let’s start with a little trip down memory lane. A long time ago, with Android 2.2, Google introduced the Device Administration API. That API provided device administration features at a device level and allowed organizations to create security-aware apps with elevated administrative permissions on the device. It would enable organizations to perform some basic actions on the device to manage basic components, like email configurations (including remote wipe) and password policies. However, it also introduced many big challenges. One of those challenges was the limited number of configuration options, without a third-party solution like Samsung Knox, and another one of those challenges was the inconsistent level of control across different manufacturers. The more Android device administrator was used, the bigger the scream became for something new.

And something new came. Starting with Android 5.0 and later, Google started with the introduction of Android Enterprise by introducing the managed device (device owner) and work profile (profile owner) modes to provide enhanced privacy, security, and management capabilities. These modes support the different Android Enterprise deployment scenarios (more about those scenarios later) and can be managed by using the Android Management API. That API can be used to configure different enhanced policy settings for the managed devices and the companion app (Android Device Policy) automatically enforces those policy settings on the device. Microsoft Intune has chosen to rely on the API for managing most of the deployment scenarios.

Now only turning off the old management method is left. Starting with Android 9.0, Google has started with decreasing device administrator support in new Android releases, by starting with deprecating specific settings. These settings are mainly related to the camera and password configurations, and these settings are completely removed starting with Android 10.0. That will prevent organizations from being able to adequately manage Android devices by using Android device administrator. A big trigger to move away from Android device administrator. The advise – when using only Microsoft Intune – is to move to Android Enterprise modes and deployment scenarios with the introduction of Android 10.0. Even better, don’t wait until the introduction of Android 10.0 (but that advise might be a bit late now).

Android Enterprise deployment scenarios

The biggest challenge of the Android Enterprise device management jungle is the number of deployment scenarios. When looking specifically at the combination with Microsoft Intune, there is even an additional deployment scenario on top of the standard Android Enterprise deployment scenarios. Below in Figure 1 is an overview of the currently available Android Enterprise deployment scenarios with Microsoft Intune (picture is taken from the slide deck of session BRK3082 at Microsoft Ignite 2019).

Now let’s have a closer look at these different deployment scenarios and the supportability of Microsoft Intune. I’ll do that by zooming in on the different deployment scenarios as shown in Figure 1.

Android APP managed – Android app protection policies (APP) managed app is the least intrusive method for allowing access to company data on personal devices and still making sure that the data remains safe. Also, this method is not Android Enterprise specific. In this scenario, the app is managed with protection policies that will make sure that the company data remains within the app and these protection policies are only applied once the user signs in with a work account. Also, the protection policies are only applied to the work account and the user is still able to use the same app with a personal account. If needed, the IT administrator can remove company data from within the managed app.

AE Work Profile – Android Enterprise work profile is supported with Android 5.0 and later in Microsoft Intune and is focused on providing access to company data on personal devices by using a profile owner mode. In this scenario, the user enrolls the device and after enrollment a separate work profile is created on the device. This separate profile creates the separation between company data and personal data and can be easily identified by the user. The apps that are part of the work profile are marked with a briefcase icon and the company data is protected and contained within the work profile. If needed, the IT administrator can remove the work profile from the device.

AE Dedicated – Android Enterprise dedicated devices – previously known as corporate-owned, single-use (COSU) devices – are supported with Android 6.0 and later in Microsoft Intune and is focused on providing single purpose company-owned devices by using a device owner mode. This is often used for kiosk-style devices (example: devices used for inventory management in a supermarket). In this scenario, these devices are enrolled and locked down to a limited set of apps and web links, all related to the single purpose of the device. These devices are not associated with any specific user and are also not intended for user specific applications (example: email app). If needed, the IT administrator can remove any (company) data of the device.

AE Fully managed – Android Enterprise fully managed devices – previously known as corporate-owned, business-only devices (COBO) devices – are supported with Android 6.0 and later in Microsoft Intune and is focussed on providing company-owned devices, used by a single user exclusively for work, by using a device owner mode. In this scenario, these devices are enrolled and fully managed by the IT organization. To give the user a personal touch, the IT administrator can allow the user to add a personal account for the installation of apps from the Google Play store. However, the device will remain fully managed and there will be no differentiation between company data and personal data. If needed, the IT administrator can remove all (company) data of the device.

AE Fully managed with work profile – Android Enterprise fully managed devices with work profile – previously known as corporate-owned, personally-enabled (COPE) devices – are not yet available with Microsoft Intune, but are eventually focussed on providing company-owned devices used for work and personal purposes, by using a combination of device owner mode and profile owner mode. In this scenario, the IT organization still manages the entire device, but can differentiate between the strength of the configuration depending on the type of profile (example: a stronger configuration set to the work profile and a lightweight configuration set to the personal profile). That should provide the user with a personal space on the device and that should provide the IT administrator with enough capabilities to protect the company data.

For the management of the company-owned devices, Microsoft Intune relies on the Android Management API and Android Device Policy. That enables Microsoft to be able to quickly introduce new features, when introduced in the API. However, that also creates a dependency on Google to introduce new features via the API. A negative example of that dependency is the time it took before the Android Enterprise fully managed devices with work profile deployment scenario became available via the API. At this moment the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune.

Android Enterprise enrollment methods

Once familiar with the Android Enterprise deployment scenarios, it’s good to get familiar with the Android Enterprise enrollment methods. That will enable the IT administrator to get an Android device in the correct mode (device owner, or profile owner) and the correct deployment scenario. The table below provides and overview of the available enrollment methods for the different deployment scenarios. It also provides some details about a few important properties of the deployment scenarios (based on the information about the deployment scenarios). Those properties are: is a reset required to get started with a deployment scenario and is a user affinity applicable with a deployment scenario.

As the Android Enterprise fully managed devices with work profile deployment scenario is not yet available with Microsoft Intune, the information regarding that deployment scenario is an educated guess, based on the other deployment scenarios. That’s why the information is in grey, as it’s still work in progress. The only thing that I’m sure of is that it would require a new enrollment. There will be no migration path from an Android Enterprise fully managed device to an Android Enterprise fully managed device with work profile. That will require a new enrollment. Keep that in mind with determining an eventual deployment and management strategy.

Deployment scenarioEnrollment methodsReset requiredUser affinity
Android app protection policies managed appManaged appNoNot applicable
Android Enterprise work profile deviceCompany Portal appNoYes
Android Enterprise dedicated deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesNo
Android Enterprise fully managed deviceNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes
Android Enterprise fully managed device with work profileNear Field Communication, Token entry, QR code scanning, or Zero touchYesYes

Now let’s have a closer look at the different enrollment methods and the supportability within Microsoft Intune. I’ll do that by zooming in on the different enrollment methods as mentioned in the table above.

Managed app – Managed app enrollment is not specific to Android Enterprise and is supported with any platform version that is supported by the specific managed app. With this enrollment method, the user downloads and installs an app that is protected with app protection policies – when using a work account – and adds a work account to that app. After signing in it triggers the app protection policies for the work account. Also, keep in mind that the user would need to have the Company Portal app installed as a broker app.

Company Portal app – Company Portal app enrollment is supported with Android 5.0 and later in Microsoft Intune for Android Enterprise deployment scenarios. With this enrollment method, the user downloads and installs the Company Portal app and signs in with a work account. After signing in the user triggers the enrollment process in the Company Portal app.

Near Field Communication – Near Field Communication (NFC) enrollment is supported with Android 6.0 and later in Microsoft Intune and can make the enrollment of a device as simple as tapping the device on a specially formatted NFC tag. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can simply tap the device on the NFC tag. That tap will automatically start the enrollment process.

Token entry – Token entry enrollment is supported with Android 6.0 and later In Microsoft Intune and enables the enrollment of a device by specifying a specific (enrollment) token. With this enrollment method, once the device is reset, or just out-of-the-box, the administrator, or user, walks through the standard setup wizard and once arrived at the Google sign-in screen provides the afw#setup code to trigger the Android Device Policy. That will enable the token entry to actually start the enrollment process.

QR code scanning – QR code scanning enrollment is supported with Android 7.0 and later in Microsoft Intune and enables the enrollment of a device by simply scanning a QR code. With this enrollment method, once the device is reset, or just out-of-the-box, and arrives on the initial Welcome screen, the administrator, or user, can multi-tap the screen to enable scanning of a QR code (on Android 7 and 8 that will first prompt for the installation of a QR code reader app). That QR code will automatically start the enrollment process.

Zero touch – Zero touch enrollment is supported with Android 8.0 and later In Microsoft Intune – only with participating manufacturers – and enables the enrollment of a device automatically. Similar to Apple Business Manager and Windows Autopilot. With this enrollment method, on first boot of the device, it will automatically check to see if an enterprise configuration is assigned. If so, the device initiates the provisioning method and downloads Android Device Policy. That download and installation will automatically start the enrollment process.

Note: Besides these standard Android Enterprise enrollment methods, there are also third-party additions (like Samsung Knox enrollment) that can benefit the enrollment process.

What the future brings

Let’s end with a look at the future and some advise. By now it should be obvious that platforms change. However, when looking at the first early signs of Android 11.0 – and specifically at what Android 11.0 brings to the Android Enterprise fully managed devices with work profile deployment scenario – organizations might wonder if change is always for the better. Just when the deployment scenarios of Android Enterprise get more and more traction, new changes are coming. Google recently announced that it will no longer support a work profile on fully managed devices with Android 11.0. Instead enhancements are made to the work profile, to provide a new enhanced work profile deployment scenario. And Android 11.0 will be a hard cut. Existing work profiles on fully managed devices will need to be migrated (to either a fully managed devices or to this new enhanced work profile) when upgrading to Android 11.0. The main driver for Google is the privacy of the user. Jayson Bayton wrote a great article around this subject. Also, when interested in anything around Android and Android Enterprise, I strongly advise to read more of his articles. It’s a great resource!

This change with Android 11.0 makes the future around the Android Enterprise fully managed devices with work profile deployment scenario, especially from a Microsoft Intune perspective, even more challenging. Even before that deployment scenario is available is available within Microsoft Intune. However, this shouldn’t be a reason for waiting even longer with the migration to Android Enterprise. Make sure to be familiar with the Android management requirements within your organization and built the solution and roadmap around those requirements. Often the lifecycle of the device is a good moment to look at a new method for managing the devices. Especially when looking at the supportability of new Android releases on existing devices. Don’t wait until the last moment and make a plan.

I would like to end by mentioning one last time that my advise is not to manage Android 10.0 with Android device administrator and only Microsoft Intune, as those devices will no longer be able to receive password requirements. To add-on to that, and to make my advise even stronger, make sure to be familiar with the upcoming restrictions to the Company Portal app on Android 10.0 devices managed via Android device administrator (see: Decreasing support for Android device administrator). Determine your own migration while you still can!

More information

For more information regarding Android device administrator and Android Enterprise, refer to the following articles:

Simplifying management of the Google Chrome browser

This week is all about simplifying the management of the Google Chrome browser. I’ve done my fair share of posts about different methods for managing settings for the Google Chrome browser, by using Microsoft Intune, like for example by using ADMX-files or by using PowerShell, but it can be easier. It can also be achieved by using Chrome Browser Cloud Management. Chrome Browser Cloud Management is a cloud-based solution that enables the management of the Google Chrome browser across Windows, Mac and Linux devices. In this post I’ll start with a short introduction about Chrome Browser Cloud Management, followed by the steps to enrol Windows devices by using Microsoft Intune. I’ll end this post by looking at the end-user experience.

Note: Keep in mind that this post is only intended to provide a simple management solution for the Google Chrome browser. Please make your own consideration if this would be added value for your organization.

Introduction to Chrome Browser Cloud Management

Let’s start with a short introduction to Chrome Browser Cloud Management. Chrome Browser Cloud Management provides the IT administrator with a unified managed experience across Windows, Mac and Linux devices via a single cloud-based console. That removes the need to use different management tools for different platforms when managing Google Chrome across the organisation. Besides that, it can even provide benefits when managing a single platform. Even in combination with Microsoft Intune. At this moment, Microsoft Intune can provide some challenges with managing Google Chrome, as it would require the use of either PowerShell scripting or ADMX-files. Both, at this moment, time intensive activities. In that case, using Chrome Browser Cloud Management would add an additional management tool, but would save time in configurations.

Chrome Browser Cloud Management provides a method to enroll Google Chrome browsers by providing an enrollment token to the browser. On Windows devices that can be achieved by applying a simple registry key. Once the Google Chrome browsers are enrolled, the Chrome Browser Cloud Management enables the management over user settings and apps and extensions. Both contain some often used configurations. Below are a couple of examples of often used configurations. Figure 1 shows how to easily configure the Homepage and Page to load on startup setting and Figure 2 shows how to easily add the Windows 10 Accounts extension.

Enroll cloud-managed Google Chrome browsers

Now let’s continue by looking at enrolling Google Chrome browsers. Basically that requires two actions. The first actions is to generate the enrollment token and the second action is to enroll Google Chrome browsers by using the enrollment token.

Action 1: Generate enrollment token

The first action is to generate and enrollment token. That token will be used for enrolling the Google Chrome browsers. The following four steps walk through the process of generating that token.

  1. Open the Google Admin console and navigate to Devices > Chrome management > Managed browsers to open the Managed browsers page
  2. On Managed browsers page, on the right bottom of the screen click on the + button to open the Chrome Browser Cloud Management License Agreement dialog box
  3. On the Chrome Browser Cloud Management License Agreement dialog box, click I ACCEPT to generate an enrollment token and to open the Enrollment token dialog box
  4. On the Enrollment token dialog box, click the copy sign to copy the enrollment token and click DONE.

Note: I’m not downloading the registry file, as I think that it’s easier to deploy the enrollment token by using a PowerShell script.

Action 2: Enroll Google Chrome browsers on Windows devices

The second action is to enroll Google Chrome browsers on Windows devices by using the generated enrollment token. For that purpose I’ve created a small PowerShell script that will be deployed via Microsoft Intune. That means two steps. The first step is to create the PowerShell script and second step is distribute the PowerShell script via Microsoft Intune.

Let’s start with the first step. The following PowerShell script provides a simple example that will create the registry path and key if needed. Simply add the copied enrollment token as the value of the $KeyValue variable.

The second step is to distribute the PowerShell script by using Microsoft Intune. That will make sure that the enrollment token applied to the Windows devices, which will trigger the Google Chrome browser to enroll. The next seven steps walk through the deployment of the PowerShell script.

  1. Open Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows > PowerShell scripts to open the Windows | PowerShell scripts blade
  2. On the Windows | PowerShell scripts blade, click Add to open the Add PowerShell script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the PowerShell script
  • Description: (Optional) Provide a description for the PowerShell script
  1. On the Script settings page, provide the following configuration and click Next
  • Script location: Select the PowerShell script
  • Run the script using the logged on credentials: Select No to run the script in SYSTEM context
  • Enforce script signature check: Select No
  • Run script in 64-bit PowerShell Host: Select Yes
  1. On the Scope tags page, configure any additional scope tags for this PowerShell script and click Next
  2. On the Assignments page, configure the assignment of this PowerShell script and click Next
  3. On the Review + add page, review the settings and click Add

End-user experience

Let’s end this post by having a look at the end-user experience. Below I’ve provided a few examples of the experience for the end-user. Figure 5 provides an overview of the applied registry key and its value and Figure 6 provides an overview of the Google Chrome browser and the applied policies. The latter shows the managed state of the Google Chrome browser and the applied Chrome policies. With those Chrome policies it provides the source of the policy, which is Platform for the cloud management enrollment token configured via Microsoft Intune and Cloud for all policies configured via Chrome Browser Cloud Management, and the policy name and value. The shown Chrome policies – and their results – are the examples provided in the introduction.

Note: An administrator can also look at the enrolled browsers in the Google Admin console by navigating to Devices > Chrome management > Managed browsers.

More information

For more information about cloud-management of the Google Chrome browser, refer to the documentation about Cloud-managed Chrome Browser.