Quick tip: Easy method for constructing settings of ingested ADMX-files

This week a quick extra blog post, just before the start of my vacation, about an easy method for construction settings of ingested ADMX-files. A few years ago I did a post about a deep dive for ingesting third-party ADMX-files and until today I still receive questions on that post that are related to constructing settings of ingested ADMX-files. Even though the described method is still available, there is an easier method for constructing the settings of ingested ADMX-files. A method that is less sensitive to errors. The following four steps walk through that easy method by again using chrome.admx as an example.

  1. The first step is ingesting the ADMX-file. That can be achieved by following the same steps as provided in my earlier post. After creating the required configuration that contains the content of the ADMX-file, assign the profile to a group with a test device and let Microsoft Intune do its magic.
  1. While Microsoft Intune is performing its magic on the test device, it’s time to start with the second step. The second step is looking up the setting and the available values in the ADMX-file. Just like my earlier post – to keep it simple – I’m looking at the SitePerProcess setting (see Figure 1). Now instead of going through the ADMX-file to construct a difficult OMA-URI, it’s time to have a look at the test device once Microsoft Intune performed its magic.
  1. After Microsoft Intune performed its magic, it’s time to start with the third step. The third step is looking up the setting of the ingested ADMX-file in the registry of the test device. Simply navigate to HKLM\SOFTWARE\Microsoft\PolicyManager\ADMXDefault and locate the just ingested ADMX-file. To make life a little bit easier, knowing to parent category can help. Otherwise, just find and locate the SitePerProcess setting. Once the setting is located, the required part of the OMA-URI is available without doing any really difficult steps (see Figure 2).
  1. The fourth and last step is putting the information together. The OMA-URI of a device-based ingested ADMX-file always starts with ./Device/Vendor/MSFT/Policy/Config. That combined with the information found in the registry of the test device makes ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess.

I know I should have posted these steps earlier, but I still hope that it will still help administrators around the globe with constructing their OMA-URIs for settings of ingested ADMX-files. For as long as it’s still required.

Working with Attack Surface Reduction rules to reduce the attack surface of applications

This week is al about Attack Surface Reduction (ASR) rules. ASR rules are originally introduced as one of the four main features of Windows Defender Exploit Guard. Windows Defender Exploit Guard was introduced as a major update to Microsoft Defender Antivirus, in Windows 10 version 1709, and was the successor of Enhance Mitigation Experience Toolkit (EMET). Nowadays ASR rules are just part of the attack surface reduction controls of Microsoft Defender, but many configuration paths will still refer to Windows Defender Exploit Guard. In this post I’ll have a closer look at configuring ASR rules by using Microsoft Intune. I’ll start with a short introduction about licensing and the different configuration options, followed by the steps for configuring ASR rules and showing the actual configuration. I’ll end this post with showing the end-user experience.

Licensing for the usage of attack surface reduction rules

ASR rules target specific types of behavior that is typically used by malware and malicious apps to infect devices. That includes protection against files and scripts used in Office apps, suspicious scripts, unexpected behavior of apps and more. However, it’s good to keep in mind that the full set of ASR rules is only supported in combination with an Enterprise license for Windows 10. Some ASR rules might work without an Enterprise license, as the Defender\AttackSurfaceReductionRules node of the Policy CSP is also available with a Pro edition, but the usage is not officially supported. Also, keep in mind that Microsoft Defender ATP is not required for the usage of ASR rules. With that, I’m referring to the configuration and the local alerting. When an organization wants more, like for example insights and reporting, Microsoft Defender ATP will be required. Besides the licensing, it’s also good to keep in mind that the usage of Microsoft Defender Antivirus is required in combination with ASR rules.

Introducing the attack surface reduction rules configuration options

When looking at the configuration options for ASR rules, it’s clear that currently many options are available within Microsoft Intune. Depending on the organizations preferences, there will be a method for everyone. Now let’s go through these different options:

  • Endpoint protection configuration profile – An Endpoint protection configuration profile can be used to control the security of Windows devices, including BitLocker and Microsoft Defender. The latter category includes the Microsoft Defender Exploit Guard subcategory, which contains an Attack Surface Reduction subcategory. That subcategory contains nearly all currently available ASR rules. This is also the profile type that the Microsoft Defender ATP documentation is referring to. The challenge with this profile type is that the names of the settings don’t correspond with the recommendations of Microsoft Defender ATP.
  • MDM Security baseline profile – A MDM Security baseline profile can be used to apply pre-configured groups of Windows settings that help organization to configure default values that are recommended by the different relevant security teams. That includes the Microsoft Defender category. That category contains nearly all currently available ASR rules. The names of the settings also correspond to the recommendations of Microsoft Defender ATP.
  • Attack surface reduction rules profile – An Attack surface reduction rules profile can be used to specifically configure settings for attack surface reduction rules that target behaviors that malware and malicious apps typically use to infect computers. Nothing more, nothing less. This category also contains nearly all currently available ASR rules and the names of the settings also correspond to the recommendations of Microsoft Defender ATP. Based on the recent introduction of this profile in the Endpoint security section, this profile might be the future.
  • Custom configuration policy – A Custom configuration profile can be used to configure most of the settings that are available in Windows 10 via Configuration Service Provider (CSP). Nearly all MDM-settings are available via CSPs. That includes the ASR rules that can be configured via the Defender node in Policy CSP. This enables an organization to configure all the available ASR rules that are recommended via Microsoft Defender ATP. It does require a bit more work.

Configuring attack surface reduction rules

When looking at configuring attack surface reduction rules, I’ll show how to do that by using the relatively new Attack surface reduction rules profile that’s available in the Endpoint security section in Microsoft Intune. When that profile doesn’t provide enough configuration options, probably none of the other policies and/or profiles does either. Except creating a Custom configuration policy. For that reason, I’ll also show the required information for creating a custom configuration policy for the attack surface reduction rules. That being said, configuring attack surface reduction rules by using an Attack surface reduction rules profile can be achieved by following the next eight steps.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Endpoint security  > Attack surface reduction to open the Endpoint security | Attack surface reduction blade
  2. On the Endpoint security | Attack surface reduction blade, click Create Profile to open the Create profile wizard
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  4. On the Basics page, provide the following information for the ASR rules profile and click Next
  • Name: Provide a valid name for the Attack surface reduction profile
  • Description: (Optional) Provide a valid description for the Attack surface reduction profile
  • Platform: Windows 10 and later
  1. On the Configuration settings page, configure the required ASR rules and click Next
  2. On the Scope tags page, configure the applicable scopes for the ASR rules profile and click Next
  3. On the Assignments page, configure the assignment for the ASR rules profile and click Next
  4. On the Review + create page, verify the configuration and click Create

Once the configuration is applied on a Windows device, the Event Viewer can be used to see what exactly is applied. The DeviceManagement-Enteprise-Diagnostics-Provide > Admin log provides all the information regarding the applied (mobile) device management configurations. That includes this ASR rules configuration. A successful configuration shows an Event ID 814 about the AttackSurfaceReductionRules policy in the Defender area with a configuration string and an Event ID 814 about the AttackSurfaceReductionRulesOnlyExclusion policy in the Defender area with a configuration string.

In other words, when configuring ASR rules by using a custom configuration profile, the AttackSurfaceReductionRules policy, which is an ADMX-backed policy, can be used. The different required GUIDs are documented here and a GUID can be set to 0 (disable), 1 (block) or 2 (audit). An example of the required information that would configure all the currently available rules is mentioned below.

  • OMA-URI: ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules
  • Data type: String
  • Value: {BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550}=1|{D4F940AB-401B-4EFC-AADC-AD5F3C50688A}=1|{3B576869-A4EC-4529-8536-B80A7769E899}=1|{75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84}=1|{D3E037E1-3EB8-44C8-A917-57927947596D}=1|{5BEB7EFE-FD9A-4556-801D-275E5FFC04CC}=1|{92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B}=1|{01443614-cd74-433a-b99e-2ecdc07bfc25}=1|{c1db55ab-c21a-4637-bb3f-a12568109d35}=1|{9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2}=1|{d1e49aac-8f56-4280-b9ba-993a6d77406c}=1|{b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4}=1|{26190899-1602-49e8-8b27-eb1d0a1ce869}=1|{7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c}=1|{e6db77e5-3df2-4cf1-b95a-636979351e5b}=1

Verifying the configured attack surface reduction rules

Now let’s end this post by verifying the configured ASR rules, by looking at the Event Viewer and the actual end-user experience. For testing purposes the demo scenarios of Microsoft Defender ATP can be used. That contains a specific section for testing the different ASR rules that includes sample files to trigger each of the ASR rules. When the user is performing an action that is not allowed, like running malicious macro code in a Word-document, the user will receive a notification that the action is blocked (as shown with number 1, in Figure 3). Besides the notification to the user, an entry will be logged in the Event Viewer, in the Windows Defender > Operational log, with Event ID 1121 (as shown with number 2, in Figure 3). That event provides information about the blocked action.

More information

For more information about (configuring) attack surface reduction rules, refer to the following documents:

Configuring the usage of Bluetooth encryption via Windows 10 MDM

This week a short blog post about configuring Bluetooth on Windows 10 devices that are managed via Microsoft Intune. More specifically, about configuring the Bluetooth encryption strength that is required for pairing Bluetooth devices. Last year there was a vulnerability regarding the Bluetooth encryption key negotiation that was addressed with an update to Windows and a specific configuration that should be performed to required a specific encryption strength. By default Windows allows all Bluetooth traffic, but with this vulnerability in mind some organizations might want to enforce a minimal encryption key size to be required for Bluetooth traffic. Even if that means that some Bluetooth devices won’t work, or stop working. In this post I’ll start with showing how to configure the Bluetooth encryption key size and I’ll end by showing the applied configuration.

Overview of the Bluetooth configuration options

Let’s start with an overview of the Bluetooth configuration options. Windows 10 already provides multiple configurations options regarding Bluetooth, via the Bluetooth policies in the Policy CSP. Most of these policies are already available via a Device restriction policy in the Cellular and connectivity section. That section contains nearly all available policies, with the exception of the latest policy, the ability to configure the encryption key size. That policy is recently introduced with Windows 10, version 2004, and will probably eventually also end-up in the UI.

That doesn’t mean that we can’t configure the Bluetooth encryption key size at this moment. Like with any available setting within the Policy CSP, it’s always possible to configure it by using a custom configuration profile. The only required information is the policy node and the available configuration values. Below is an overview of the required policy node within the Bluetooth section of the Policy CSP and the available configuration values.

PolicyDescription
SetMinimumEncryptionKeySizeThis policy setting helps with preventing weaker devices cryptographically being used in high security environments, as there are multiple levels of encryption strength when pairing Bluetooth devices. The default configuration is 0 and allows all Bluetooth traffic. Number 1 can be used to always enforce Bluetooth encryption and ignoring the precise encryption key size. Any number from 2 through 16 can be used to always enforce Bluetooth encryption and in that case that number also represents the bytes used in the encryption process.

Configuration of the Bluetooth encryption key size

After being familiar with the available policy settings and the possible values, it’s time to take a look at the steps for configuring the Bluetooth encryption key size policy setting. The nine steps below walk through the configuration of a new custom device configuration profile that includes the required OMA-URI and its value. The wizard style of configuring makes sure that the device 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 and click Next
  • Name: Provide a valid name for the custom device configuration profile
  • Description: (Optional) Provide a valid description for the custom device configuration profile
  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 for the OMA-URI setting
  • Description: (Optional) Provide a valid description for the OMA-URI setting
  • OMA-URI: ./Vendor/MSFT/Policy/Config/Bluetooth/SetMinimumEncryptionKeySize
  • Data type: Select Integer
  • Value: 7
  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 BusinessEnterprise 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

Result of the Bluetooth encryption configuration

Let’s end this post by showing the result of the Bluetooth encryption configuration. This time I’ll do that by simply looking at the Event Viewer and the MDM Diagnostic Report and relating the information seen at both locations. In both overviews the following corresponding information is seen of the successfully applied configuration.

  1. Policy setting: SetMinimumEncryptionKeySize
  2. Policy area: Bluetooth
  3. Policy value: 7
  4. Policy scope: Device
  5. Policy ID: 5C71E17A-2715-47C6-B338-4EE-07C445339

More information

For more information about the different configuration options for Bluetooth, refer to the Bluetooth policies in the Policy CSP documentation.

Creating a custom look-and-feel across Android Enterprise fully managed devices

This week is all about Android Enterprise fully managed devices. More specifically, this week is all about creating a single look-and-feel across all Android Enterprise fully managed devices by using the Microsoft Launcher app. Similar to working with Android Enterprise dedicated devices and using the Managed Home Screen app. The Microsoft Launcher app provides many configuration options that can be configured by using an app configuration policy. That in combination with the recently introduced feature to configure the Microsoft Launcher app as the default launcher, enables the administrator to create a custom look-and-feel across all Android Enterprise fully managed devices. In this post I’ll show how to add the Microsoft Launcher app, how to configure the Microsoft Launcher app and how to configure the default launcher app. All the required actions for configuring a custom look-and-feel across all Android Enterprise fully managed devices. I’ll end this post by showing the end-user experience.

Configure a custom look-and-feel across Android Enterprise fully managed devices

Let’s start with the steps that are specific to creating a custom look-and-feel across Android Enterprise fully managed devices. For that I will assume that the enrollment of Android Enterprise fully managed devices is already configured and I’ll focus on the steps that are specifically related to configuring that custom look-and-feel. Those steps are: 1) adding the Microsoft Launcher app, 2) creating a custom look-and-feel for the Microsoft Launcher app, and 3) configuring the Microsoft Launcher app as the default launcher. More details of these steps are described below.

Add the Microsoft Launcher app

The first step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to add the Microsoft Launcher app as an app to Microsoft Intune and to assign it to the required users or devices. The Microsoft Launcher app can be set to a specific background and can be configured as the custom launcher on Android Enterprise fully managed devices. The following seven steps walk through the simple process of adding the Microsoft Launcher app as a Managed Google Play store app.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > Android to open the Android | Android apps page
  2. On the Android | Android apps, click Add to open the Select app type page
  3. On the Select app type page, select Managed Google Play app as the App type and click Select to open the Managed Google Play store
  4. In the Managed Google Play store, search for the Microsoft Launcher app, select the app and click Approve to open the Microsoft Launcher permissions dialog
  5. On the Microsoft Launcher permissions dialog, click Approve to switch to the Notifications tab
  6. On the Notifications tab, select Keep approved when app requests new permissions and click Done to return to the Managed Google Play store
  7. Back in the Managed Google Play store, click Sync to create apps that are added in Managed Google Play when the sync completes

Configure a custom look-and-feel for the Microsoft Launcher app

The second step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to create an app configuration policy for the Microsoft Launcher app that is assigned to the required users or devices. The app configuration policy can be used to configure a custom look-and-feel for the Microsoft Launcher app. The custom look-and-feel in the Microsoft Launcher app can be used to configure a custom look-and-feel across the Android Enterprise fully managed devices. The following steps walk through the process of configuring the Microsoft Launcher app to at least show a custom background across the Android Enterprise fully managed devices. That will help with recognizing company devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps > App configuration policies to open the Apps | App configuration policies page
  2. On the Apps | App configuration policies, click Add > Managed devices to open the Create app configuration policy wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the app configuration policy
  • Description: (Optionally) Provide a valid description for the app configuration policy
  • Device enrollment type: Managed devices (already greyed out based on the initially selection)
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner Only
  • Targeted app: Select Microsoft Launcher
  1. a) On the Settings page, configure any additional required permissions by clicking Add as shown below in Figure 1.
  1. b) Also on the Settings page, perform the actual app configuration settings to set a custom device wallpaper in the Microsoft Launcher app by clicking Add and creating something similar as shown below in Figure 2.
  1. On the Scope tags page, configuring any required scope tags and click Next
  2. On the Assignments page, configure the required assignment that contains the applicable users or devices and click Next
  3. On the Review + create page, click Create

Configure the Microsoft Launcher app as the default launcher

The last step, in creating a custom look-and-feel across all Android Enterprise fully managed devices, is to create a device restrictions policy for configuring the default launcher that is assigned to the required users or devices. The device restrictions policy can be used to configure the Microsoft Launcher app as the default launcher on Android Enterprise fully managed devices. The following steps walk through the process of configuring the Microsoft Launcher app as the default launcher on the Android Enterprise fully managed devices.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Android > Configuration profiles to open the Android | Configuration profiles page
  2. On the Android | Configuration profiles, click Create profile to open the Create a profile page
  3. On the Create a profile page, select the following information and click Create to open the Device restrictions wizard
  • Platform: Android Enterprise
  • Profile: Device restrictions
  1. On the Basics page, provide a valid name and (optionally) description for the device restriction policy and click Next
  2. On the Configuration settings page, configure at least the following settings in the Device restrictions sections (as shown in Figure 1) and click Next
  • Enrollment profile type: Fully managed
  • Make Microsoft Launcher the default launcher: Enabled
  1. On the Scope tags page, configuring any required scope tags and click Next
  2. On the Assignments page, configure the required assignment that contains the applicable users or devices and click Next
  3. On the Review + create page, click Create

End-user experience

Now let’s end this post by having a look at the end-user experience. This post was mainly focussed on creating a custom look-and-feel across all Android Enterprise fully managed devices by configuring a custom device wallpaper. The result of that configuration and the experience for the end-user, is shown on the right in Figure 4.

It’s good to know that this is just an example of the possibilities that are currently available via the Microsoft Launcher app as a custom launcher. Besides this basic, but most notable adjustment, the Microsoft Launcher app also provides configurations options for more adjustments, like the following:

  • Grid Size – The administrator can define the grid size for apps to be positioned on the home screen.
  • Feed – The administrator can enable the launcher feed on the device when the user swipes to the right on the home screen.
  • Search Bar – The administrator can specify the placement of search bar on the home screen.
  • Dock Mode – The administrator can enable the dock on the device when the user swipes to the right on the home screen.
  • Home Screen Apps – The administrator can define the set of apps that are visible on the home screen from amongst the apps installed on the device. 
  • Home Screen App Order – The administrator can specify the app order on the home screen
  • Home Screen Web Links – The administrator can pin websites to the home screen as quick launch icon.

More information

For more information about configuring the Microsoft Launcher app and configuring the default launcher, refer to the following articles:

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: