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).

Prevent non-administrator users from installing Windows app packages via Windows 10 MDM

This week a short new blog post about a new introduced Windows 10 MDM policy setting, in Windows 10, version 2004, to address new default behavior. That policy setting is related to the installation of Windows app packages. More specifically, that policy setting can be used to prevent non-administrator users from initiating the installation of (signed) Windows app packages. Starting with Windows 10, version 2004, every user – administrator and non-administrator – can initiate the installation of (signed) Windows app packages. On previous versions of Windows 10 that would require the administrator to at least enable the ability to sideload apps (part of the developer settings), for users to be able to initiate the installation of (signed) Windows app packages. This policy setting can be used to return to a situation similar to before, as it enables the administrator to prevent users from initiating the installation of (signed) Windows app packages. That can be the preferred situation for specific groups of users. In this post I’ll quickly go through the setting and requirements, followed by the configuration steps. I’ll end this post by having a look at the end-user experience.

Overview

Let’s start with a quick overview of this specific policy setting. This is an ADMX-backed setting that is available via the AppxPackageManager.admx and this policy setting is used to manage the ability of users to initiate the installation of (signed) Windows app packages. The friendly name of this policy setting is Prevent non-admin users from installing packaged Windows apps and this policy setting is only available in the Windows 10 Business, Enterprise and Education editions.

The policy setting is available in the ApplicationManagement area in the Policy CSP. That’s not a new area, but starting with Windows 10, version 2004, it contains this specific new policy setting. In the table below is an overview of the policy setting and keep in mind that the complete node of this policy setting starts with ./Vendor/MSFT/Policy/Config/ApplicationManagement/.

PolicyDescription
BlockNonAdminUserInstallThis policy setting manages the ability of non-administrator users to install (signed) Windows app packages. When enabled (value: 1), non-administrator users will be unable to initiate the installation of (signed) Windows app packages. Administrator users will still be able to initiate the installation of (signed) Windows app packages in Administrator-context. When disabled (value: 0), or not configured, all users will be able to initiate the installation of (signed) Windows app packages.

Note: This policy does not configure the ability of users to install Windows app packages via the Microsoft Store.

Configuration

When knowing the available policy setting and the possible values, it’s time to take a look at the steps for configuring that specific policy. The nine steps below walk through the configuration of a new custom configuration profile that includes the required OMA-URI and its value. The wizard style of configuring makes sure that the configuration profile will be assigned to the selected users and/or devices.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information (the Platform and Profile type are greyed out and configured based on the provided information on the previous page) and click Next
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/ApplicationManagement/BlockNonAdminUserInstall
  • Data type: Select Integer
  • Value: 1
  1. On the Scope tags page, configure the applicable scopes and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this setting for only the Business, Enterprise and Education edition and the existence of this setting for only the 2004 version and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

Note: At some point in time this configuration will probably become available in the Microsoft Endpoint Manager admin center portal without the requirement of creating a custom device configuration profile with a custom OMA-URI.

End-user experience

Let’s end this post by having a look at the end-user experience. The basic end-user experience when using this policy setting, is the same for every user. When initiating the installation of a (signed) Windows app package by simply double-clicking the file, every user – non-administrator and administrator – will receive the same experience. For an administrator to still be able to install a (signed) Windows app package, the installation should be initiated in an administrator-context (for example: using PowerShell that was started by using Run as Administrator).

To show the end-user experience, I’ve used two different Windows app packages. Below on the left is an example of a trusted app in MSIX-format and below on the right is an example of an offline trusted Microsoft Store app in APPX-format. Both examples simply used to show the behavior of the policy setting. MSIX Hero is actually a really nice and simple tool for managing and troubleshooting MSIX packages and Word Mobile is just a simple APPX package.

Reminder: This policy does not configure the ability of users to install Windows app packages via the Microsoft Store.

More information

For more information about the policy setting to prevent non-administrator from initiating the installation of Windows app packages, refer to the ApplicationManagement policies in the Policy CSP documentation.