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

Supporting the unsupported platforms

This week is all about supporting the unsupported platforms. More specifically, working with the limitations of the platforms that are unsupported by (parts of) the Microsoft 365 solution. Those platforms are Chrome OS and the different Linux distributions. Often those platforms are around in an organization during the introduction of a Microsoft 365 solution. In many components of the Microsoft 365 solution, those platforms are currently not supported. Think about Microsoft 365 Apps for Enterprise, Microsoft Intune, Conditional Access and so on. Basically nothing is really working and/or supported on those platforms at this moment. From that perspective Chrome OS is maybe even worse than the different Linux distributions. That doesn’t mean that there is no story at all. In this post, I want to start with an introduction to the actual challenge, followed by going through the most common options that are available to address that challenge. The scope for this post is limited to Microsoft 365 E3 license functionalities.

An introduction

When introducing a Microsoft 365 solution, the strength is the completeness of the solutions and the security and management capabilities that it brings. Especially the security of the solution goes as far as to were it’s a closed solution. For that, think about Conditional Access, the front door protection towards the company apps and data. Basically the first line to protect the access to the company apps and data. However, that’s also were the first challenge is that arises. Conditional Access, the protection at the front door, doesn’t support Chrome OS and the different Linux distributions. That means that it’s still possible to protect at our front door, but it’s not possible to take everything into account. It’s not possible to require anything of those platforms, besides multi-factor authentication (MFA) for the user using that platform. That’s not always sufficient. In the ideal world an organization wants to make sure that either the app, or device, that is used to access the company apps and data, is managed. However, that’s simply currently not supported for all platforms. That’s also were the second challenge arises, as Chrome OS and the different Linux distributions are not supported by Microsoft Intune. So, it wouldn’t even be possible to get those platforms managed. And I could go on in that chain, by looking at the Microsoft 365 apps for Enterprise (with the exception of Chrome OS devices that are capable of using Android apps) and all the other different components of the Microsoft 365 solution, but the result would be the same for Chrome OS and the different Linux distributions. Of course there are small exceptions, like the Microsoft Teams app and Microsoft Defender ATP for specific Linux distributions (in that case an E3-license is not sufficient), but those platforms are simply currently not a good fit in a Microsoft 365 solution. Especially when focusing on functionalities that are available within a Microsoft 365 E3 license.

The options

However, that doesn’t mean that there is completely no place for Chrome OS and the different Linux distributions in a Microsoft 365 solution. It will just not be the complete experience as on Windows, Android, macOS and iOS devices. Let’s have a look at the most common options that are available for those platforms, within the Microsoft 365 E3 license functionalities, and let’s go high-over through those options.

  1. Block access for unsupported platforms
  2. Provide access based on the location of the devices
  3. Provide limited access to SharePoint Online and Exchange Online
  4. Provide access via Windows Virtual Desktop
  5. Provide access via a Virtual Machine

Option 1 – Block access for unsupported platforms

When an organization has strict requirements regarding the management of the device and/or app that the user is using for accessing company apps and data (for example to limit the possibility of loosing data, or having company data on personal devices), the Chrome OS devices and the different Linux distributions can’t be part of the Microsoft 365 solution. In that case the best option might be to completely block access to company apps and data, by using Conditional Access. Even though Conditional Access doesn’t support those platforms, Conditional Access can be used to block those platforms. The idea is similar to what I’ve described here, which is to create a Conditional Access policy that will block access to all cloud apps and is assigned to all platforms with the exception of the platforms that the organization does want to allow. The main difference is that the UI changed a little bit over the last year.

This option will completely block access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 1 for an example).

Option 2 – Provide access based on the location of the devices

When an organization has separately managed Chrome OS devices and/or different managed Linux distributions and can pinpoint those devices to a specific location, it can be an option to exclude those devices based on their location. The idea is similar to what I’ve described here, just the UI and experience changed over the years. This option could be an addition to the Conditional Access policy described in the first option. In this case there will be an exclusion for unsupported platforms coming from a specific location. The only thing that should be kept in mind is that it’s not possible to control which devices will actually be used by the user when accessing company apps and data on that specific location. We simply can’t differentiate between a separately managed Chrome OS device and a personal Chrome OS device from that specific location. That risk should be assessed.

This option will provide the user with full access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 2 for an example).

Option 3 – Provide limited access to SharePoint Online and Exchange Online

When an organization is trying to find a balance between security and usability, it might be an option to allow a limited experience via the browser. That limited experience is only be available for Exchange Online and SharePoint Online and provides the user with the ability to at least perform some basic activities on company apps and data, without the major risk of loosing data or getting data on personal devices. This experience can be created across all platforms, whether those platforms are supported by the different Microsoft 365 components, or not. The idea is similar to what I’ve described here, and something similar is also applicable to Exchange Online. If needed the limited experience can be further limited to a true read only experience. In addition, it’s even possible to differentiate the behavior between SharePoint sites as explained here.

This option will provide the user with limited access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 3 for an example).

Option 4 – Provide access via Windows Virtual Desktop

When an organization has strict requirements regarding the management of the device and/or app that the user is using for accessing company apps and data (for example to limit the possibility of loosing data), Windows Virtual Desktop (WVD) might also be an option on basically any platform. WVD is the exception when talking about cross-platform availability. The web client should work with any HTML5-capable browser and is officially supported on the default browsers of Chrome OS (Google Chrome) and the different Linux distributions (Mozilla Firefox). The good thing is that it’s possible to make sure that WVD is part of the Conditional Access policy, by either making sure WVD is hybrid Azure AD joined or by excluding WVD based on their location. Those are both valid options, when configured correctly, for making sure that it can be safely said that only WVD can access company apps and data. For basic account protection it’s still possible to use Conditional Access to require MFA on any platform that is used by the user for accessing WVD.

This option would provide the user with full access to company apps and data within WVD on Chrome OS devices and on the different Linux distributions (see Figure 4 for an example).

Option 5 – Provide access via a Virtual Machine

When an organization has many more advanced users, a last resort could also be to use a Virtual Machine (VM). That VM can exist on the host, can enroll into Microsoft Intune and can be compliant with the company policy. That would enable the user to access company apps and data, without the need for the administrator to create holes in the Conditional Access policy. The VM will be managed and secured in a similar way as any other physical device. This option is mainly applicable to the different Linux distributions.

My conclusion

Even though there are some unsupported platforms within most of the components of a Microsoft 365 solution, that doesn’t mean that an organization can’t use those platforms at all. I wouldn’t advise an organization to choose Chrome OS devices and/or different Linux distributions, when choosing for a Microsoft 365 solution, simply because of the currently limited support within a Microsoft 365 solution. However, when devices with those platforms are already within the organization, there are still options to somehow provide some support for those platforms. That’s the main point of this post. It’s just not a perfect story, yet.

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.

Android Enterprise and Microsoft Intune: And the previously missing use case

This week is all about an addition to my previous post about the device management jungle of Android Enterprise. In that post I already did a brief look at the future and what Android 11 would bring to the table. At that time Microsoft Intune did not yet support a deployment scenario to address the Corporate-Owned, Personally Enabled (COPE) use case. The good news is: that has changed! Microsoft Intune now contains the deployment scenario Corporate-Owned Work Profile, which is currently still in preview, and that deployment scenario can address the COPE use case.

With this blog I want to provide a refreshed overview of the different deployment scenarios and the use cases that are addressed. However, the main focus of this post is the new Corporate-Owned Work Profile deployment scenario. I’ll start this post with the refreshed overview of the different Android Enterprise deployment scenarios in Microsoft Intune, followed with a summery of the main characteristics of the different deployment scenarios. I’ll end this post by focusing on the implementation of the new Corporate-Owned Work Profile deployment scenario.

Updated overview of the Android Enterprise deployment scenarios

Let’s start with a brief overview of the different Android Enterprise deployment scenarios that are available within Microsoft Intune. I’ve discussed these deployment scenarios before, but I thought it would be good to provide another quick overview to clearly differentiate between the deployment scenario and the use case and to address the main characteristics of the different deployment scenarios. Below in Figure 1 is an overview of the different deployment scenarios. As it’s mainly focused on the Android Enterprise capabilities, I’ve skipped the MAM-only scenario. For a first filtering the deployment scenarios are sorted based on the owner of the device and based on the type of workers for the device.

The next step in providing a clearer overview is the table below. That table describes the main characteristics of the different deployment scenarios. It shows important characteristics like the main use cases of a deployment scenario, if personal use is possible, if the privacy can be guaranteed, the management reach and more familiar characteristics.

Deployment scenarioUse casePersonal usePrivacy guaranteedEnrollment methodManagement reachReset requiredUser affinity
Work ProfileBring Your Own Device (BYOD)YesYesCompany Portal appProfile ownerNoYes
Corporate-Owned Work ProfileCorporate-Owned, Personally Enabled (COPE)YesYesNear Field Communication, Token entry, QR code scanning, or Zero touchProfile owner with device-level settingsYesYes
Fully ManagedCorporate-Owned, Business Only (COBO)YesNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesYes
DedicatedCorporate-Owned, Single Use (COSU)NoNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesNo

As a little bit of context with this table, the different collumns are used to provide the following information:

  • Deployment scenario – This column describes the name of the deployment scenario (or some times referred to as management scenario) in Microsoft Intune
  • Use case – This column describes the often used name of the most common use case
  • Personal use – This column describes if the deployment scenario can facilitate personal use (which can be as simple as the option for enabling a personal account for the Google Play store)
  • Privacy guaranteed – This column describes if the deployment scenario can guarantee the privacy of the user (which actually can only be the case when using a work profile)
  • Enrollment method – This column describes the different enrollment methods that are available for the deployment scenario
  • Management reach – This column describes the management reach of the deployment scenario on the device
  • Reset required – This column describes if the deployment scenario requires a reset of the device
  • User affinity – This column describes if the the deployment scenario facilitates user affinity

Android Enterprise Corporate-Owned Work Profile

Now let’s have a look at the previously missing use case, which was the actual trigger of this post, the COPE use case. That use case can now be addressed with the introduction of the Corporate-Owned Work Profile deployment scenario. A long time the public feeling was that Microsoft was missing a use case in Microsoft Intune. Even though the feeling was fair and actually not just a feeling but a simple fact, there was also a fair reason why the deployment scenario for that use case was not available. Microsoft was relying on the Android Management API (AMAPI) and support for the required deployment scenario was not available. That’s changing now.

However, before looking at that deployment scenario in a bit more detail, let’s start with stating that the previous deployment scenario in Android Enterprise, to address the COPE use case, often named Work Profile on Fully Managed Device (WPoFMD), is not going to happen in Microsoft Intune. The support that’s provided via Microsoft Intune by leveraging AMAPI, is focused on the changes coming with Android 11. With Android 11, Google wants to focus more on the privacy of the user. To achieve that, Google wants to further separate the work profile and the personal profile. With the previous implementation there would be two separate Device Policy Controller (DPC) instances running on the device. An instance running as device owner in the personal profile of the user and an instance running as profile owner in the work profile of the user. As you can imagine, that theoretically provides an organization with a lot of control over the personal profile of the user. Besides the level of control, the organization could also potentially see information from the personal profile of the user, like the installed apps. That will also be one of the biggest changes in the new implementation. There will no longer be a work profile on a fully managed device. Instead, the new Corporate-Owned Work Profile deployment scenario will be similar to a normal work profile, but on steroids. Starting with Android 11, there will be a single DPC instance running as profile owner on the corporate owned device of the user. That instance also has the capabilities to do a few device settings. However, there will be no insights in for example the installed apps, or data, in the personal profile on the device. There will be strict separation between the apps and data in the personal profile and the work profile. Similar to the work profile deployment on personal devices. The main difference between the two are the steroids of the DPC instance. On a personal device, the DPC instance is running as profile owner and only has permissions within the work profile. On a corporate device, the DPC instance is also running as profile owner, it has permissions within the work profile and it can manage a few device settings that also affect the personal profile.

When looking from a Microsoft Intune perspective, the nice thing is that the user will have the same usage experience on devices with Android 8 and later, and that the administrators will also have the same management experience for devices with Android 8 and later. That’s achieved by using AMAPI. That will make sure that with a single configuration performed by the administrator, the correct configuration will be applied to the Android device of the user. No matter the specific Android version. As long as it’s Android 8 or later.

More information

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

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.

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: