Detecting local administrators with proactive remediations

This week is all about proactive remediations, which is a feature of Endpoint Analytics. Proactive remediations are script packages that can detect common issues and remediate those issues if needed. All of that before the user even realizes that there is an issue. Those remediations can help with reducing support calls. The strength is that the remediations can be anything to address potential issues, as long as it can be addressed by using PowerShell. Each script package contains a detection script and a remediation script and that script package is deployed through Microsoft Intune. For deploying script packages, Microsoft Intune relies on the Intune Management Extension (IME).

To show the power of proactive remediations, I’ll use local administrators as an example. I’ve did something similar a long time ago for Configuration Manager and I still get many questions around that subject on my post about managing local administrators. Even in this modern world, local administrators are still a hot item. In this post I’ll focus on the detection part of proactive remediations and the remediation part itself might only be a week away. I’ll start this post by constructing the detection script, followed by creating the script package. I’ll end this post by verifying the results locally on the device.

Important prerequisites

Before actually starting with Endpoint Analytics it’s important to have the different prerequisites in place. That means the correct licenses and the correct configuration.

  • The device must be running Windows 10 Enterprise, Professional, or Education
  • The devices must be enrolled into Endpoint Analytics
  • The devices must be Azure AD joined or hybrid Azure AD joined and meet one of the following conditions:
    • the device is managed by Intune.
    • the device is co-managed device and running Windows 10, version 1903 or later.
    • the device is co-managed device and running on pre-1903 versions of Windows 10 with the Client apps workload pointed to Intune
  • The user must be licensed for Endpoint Analytics, which is included in Enterprise Mobility + Security E3 or higher and Microsoft 365 Enterprise E3 or higher, and when not using the latter, additional licensing of the following:
    • Windows 10 Enterprise E3 or E5
    • Windows 10 Education A3 or A5
    • Windows Virtual Desktop Access E3 or E5

Constructing the detection script

The first step is constructing the detection script. That script should detect the correct situation. In this example, the detection script should detect the correct number of local administrators and also the correct local administrator users. For a successful detection of the correct (number of) local administrators, the script should return an exit code of 0 and for a failed detection of the (number of) local administrators, the script should return an exit code of 1. That failure will eventually trigger the remediation script. More about that, next week. Besides that, it’s good to know that the last line of output, before the exit code, will also be displayed in the logs. That can be helpful when verifying and troubleshooting the detection script. The following example detection script will verify the number of local administrators and once the number matches, it will actually verify the local administrator users with the configured list of local administrators. Make sure to adjust that list with the correct local administrators and make sure to adjust the number of local administrators. The required adjustments are mentioned in the script example below.

#Define variables
$localAdministrators = @()
$memberCount = 0
$numberLocalAdministrators = 4 #Adjust to your number of administrators
try {
$currentUser = (Get-CimInstance Win32_ComputerSystem).Username -replace '.*\\'
$administratorsGroup = ([ADSI]"WinNT://$env:COMPUTERNAME").psbase.children.find("Administrators")
$administratorsGroupMembers= $administratorsGroup.psbase.invoke("Members")
foreach ($administrator in $administratorsGroupMembers) {
$localAdministrators += $administrator.GetType().InvokeMember('Name','GetProperty',$null,$administrator,$null)
}
if ($localAdministrators.Count -eq $numberLocalAdministrators) {
foreach($localAdministrator in $localAdministrators) {
switch ($localAdministrator) {
#Adjust to your local administrators
"Administrator" { $memberCount = $memberCount + 1; break; }
"$currentUser" { $memberCount = $memberCount + 1; break; }
"[YourGlobalAdminRoleSid]" { $memberCount = $memberCount + 1; break; }
"[YourDeviceAdminRoleSid]" { $memberCount = $memberCount + 1; break; }
default {
Write-Host "The found local administrators are no match"
exit 1
}
}
}
if ($memberCount -eq $numberLocalAdministrators) {
Write-Host "The found local administrators are a match"
exit 0
}
}
else {
Write-Host "The number of local administrators doesn't match"
exit 1
}
}
catch {
$errorMessage = $_.Exception.Message
Write-Error $errorMessage
exit 1
}

Note: Compared to my previous post, I prefer to use ADSI above WMI and Get-LocalGroupMember. WMI was often too slow and the mentioned cmdlet doesn’t really like SIDs yet.

Creating the script package

The second step is creating the script package. The script package can be created by using the relatively new functionality of Endpoint Analytics, which is proactive remediations. That functionality can be used to basically schedule scripts to detect specific configurations and, if needed, remediate the configuration. The following six steps walk through the process of creating a script package, with a focus on the detection script. That will create a script package to detect the local administrators. That script package can be scheduled to either perform the detection (and remediation) only once, or on a recurring schedule. The latter will make sure that it can actually be used for creating some baseline configurations, which might sound familiar when previously, or still, using Configuration Manager. The idea is the same, just a bit more simplistic and easier to use.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Reports Endpoint analytics (Preview) > Proactive remediations to open the Endpoint analytics (Preview) | Proactive remediations blade
  2. On the Endpoint analytics (Preview) | Proactive remediations blade, click Create script package to open the Create custom script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom script package
  • Description: (Optional) Provide a valid description for the custom script package
  • Publisher: Provide a valid publisher for the custom script package
  • Version: [Greyed out]
  1. On the Settings page, provide the following information and click Next
  • Detection script file: Select the created detection script
  • Detection script: [Greyed out]
  • Remediation script file: (Optional) More about the remediation script file next week
  • Remediation script: (Optional) More about the remediation script next week
  • Run this script using the logged-on credentials: No
  • Enforce script signature check: No
  • Run script in 64-bit PowerShell: No
  1. On the Assignments page, provide the following information and click Next
  • Assign to: Select the assigned group and when selecting multiple groups, multiple lines will appear with all separate schedule configurations
  • Schedule: Click on the three dots to open the schedule configuration. This enables the administrator to configure a recurrence frequency for the script package. This can be Once, Daily, or Hourly.
    • When selecting Once, a specific date and time should be configured
    • When selecting Daily, a frequency and daily time should be configured
    • When selecting Hourly, a frequency should be configured
  1. On the Review + create page, verify the information and click Create

Verifying the results

For the detection of the local administrators, I’ll focus mainly on the information locally on the device. Next week, when adding the remediation, the focus will be on Microsoft Intune when looking at the results. As it’s the IME that is addressing the execution of the script packages, the information related to the execution is also logged in the IME related logfiles. The most interesting information can be found in the IntuneManagementExtension.log. That logfile contains the execution information of the script packages and every related line in the log has a prefix of [HS]. That prefix is referring to HealthScripts, which is shown in the different logs and file locations. When looking at the [HS] prefix throughout the log, it’s divided into the following two categories:

  1. Scheduler – Looking at the log, the Scheduler is responsible for requesting and scheduling the script packages. Below, in Figure 3, is an example of the Scheduler that is scheduling the script package for detecting local administrators. The highlighted sections show information about the user, the policy and the schedule. All of that information is referenced below in more logs, file locations and the registry.
  1. Runner – Looking at the log, the Runner is responsible for executing and reporting about the script packages. Below, in Figure 4, is an example of the Runner that is actually executing the scheduled policy for detecting local administrators. The highlighted sections show information about the user, the policy, the schedule, the result and the output. All that information is referenced above in the script, and below in the file location and the registry.

The script package is store locally in the HealthScripts folder in the IMECache folder. That folder contains a folder, as shown below in Figure 5, that corresponds with the policy that was highlighted in the IntuneManagementExtension.log. That folder contains a script named detect and a script named remediate and both of those scripts correspond to the scripts of the script package. When the script package is only used for detection, the remediate script will be empty.

In the end all of the most important information is stored in the registry, in the Scrips key in HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies. That key contains a key with information about the execution of the script package and that information is stored below a key of the user and the policy. That key contains the latest execution information and is shown below in Figure 6.

The Scripts key also contains a key with information about the result of the script package and that information is store below a key of the user and the policy. That key contains the result information that is reported and is shown in Figure 7.

The actual content of the Result value is shown below. That information contains the policy, the user, that status and the output. All the information that was referenced earlier in the script, log, file location and registry.

{ 
    "PolicyId":"176b61ca-59e6-4af1-b852-13a3102c5578",
    "UserId":"dedbba8f-f4f1-475c-a30b-895d87d77e9b",
    "PolicyHash":null,
    "Result":3,
    "ResultDetails":null,
    "InternalVersion":1,
    "ErrorCode":0,
    "ResultType":1,
    "PreRemediationDetectScriptOutput":"The found local administrators are a match",
    "PreRemediationDetectScriptError":null,
    "RemediationScriptErrorDetails":null,
    "PostRemediationDetectScriptOutput":null,
    "PostRemediationDetectScriptError":null,
    "RemediationStatus":4,
    "Info": {
        "RemediationExitCode":0,
        "FirstDetectExitCode":0,
        "LastDetectExitCode":0,
        "ErrorDetails":null
    }
}

More information

For more information about Endpoint Analytics and Proactive Remediations, refer to the following docs

Deploy Microsoft Defender Application Control policies without forcing a reboot

This week is all about Microsoft Defender Application Control (MDAC). More specifically, about configuring MDAC policies on Windows 10 devices by using Microsoft Intune without forcing a reboot. MDAC, often still referred to as Windows Defender Application Control (WDAC), restricts application usage by using a feature that was previously already known as configurable Code Integrity (CI) policies. To make the history lesson complete, configurable CI policies was one of the two main components of Windows Defender Device Guard (WDDG). History aside, CI policies help with protecting Windows 10 devices by checking apps based on the attributes of the code signing certificates and the app binaries, the reputation of the app, the identity of the process that initiated the installation (managed installer) and the path from which the app is launched. In this post I won’t focus on how MDAC technically works, but I want to focus on creating a custom MDAC policy and deploying that policy by using Microsoft Intune, without triggering a reboot. The same steps are actually applicable to deploying any custom MDAC policy by using Microsoft Intune. I’ll end this post by having a look at the end-user experience.

Create Code Integrity policy

The first action is to create a custom MDAC policy, which was formerly known as a Code Integrity policy. However, as a lot in the configuration is still referring to Code Integrity, or CI, I’ll keep referring to it in this post as a Code Integrity policy. Luckily, Windows already contains a few examples that can be used as the starting point (in a folder named CodeIntegrity). As this post is not focussed on constructing a custom Code Integrity policy, I’ll use DefaultWindows_Enforced.xml as my custom Code Integrity policy. That policy enforces the rules that are necessary to ensure that Windows, 3rd party hardware and software kernel drivers, and Windows Store apps will run and is also used as the basis for all Microsoft Endpoint Manager (MEM) policies.

PowerShell can be used to make all kinds of adjustments to a Code Integrity policy (the .xml policy file), by using the ConfigCI module. From that module the Set-RuleOption cmdlet can be used to modify the rule options in a Code Integrity policy. The configured rule options appear under the Rules property in the .xml policy file. Currently there are 19 different rule options that can be configured and those rule options are documented here. For this post the most important rule option, is rule option 16. That rule option can be used to allow future updates to the Code Integrity policy without requiring a system reboot. Below is an example of how to add rule option 16 to the Code Integrity policy. Using that same example with the -Delete parameter, will remove the no reboot information again.

Set-RuleOption -FilePath .\DefaultWindows_Enforced.xml -Option 16

Below in Figure 1, with number 2, is an example of the information that will be added to the .xml policy file, after adding rule option 16 to the Code Integrity policy.

Note: The detailed reader might notice that I’ve removed some default rule options in Figure 1 that are normally already configured by default. That is correct, because I wanted Figure 1 to focus on the specific settings of this post.

Transform Code Integrity policy

The second action is to transform the Code Integrity policy, so it can be distributed by using Microsoft Intune. To distribute the Code Integrity policy, it must be converted from a .xml policy file to .bin file. From the earlier mentioned PowerShell module, the ConverFrom-CIPolicy cmdlet can be used to convert a Code Integrity policy into a binary format. That binary version of the policy can be installed on Windows 10 devices and can be distributed via Microsoft Intune. Below is an example of how to convert the .xml policy file.

ConvertFrom-CIPolicy -XmlFilePath ".\DefaultWindows_Enforced.xml" -BinaryFilePath "DefaultWindows.bin"

Distribute Code Integrity policy

The third action is to distribute the Code Integrity policy, by using Microsoft Intune. To distribute the binary version of the Code Integrity policy, a custom device configuration profile can be used to achieve that. That requires the correct OMA-URI.

Construct OMA-URI

To distribute a custom Code Integrity policy, the ApplicationControl CSP can be used. This CSP was added with Windows 10, version 1903, and provides extended diagnostics capabilities, support for multiple policies and it supports rebootless policy deployment. The latter is the main difference with the AppLocker CSP. Unlike the AppLocker CSP, the ApplicationControl CSP detects the presence of no-reboot option. The following OMA-URI can be used ./Vendor/MSFT/ApplicationControl/Policies/{PolicyID}/Policy. In that OMA-URI, the PolicyID should actually be an existing value and not a self-generated value, like with most other policies that are configured. In this case the PolicyID should be the PolicyID of the Code Integrity policy. That PolicyID can be found in the .xml policy file, as shown in Figure 1, with number 1, and should be used without the curly brackets. For this example that means that the following OMA-URI can be used ./Vendor/MSFT/ApplicationControl/Policies/A244370E-44C9-4C06-B551-F6016E563076/Policy.

Create custom device configuration policy

To actually distribute a custom Code Integrity policy, Microsoft Intune can be used to configure the constructed OMA-URI on Windows 10 devices. The following nine steps walk through the process of creating a new custom device configuration profile that configures a single OMA-URI setting.

  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/ApplicationControl/Policies/A244370E-44C9-4C06-B551-F6016E563076/Policy
  • Data type: Select Base64 (file)
  • Value: Select the created binary file
  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 CSP for version 1903 and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

End-user experience

Now let’s end this post by having a look at the end-user experience, once the Code Integrity policy is distributed and applied to the Windows 10 device of the user. The first thing that the user might notice is that the device doesn’t request a reboot. When the user now wants to start an application that doesn’t comply with the configured Code Integrity policy, the user will be prevented from starting the application. Figure 3 shows an example of a user that wants to start an application that was manually installed and the user receives a clear message that the app is blocked by Windows Defender Application Control.

More information

For more information about deploying WDAC policies, refer to the docs about deploying Windows Defender Application Control policies by using Microsoft Intune.

Windows 10 MDM Bridge WMI Provider: Settings template

This week my post is a few days later, as my post is an extension of my session at the Workplace Ninja Virtual Summit 2020. At the virtual summit I did a session about Getting to know the Windows 10 MDM WMI Bridge provider and during my session I shared how to easily work with the Windows 10 MDM Bridge WMI provider. Similar to using Microsoft Intune to address the different CSPs, we can also use PowerShell via the WMI bridge.

The main thing that I’ve showed at the end of that session was a setting template, basically a PowerShell-function, that can be used to set, adjust and remove nearly all settings via the MDM WMI Bridge provider. That PowerShell-script is available below and I’ve completely documented the use, parameters and what it exactly does.

function Update-PolicySetting {
<#
.SYNOPSIS
A simple function to update policy settings by using MDM WMI Bridge
.DESCRIPTION
This function provides the capability to adjust policy settings by using the MDM WMI Bridge.
It supports the capabilities to create, update and remove an instance
.PARAMETER className
This parameter is required for the name of the WMI class
.PARAMETER parentID
This parameter is required for the name of the parent node of the OMA-URI
.PARAMETER instanceID
This parameter is required for the name of the WMI instance, which is the node of the OMA-URI
.PARAMETER configureProperty
This parameter is required when configuring a setting and is the name of the property
.PARAMETER valueProperty
This parameter is required when configuring a setting and is the value of the property
.PARAMETER removeInstance
This switch is used to indicate that the specified variables are used for deleting the WMI instance
.EXAMPLE
Update-PolicySetting -className 'MDM_Policy_Config01_Start02' -parentID './Vendor/MSFT/Policy/Config' -instanceID 'Start' -configureProperty 'HideAppList' -valueProperty 1
This example will run the function and configure a the property to hide the app list in Start
.EXAMPLE
Update-PolicySetting -className 'MDM_Policy_Config01_Start02' -parentID './Vendor/MSFT/Policy/Config' -instanceID 'Start' -removeInstance
This example will run the function and remove the instance of Start
.NOTES
Author: Peter van der Woude
Contact: pvanderwoude@hotmail.com
#>
param (
[Parameter(Mandatory=$true)]$className,
[Parameter(Mandatory=$true)]$parentID,
[Parameter(Mandatory=$true)]$instanceID,
[Parameter(Mandatory=$false)]$configureProperty,
[Parameter(Mandatory=$false)]$valueProperty,
[Parameter(Mandatory=$false)][Switch]$removeInstance
)
try {
#Get a specific instance
$instanceObject = Get-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName $className -Filter "ParentID='$parentID' and InstanceID='$instanceID'" -ErrorAction Stop
}
catch {
Write-Host $_ | Out-String
}
#Verify the action
if ($removeInstance -eq $false) {
#Verify if the additional required parameters are provided
if ($PSBoundParameters.ContainsKey('configureProperty') -and ($PSBoundParameters.ContainsKey('valueProperty'))) {
#Verify if the instance already exists
if ($null -eq $instanceObject) {
try {
#Create a new instance
New-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName $className -Property @{ InstanceID=$instanceID; ParentID=$parentID; $configureProperty=$valueProperty } -ErrorAction Stop
Write-Output "Successfully created the instance of '$instanceID'"
}
catch {
Write-Host $_ | Out-String
}
}
else {
try {
#Adjust a specific property
$instanceObject.$configureProperty = $valueProperty
#Modify an existing instance
Set-CimInstance -CimInstance $instanceObject -ErrorAction Stop
Write-Output "Successfully adjusted the instance of '$instanceID'"
}
catch {
Write-Host $_ | Out-String
}
}
}
else {
Write-Output ">> Make sure to provide a value for configureProperty and valueProperty when creating or adjusting an instance <<"
}
}
elseif ($removeInstance -eq $true) {
#Verify if the instance already exists
if ($null -ne $instanceObject) {
try {
#Remove a specific instance
Remove-CimInstance -InputObject $instanceObject -ErrorAction Stop
Write-Output "Successfully removed the instance of '$instanceID'"
}
catch {
Write-Host $_ | Out-String
}
}
else {
Write-Output "No instance available of '$instanceID'"
}
}
}

An example to use this function to hide the app list in Start can be found below.

Update-PolicySetting -className 'MDM_Policy_Config01_Start02' -parentID './Vendor/MSFT/Policy/Config' -instanceID 'Start' -configureProperty 'HideAppList' -valueProperty 1 

As mentioned during my session, the required parameters can be found mainly by looking at WMI by using the WMI Explorer. The name of the instance is the node of the OMA-URI that contains the required configuration. In this case Start. When you can’t find the required information, you can always refer to the documentation that’s shared below.

More information

During my sessions I’ve showed many reference to post that describe the subjects that I covered. For future reference those posts are summarized below.

Getting started with Endpoint Data Loss Prevention

Completely fresh after my vacation I thought it would be awesome to have a look at Endpoint Data Loss Prevention (DLP), which was announced during Microsoft Inspire. Endpoint DLP extends the activity monitoring and protection capabilities of DLP to sensitive content on Windows 10 devices. The best part of it is that the actual functionality is built-in to Windows 10 (and the Edge Chromium browser). No additional agent is required, just the onboarding of the device. In this post I want to start with a short introduction about Endpoint DLP, followed by the actions to onboard devices and to configure DLP policies and settings. I want to end this post by having a quick look at the end-user experience.

Introduction to Endpoint DLP

Let’s start with a quick introduction about Endpoint DLP. Endpoint DLP is an extension on the activity monitoring and protection capabilities that are provided by DLP, for sensitive content that is used on Windows 10 devices. That can be content that is directly edited in SharePoint Online, or OneDrive, but also content that is only locally available on the Windows 10 devices. So no dependency on the location of the data, but only on the data itself (and of course the device that it’s used on). Really awesome!

At this moment Endpoint DLP enables organizations to audit and manage activities of users on sensitive items. Activities like created, renamed, printed and more. For a complete list, refer to the documentation. Besides that, Endpoint DLP monitors the activity based on MIME type, which means that an extension change doesn’t stop content from be monitored. At this moment the list of supported file extensions is documented here.

To enable Endpoint DLP, make sure that the following is in place:

  1. The user must have a Microsoft 365 E5/A5 subscription or Microsoft 365 E5/A5 compliance or information protection and governance add-on
  2. The device must be running Windows 10 build 1809 or later
  3. The device must be Azure Active Directory (AAD) joined, or Hybrid Azure AD joined
  4. The Chromium Edge browser must be used on the device for the cloud activity actions

Onboard devices into device management

The first action that should be performed is onboarding the devices into device management. After onboarding the devices, the activities of those devices can be reviewed in features like activity explorer, or can be monitored by compliance solutions such as insider risk management and data loss prevention (DLP). To enable the onboarding, simply follow the next three steps.

  1. Open the Microsoft 365 compliance portal and navigate to Settings > Device onboarding (preview) > Devices and click on Turn on device onboarding
  1. On the Turn on device onboarding dialog box, review the message about devices already onboarded via Microsoft Defender ATP and click OK
  1. On the Device monitoring is being turned on dialog box, review the message and click OK

After successfully performing the previous steps, the devices that are already onboarded via Microsoft Defender ATP will start appearing in the devices list. When not already using Microsoft Defender ATP, devices can be onboarded by using the same process as for onboarding devices for Microsoft Defender ATP. When using Microsoft Intune that means following the next 10 steps.

  1. In the Microsoft 365 compliance portal, navigate to Settings > Device onboarding (preview) > Onboarding
  2. Select with Mobile Device Management / Microsoft Intune as the Deployment method and click Download package to download the onboarding package
  3. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices  > Configuration profiles > Create a profile to open the Create a profile blade
  4. On the Create a profile blade, provide the following information and click Create to open the Microsoft Defender ATP (Windows 10 Desktop) wizard
  • Platform: Windows 10 and later
  • Profile: Microsoft Defender ATP (Windows 10 Desktop)
  1. On the Basics page, provide a valid name for the profile and click Next
  2. On the Configuration settings page, provide the following information and click Next
  • Microsoft Defender ATP client configuration package type: Select Onboard and add the downloaded package of Step 2 (this is not necessary when a Microsoft Defender ATP connection is established with Microsoft Intune)
  • Sample sharing for all files: Not applicable
  • Expedite telemetry reporting frequency: Not applicable
  1. On the Scope tags page, click Next
  2. On the Assignments page, assign the onboarding configuration to the required group and click Next
  3. On the Applicability Rules page, click Next
  4. On the Review + create page, click Create to create the profile

Configure Endpoint DLP settings

Once the devices are onboarded, the next step is to have a look at the Endpoint DLP settings. These settings apply to all new and existing DLP policies that protect content on Windows devices and these settings are divided into the following three categories.

  • File path exclusions – This category can be used to configure file path exclusion to make sure that files in the specified locations won’t be monitored by the DLP policies.
  • Unallowed apps – This category can be used to configure specific apps that are prevented from accessing files that are protected by the DLP policies.
  • Browser and domain restrictions to sensitive data – This category is divided into the following two subcategories.
    • Unallowed browsers – This subcategory can be used to configure specific browsers that will be blocked from accessing files that are protected by DLP policies. The end-user will be prompted to use Edge Chromium.
    • Service domains – This subcategory can be used to configure specific service domains – from Edge Chromium – that are either allowed or blocked from uploading files that are protected by DLP policies.

To optionally configure these settings simply open the Microsoft 365 compliance portal and navigate to Policies > Data loss prevention > Endpoint DLP settings (preview).

Configure Endpoint DLP policy

Once the generic Endpoint DLP settings are configured, the next step is to have a look at configuring an Endpoint DLP policy. That’s actually just configuring a normal DLP policy with a new endpoint specific section. Let’s walk through those configurations by configuring a DLP policy that is based on the defaults of the GDPR template. To achieve that, simply follow the 11 steps below.

  1. Open the Microsoft 365 compliance portal and navigate to Policies > Data loss prevention > Policies and click Create policy (preview) to open the Create policy wizard
  2. On the Choose the information to protect page, select the General Data Protection Regulation (GDPR) template and click Next
  3. On the Name your DLP policy page, verify the information – if needed adjust the name – and click Next
  4. On the Locations to apply the policy page, make sure to at least select Devices (preview), make sure to include a (test) user and/or group and click Next
  1. On the Define policy settings page, select Review and customize default settings from the template and click Next
  2. On the Info to protect page, verify the default configuration and click Next
  3. On the Protection actions page, verify the default configuration and click Next
  4. On the Customize access and override settings page, perform the following actions and click Next
  • Verify the default configuration of the Restrict access or encrypt the content in Microsoft 365 locations section
  • Enable the configuration of the Audit or restrict activities on Windows devices section and configure the different activities to Audit, Block or Block with override
  1. On the Test or turn on the policy page, configure to test or to turn on or off the policy and click Next
  2. On the Review your settings page, verify the configuration and click Submit
  3. On the New policy created message page, select Done to close the wizard

End-user experience

Now let’s end this post by having a look at the end-user experience. Based on the usage of the GDPR template, I can show some nice examples of the user experience when working with personal information (like drivers license numbers). To show some examples of the behavior I’ve created a document, named Document5.docx, and that document contains a drivers license number. When I now want to copy content from that document, I receive a notification as shown below in Figure 6 and when I now want to print that document, I receive a notification as shown in Figure 7. Both notifications show the override option for the end-user, via the Allow button, as configured in the DLP policy (see Figure 5).

More information

For more information about Microsoft Endpoint DLP, refer to the documentation that starts here with Learn about Microsoft 365 Endpoint data loss prevention (preview).

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.

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.

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