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.

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.

The different ways of enrolling devices in Windows Analytics

After a week of silence, due to the MVP Summit, this week another new blog post. This week is all about enrolling devices in to Windows Analytics. An updated version, with a slightly different angle, of a post of about two years ago. This time I’ll summarize the different methods to achieve the same goal and the changes since Windows 10, version 1803. I’ll start this post with an overview of the required settings, followed by an overview of the different configuration methods. I’ll end this post by going through my preferred method, for a cloud scenario, and the administrator experience.

Settings to configure

Now let’s start by looking at the settings that are required to enroll devices in to Windows Analytics. Those settings are the commercial ID, the telemetry level (and with that enabling Windows telemetry) and allowing the device name in the telemetry data (since Windows 10, version 1803). The following table describes the settings that are required, including a description, and starting point for my preferred method, for a cloud scenario, of configuring these settings.

Policy Description

AllowTelemetry

Values: 0 (Security), 1 (Basic), 2 (Enhanced), or 3 (Full)

This setting should be used to enable Windows telemetry. Windows Analytics requires a minimum Windows telemetry level of enhanced (optional together with the policy LimitEnhancedDiagnosticDataWindowsAnalytics to limit the telemetry data to the minimal required).

AllowDeviceNameInDiagnosticData

Values: 0 (Disabled) or 1 (Enabled)

This setting should be used to allow the device name in the Windows telemetry that is sent to Windows Analytics. That will enable that the different solutions within Windows Analytics can actually be used for really tracking update compliance.

CommercialID

Values: [YourCommercialID]

This setting should be used to specify the workspace id that should be used for Windows Analytics. The commercial ID can be found in the Settings of the different Windows Analytics solutions.

Note: The first two policies are available in the node ./Vendor/MSFT/Policy/Config/System and the third policy is available in the node ./Vendor/MSFT/DMClient/Provider/MS DM Server.

Configuration options

Let’s continue with looking at the different configuration methods. Every configuration option has pros and cons, which can differ per scenario.

1 WA-ConfigMgrWhen using Configuration Manager, the Configuration Manager client can be used to enroll a device in to Windows Analytics. This can be achieved by using the Windows Analytics section in the Client Settings. This configuration method can configure the commercial ID and the telemetry level. This can be a useful method in an on-premises, or a co-management scenario. Only allowing the device name in the telemetry data would require an additional configuration method.
2 WA-GPOWhen using Group Policy, Administrative Templates can be used to enroll a device in to Windows Analytics. This can be achieved by using the Data Collection and Preview Builds section in the Windows Components section of the Administrative Templates. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in any on-premises, or cloud scenario (by using a third-party tool like PolicyPak: MDM Edition). Only reporting on a setting-level will be limited in a cloud scenario.
3 When using Configuration Manager or Microsoft Intune, PowerShell scripts can be used to enroll a device in to Windows Analytics. This can be achieved by using the New-Item and the New-ItemProperty cmdlets to directly create the required registry keys. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in any on-premises, or cloud scenario. Only reporting on a setting-level will be limited.
4 WA-MDMWhen using Microsoft Intune, Windows 10 MDM can be used to enroll a device into Windows Analytics. This can be achieved by using custom OMA-URI settings. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in a co-management, or cloud scenario.

Preferred configuration option

Let’s continue by looking at my preferred configuration option, at least in a cloud scenario. Besides using Group Policy, this is the most reliable and complete option for configuring the required settings. It allows setting-level configuration and reporting. The following 3 steps walk through the required actions.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Devices configuration – Profiles blade;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

WA-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b;

Explanation: This configuration will make sure that a custom profile is created that can be used to add the required Windows Analytics settings.

3b

WA-AddRowOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: Specify a the required policy setting;
  • Data type: Select Integer;
  • Value: Specify the required value;

Note: Simply repeat this step for every policy setting that should be configured.

WA-MDM

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

Administrator experience

Let’s end this post by looking at the administrator experience. Of course I can simply show the configurations on the device, but I thought that showing a device including the device name in a solution would show the complete picture. It proofs that Windows telemetry is enabled, that it’s sending data to the correct workspace and that it’s sending the device name (even for devices with Windows 10, version 1803 and newer). See below for that example.

WA-Result

More information

For more information about Windows Analytics and Microsoft Intune, please refer to the following articles:

Enable PIN reset from the login screen

This week I’m going for an end-user experience focused blog post. This week is all about the PIN reset option on the login screen. In other words, the I forgot my PIN option. Starting with Windows 10, version 1709, it’s now possible to enable the I forgot my PIN option from the login screen. When using Windows Hello for Business, which can be configured during the Windows enrollment, by using Microsoft Intune, the PIN is the fallback mechanism when it’s not possible to authenticate with biometrics. In other words, the PIN is really important.

In this post I’ll provide the required configuration to provide the user with the I forgot my PIN option from the login screen. I’ll do that by assuming that the user can use the Windows Hello for Business PIN recovery service to reset their PIN. I’ll end this post by looking at the end-user experience.

Configuration

Now let’s start by having a look at the required configuration to enable the I forgot my PIN option from the login screen. As the configuration of the actual settings requires the tenant ID, I divided the configuration into three steps. The first step is to find and introduce the required setting, the second step is to get the tenant ID and the third step is to use the tenant ID in the actual configuration.

Step 1: Get the required setting

The first step is to get and introduce the required setting. The PIN-related settings are part of the Windows Hello for Business settings, which can be configured by using the PassportForWork CSP. Starting with Windows 10, version 1703, that CSP contains the EnablePinRecovery node. With Windows 10, version 1703, this setting can be used to enable the I forgot my PIN option from the Settings panel and starting with Windows 10, version 1709, this setting can also be used to enable the I forgot my PIN option from the login screen.

This settings has a boolean value that enables a user to change their PIN by using the Windows Hello for Business PIN recovery service. This cloud service encrypts a recovery secret, which is stored locally on the client, and can be decrypted only by the cloud service. The default value of this setting is false. Once the administrator enables this setting, the PIN recovery secret will be stored on the device and the user can change their PIN if needed.

Step 2: Get the tenant ID

The second step is to get the tenant ID. This is super simple these days, but, as I’ve never provided the actual steps, I thought it would be smart to publish them once. To get the tenant ID, simply follow the two steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Properties;
2

tenantIDOn the Properties blade, click Copy next to Directory ID to copy the tenant ID;

Note: Just to be clear, this should be used in the OMA-URI instead of {tenantID}.

Step 3: Configure the required setting

The third step is to configure the required setting to enable the I forgot my PIN option from the login screen. In other words, the third step is to configure a device configuration profile with at least a custom OMA-URI setting. The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MIS_PINResetOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{tenantID}/Policies/EnablePinRecovery;
  • Data type: Select Boolean;
  • Value: Select True.

End-user experience

Now let’s walk through the end-user experience. On the login screen a new option is available when selecting PIN as the sign-in option, the I forgot my PIN option.

IfmP_01

When the user selects I forgot my PIN, the user will be redirected to the login experience of the identity provider. In my case ADFS.

IfmP_02

When the user provides a password and clicks on Sign-in, the user needs to provide an additional verification option, on an Azure AD branded page. In my case a text message.

IfmP_03

When the user provides the additional verification and clicks on Next, the user will be provided with an additional notification to make sure that the user is aware of the impact.

IfmP_04

When the user accept the impact of resetting the PIN and clicks Continue, the user will be provided with a dialog box to create a new PIN. Also, the user can click on PIN requirements to view the requirements for the new PIN. In my case it will show the Windows Hello for Business settings as configured in the Windows enrollment section of Microsoft Intune.

IfmP_05

When the user provided a new PIN and clicks OK, the user will be provided with the message that it’s all set. When the user than clicks on OK, the user will be redirected to the login screen.

IfmP_06

More information

For more information about Windows 10 and the (remote) PIN reset functionality, please refer to the following articles:

Deep dive ingesting third-party ADMX-files

A bit more than a week ago I got the suggestion to do a blog post about the ingestion of custom and/or third-party ADMX-files. Not without a reason. The suggestion was triggered by the latest Spectre and Meltdown vulnerabilities and the ability to manage site isolation via policies for Google Chrome. That was enough motivation for me to look into it. In this post I’ll provide an introduction to ingesting ADMX-files, followed by a step-by-step overview of how to ingest custom and/or third-party ADMX-files and how to configure the related settings. As a configuration example I’ll use the manage site isolation setting for Google Chrome. I’ll end this post with showing the configuration result.

Introduction

Starting with Windows 10, version 1703, it’s possible to ingest ADMX-files and to set those ADMX-backed policies for Win32 apps and Desktop Bridge apps, by using Windows 10 MDM. The ADMX-files that define policy information, can be ingested to the device by using OMA-URI. The ingested ADMX-files are then processed into MDM policies. When the ADMX policy settings are ingested, the registry keys, to which each policy is written, are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the locations documented here.

Configuration

Now let’s have a look at the configuration. The configuration contains two important steps. The first step is to ingest the ADMX-file and the second step is to configure the required setting. I will configure both settings on the device level.

Step 1: Ingest the ADMX-file

The first step is to ingest the ADMX-file. As this post is using Google Chrome as an example, make sure to download the Chrome policies here. Before starting with ingesting this ADMX-file, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}. In this URI the following variables should be provided:

AppName: This should be the name of the app that will be configured, but can theoretically be anything. In this example I’ll use Chrome;
SettingType: This should always be policy with ingesting ADMX-files. So, in this example I’ll use Policy;
FileUid or AdmxFileName: This should be the name of the ADMX-file, but can theoretically be anything. In this example I’ll use ChromeADMX.

Value

The value is a lot easier. That’s simply the content of the downloaded chrome.admx, which is available in the folder policy_templates\windows\admx. So, to make this really simple, open chrome.admx in an editor and press Ctrl+A, followed by Ctrl+C.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in a Device configuration profile. To do this, simply follow the three steps below and keep in mind that the OMA-URI setting (step 3b) is nothing more than just putting together the variables as mentioned in the Setting section.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

MSI_DC_CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Windows 10 – Chrome configuration;
  • Description: (Optional);
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b;
3b

MSI_DC_AddRowOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Chrome ADMX Ingestion;
  • Description: (Optional);
  • OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx;
  • Data type: Select String;
  • Value: [Complete content of the chrome.admx];

Step 2: Configure the required setting

The second step is to configure the required setting. Finding the correct values for configuring the required setting, is similar to finding the correct values for any other ADMX-backed policy. So, make sure to be familiar with my post about Deep dive configuring Windows 10 ADMX-backed policies. Before starting with the configuration, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/Config/{AppName}~{SettingType}~{CategoryPathFromADMX}/{SettingFromADMX}. Make sure to pay attention to the use of tildes in this URI. In this URI the following variables should be provided:

AppName: This should be the name of the app, as configured with the ingestion of the ADMX-file. In this example I used Chrome;
SettingType: This should be the same as configured with the ingestion of the ADMX-file. In this example I used Policy;
Chrome_CatCategoryPathFromADMX: This should be the complete category path, which actually starts with number 3 in the picture below. That shows googlechrome as the parent category. That category should be followed until the category definition of the ADMX-file, as shown with number 1 in the picture on the right. Number 2 in that same picture, shows that there is no additional parent category;
Chrome_SettingSettingFromADMX: This should be the name of the setting, which is shown with number 2 in the picture on the right. That shows SitePerProcess as the actual name of the setting. Number 2 in that same picture shows the actual registry that will be configured and which we can use to verify the result.

Value

The value is again a lot easier. In this example I simply want to enable the policy, which can be done by using <enabled/>. For more complicated settings, refer to my earlier mentioned post.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in the previously created Device configuration profile. To do this, simply follow the four steps below and assign the profile to an user group. Just like with ingesting the ADMX-file, keep in mind that the OMA-URI setting (step 4) is nothing more than just putting together the variables as mentioned in the Setting section.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;;
2 On the Devices configuration – Profiles blade, select the earlier created Windows 10 – Chrome configuration profile to open the Windows 10 – Chrome configuration blade;
3 On the Windows 10 – Chrome configuration blade, select Properties > Settings to open the Custom OMA-URI Settings blade;
4

MSI_DC_AddRow1On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK on the Custom OMA-URI blade and Save on the Windows 10 – Chrome configuration blade);

  • Name: Chrome – ADMX – SitePerProcess;
  • Description: (Optional);
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess;
  • Data type: Select String;
  • Value: <enabled/>;

Result

Let’s end this post with the result of the device configuration. The easiest location to look for a success would be Google Chrome itself, but instead I would like to show that the configuration actually arrived on the device. Below on the left is a screenshot of the Settings panel (Accounts > Access work or school > {tenant} > Info). That screenshot clearly shows the custom policy of Chrome~Policy~googlechrome. The applied custom policy doesn’t get any clearer than that. Below on the right is a screenshot of the Registry Editor. That screenshot clearly show the applied configuration, which can be matched with the registry setting in the ADMX-file (see number 2 in the picture with SettingFromADMX).

Chrome_Settings Chrome_Registry

More information

For more information about ingesting ADMX-files, refer to this article Win32 and Desktop Bridge app policy configuration.

Managing User Account Control settings via Windows 10 MDM

This blog post uses the LocalPoliciesSecurityOptions area of the Policy configuration service provider (CSP), to manage User Account Control (UAC) settings on Windows 10 devices. This area was added in Windows 10, version 1709, which is currently available as Insider Preview build.

This week a blog post about managing User Account Control (UAC) settings via Windows 10 MDM. The ability to manage UAC-settings is new in Windows 10 MDM. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP, which also contains settings to manage UAC. This is the same area, in the Policy CSP, as my last post, but this time a different group of settings. The frequent readers of my blog might recognize some bits and pieces, but that’s simply because I liked the subjects used in my previous post. That also enables me to provide more details in this post. In this post I’ll look at the available UAC-settings, in the Policy CSP, and I’ll provide information about how those settings relate to actual local group policy settings. I’ll also provide some configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone and I’ll end this post with 4 different locations that show the actual device configuration.

Available settings

Let’s start by looking at the available UAC-settings. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP. That area contains 20+ settings. Those settings are related to accounts, interactive logon, network security, recovery console, shutdown and UAC. In this post I’m specifically looking at the settings related to UAC. The table below show the available UAC-settings, the available values and a short description. For even more information about the UAC-settings, please refer to the articles in the More information section of this post.

Setting Value Description
UserAccountControl_ AllowUIAccessApplicationsToPromptForElevation 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether User Interface Accessibility (UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.
UserAccountControl_ BehaviorOfTheElevationPromptForAdministrators 0 – Elevate without prompting
1 – Prompt for credentials on the secure desktop
2 – Prompt for consent on the secure desktop
3 – Prompt for credentials
4 – Prompt for consent
5 – Prompt for consent for non-Windows binaries
This setting allows the administrator to control the behavior of the elevation prompt for administrators.
UserAccountControl_ BehaviorOfTheElevationPromptForStandardUsers 0 – Automatically deny elevation requests
1 – Prompt for credentials on the secure desktop
3 – Prompt for credentials
This setting allows the administrator to control the behavior of the elevation prompt for standard users.
UserAccountControl_ DetectApplicationInstallationsAndPrompt ForElevation 0 – Disabled

1 – Enabled

This setting allows the administrator to control the behavior of application installation detection for the computer.
UserAccountControl_ OnlyElevateExecutableFilesThatAreSigned AndValidated 0 – Disabled

1 – Enabled

This setting allows the administrator to enforce public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege.
UserAccountControl_ OnlyElevateUIAccessApplicationsThatAreInstalled InSecureLocations 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system
UserAccountControl_ RunAllAdministratorsInAdminApprovalMode 0 – Disabled

1 – Enabled

This setting allows the administrator to control the behavior of all User Account Control (UAC) policy settings for the computer.
UserAccountControl_ SwitchToTheSecureDesktopWhenPrompting ForElevation 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether the elevation request prompt is displayed on the interactive user’s desktop or the secure desktop.
UserAccountControl_UseAdminApprovalMode 0 – Disabled

1 – Enabled

This setting allows the administrator to control the behavior of Admin Approval Mode for the built-in Administrator account..
UserAccountControl_ VirtualizeFileAndRegistryWriteFailuresToPer UserLocations 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether application write failures are redirected to defined registry and file system locations.

Note: Keep in mind that every mentioned settings starts with ./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions and that any spaces used within the setting, show in the table above, should be removed.

Local group policy settings

The nice thing is that the mentioned UAC-settings, in the LocalPoliciesSecurityOptions area of the Policy CSP (./Vendor/MSFT/Policy/Config), are all related to actual local group policy settings. Those local group policy settings can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The name of the area, in the Policy CSP, simply translates to the location in the local group policies. Nice and easy. The table below shows how the available UAC-settings, actually translate to local group policy settings.

Policy CSP Local group policy setting
UserAccountControl_ AllowUIAccessApplicationsToPromptForElevation User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
UserAccountControl_ BehaviorOfTheElevationPromptForAdministrators User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
UserAccountControl_ BehaviorOfTheElevationPromptForStandardUsers User Account Control: Behavior of the elevation prompt for standard users
UserAccountControl_ DetectApplicationInstallationsAndPrompt ForElevation User Account Control: Detect application installations and prompt for elevation
UserAccountControl_ OnlyElevateExecutableFilesThatAreSigned AndValidated User Account Control: Only elevate executables that are signed and validated
UserAccountControl_ OnlyElevateUIAccessApplicationsThatAreInstalled InSecureLocations User Account Control: Only elevate UIAccess applications that are installed in secure locations
UserAccountControl_ RunAllAdministratorsInAdminApprovalMode User Account Control: Run all administrators in Admin Approval Mode
UserAccountControl_ SwitchToTheSecureDesktopWhenPrompting ForElevation User Account Control: Switch to the secure desktop when prompting for elevation
UserAccountControl_UseAdminApprovalMode User Account Control: Admin Approval Mode for the built-in Administrator account
UserAccountControl_ VirtualizeFileAndRegistryWriteFailuresToPer UserLocations User Account Control: Virtualize file and registry write failures to per-user locations

Configure settings

After getting to know the available settings, let’s have a closer look at the configuration of the settings. The settings can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below. Within the configuration guidelines, I’m using the UAC-setting to enable the behavior of Admin Approval Mode for the built-in Administrator account as an example. That requires the following OMA-URI setting and value:

OMA-URI setting: ./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/UserAccountControl_UseAdminApprovalMode
OMA-URI value: 1

Environment Configuration guidelines
Microsoft Intune hybrid IntuneH_UACSettingThe configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI setting and value.

Once the configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices/ users.

Microsoft Intune standalone (Azure portal) IntuneS_UACSettingThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile and within the new profile, make sure to select Windows 10 and later as Platform and Custom as Profile type. In the Custom OMA-URI Settings blade, add the custom settings by using the earlier mentioned OMA-URI setting and value.

Once the configurations are finished, the profile can be saved and can be deployed to Windows 10 devices/ users.

Note: This post is based on the custom OMA-URI settings configuration. At some point in time this configuration can become available via the UI of Microsoft Intune standalone and/or hybrid.

Device configuration

Like last week I’ll end this post by simply looking at the device configuration. However, this week I’ll take it one step further. This time I’ll also add some WMI and registry information. Now let’s start with, below on the left, an export of the MDM Diagnostics Information, which clearly shows the default configuration and the new configurations via MDM. Below on the right is an overview of the Local Group Policy Editor, which clearly shows the actual configuration of the new configurations via MDM. In both cases the example UAC-setting, to control the behavior of Admin Approval Mode for the built-in Administrator account, is shown in the small red circle.

UAC_MDMDiagReport_Settings UAC_LGPO_Settings

Now let’s also have a look at the information in WMI and the registry. Below on the left is an overview of the policy result node in WMI Explorer, which clearly shows the results of the configurations via MDM. Below on the right is an overview of the local group policy settings in the Registry Editor, which clearly shows the local group policy settings configured via MDM. Also, like before, in both cases the example UAC-setting, to control the behavior of Admin Approval Mode for the built-in Administrator account, is shown in the small red circle.

UAC_WMI_Settings UAC_Registry_Settings

More information

For more information about the LocalPoliciesSecurityOptions area of the Policy CSP, and about the available UAC-settings,please refer to the following articles:

Managing local policies security options for accounts via Windows 10 MDM

This blog post uses the LocalPoliciesSecurityOptions area of the Policy configuration service provider (CSP) to manage local policies security options on Windows 10 devices. This area was added in Windows 10, version 1709, which is currently available as Insider Preview build.

This week a blog post about managing local policies security options via Windows 10 MDM. More specifically, local policies security options settings related to accounts. For example, to block the usage of Microsoft accounts. I might address the other areas of the local policies security options in later blog posts, but that will be more of the same. The ability to manage local policies security options is something new in Windows 10 MDM. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP. In this post I’ll look at the available settings in the Policy CSP and I’ll provide information about how those settings related to actual local policies security options. I’ll also provide some configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone and I’ll end this post with the some examples of the actual device configuration.

Available settings

Now let’s start by having a look at the available settings. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP. That area contains 20+ settings. Those settings are related to accounts, interactive logon, network security, recovery console, shutdown and user account control. In this post I’m specifically looking at the settings related to accounts. The table below show the available settings related to accounts and the available values.

Setting Value Description
Accounts_BlockMicrosoftAccounts 0 – Disabled
1 – Enabled
This setting allows the administrator to prevent users from adding new Microsoft accounts on this computer.
Accounts_EnableAdministratorAccountStatus 0 – Disabled
1 – Enabled
This setting allows the administrator to enable the local Administrator account.
Accounts_EnableGuestAccountStatus 0 – Disabled
1 – Enabled
This setting allows the administrator to enable the Guest account.
Accounts_LimitLocalAccountUseOfBlank PasswordsToConsoleLogonOnly 0 – Disabled
1 – Enabled
This setting allows the administrator to configure whether local accounts that are not password protected can be used to log on from locations other than the physical computer console.
Accounts_RenameAdministratorAccount <string> This setting allows the administrator to configure whether a different account name is associated with the security identifier (SID) for the account Administrator.
Accounts_RenameGuestAccount <string> This setting allows the administrator to configure whether a different account name is associated with the security identifier (SID) for the account Guest.

Local group policy setting

The nice thing is that the mentioned account related settings, in the LocalPoliciesSecurityOptions area of the Policy CSP (./Vendor/MSFT/Policy/Config), are all related to actual local group policy settings. Those settings can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The name of the area, in the Policy CSP, simply translates to the location in the local group policies. Nice and easy. The table below shows how the available settings, related to accounts, actually translate to local group policy settings.

Local group policy setting Policy CSP
Accounts: Block Microsoft accounts Accounts_BlockMicrosoftAccounts
Accounts: Administrator account status Accounts_EnableAdministratorAccountStatus
Accounts: Guest account status Accounts_EnableGuestAccountStatus
Accounts: Limit local account use of blank password to console logon only Accounts_LimitLocalAccountUseOfBlank PasswordsToConsoleLogonOnly
Accounts: Rename administrator account Accounts_RenameAdministratorAccount
Accounts: Rename guest account Accounts_RenameGuestAccount

Configure settings

After getting to know the available settings, let’s have a closer look at the configuration of the settings. The settings can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

IntuneH_BlockMSAccount The configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI settings and values.

Once the configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices/ users.

Microsoft Intune standalone (Azure portal)

IntuneS_BlockMSAccountThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile and within the new profile, make sure to select Windows 10 and later as Platform and Custom as Profile type. In the Custom OMA-URI Settings blade, add the custom settings by using the earlier mentioned OMA-URI settings and values.

Once the configurations are finished, the profile can be saved and can be deployed to Windows 10 devices/ users.

Note: This post is based on the custom OMA-URI settings configuration. At some point in time this configuration can become available via the UI of Microsoft Intune standalone and/or hybrid.

Device configuration

Usually I’ll end these type of posts with the end-user experience. However, in this case it’s better to simply look at the device configuration instead. On the left is an export of the MDM Diagnostics Information, which clearly shows the default configuration and the new configurations via MDM. On the right is an overview of the Local Group Policy Editor, which clearly shows the new actual configuration of the new configuration via MDM.

MDMDiagReport_Settings LGPO_Settings

More information

For more information about the LocalPoliciesSecurityOptions area of the Policy CSP, please refer to this article about Policy CSP – LocalPoliciesSecurityOptions.

More differentiation options for device health attestation

This week a short blog post, as it’s written during my vacation, about the new differentiation options in device health attestation for compliance policies. This post is basically an addition to my post about conditional access and health attestation. Back then, a compliance policy could only check for the overall health status reported by the Health Attestation Service. That is changed now. Now it’s possible to differentiate between the different data points of the Health Attestation Service. In this post I’ll briefly go through these new configuration options for Microsoft Intune hybrid and Microsoft Intune standalone.

Configuration

Now let’s have a look at the new configuration options for the differentiation between the different data points of the Health Attestation Service. Below are the configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone. The guidelines for Microsoft Intune hybrid require Configuration Manager 1706, or later, and both guidelines also contain the configurable data points.

Environment Configuration guidelines
Microsoft Intune hybrid HAS_HybridThe configuration in Microsoft Intune hybrid can be performed by starting the Create Compliance Policy Wizard in the Configuration Manager administration console. Make sure to select Compliance rules for devices managed without Configuration Manager client on the General page and to select Windows 10 on the Supported Platforms page. Now select New on the Rules page and the condition Reported as healthy by Health Attestation Service can be added. After selecting the condition it’s possible to configure the required status per data point. This includes BitLocker, Secure Boot, Code Integrity and Early Launch Anti-Malware (ELAM).

Microsoft Intune standalone (Azure portal)

HAS_StandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device compliance policy. Create a new policy, select Windows 10 and later as Platform and select Settings > Device Health. This enables the configuration of the the required status per data point of the Health Attestation Service. This includes BitLocker, Secure Boot and Code Integrity.

Note: This enables new scenarios in which it’s possible to not require BitLocker on VMs, or in which it’s possible to not require ELAM due to it’s quirks with hibernation.

Easily configuring Windows Update for Business via Windows 10 MDM

This week a blog post about easily configuring Windows Update for Business (WUfB). I call it easily, as I did a post about something similar about a year ago. That time It was required to configure everything with custom OMA-URI settings. Starting with Configuration Manager 1706, an easier configuration option is available for the most important settings, by using the Configuration Manager administration console. For Microsoft Intune standalone this was already available for a while. In this post I’ll walk through the easy configuration options for Microsoft Intune hybrid and standalone and I’ll end this post with the end-user experience.

Configuration

Now let’s start by walking through the configuration steps for Microsoft Intune hybrid and standalone. However, before doing that it’s good to mention that at this moment Microsoft Intune hybrid and standalone still use the “old” branch names and are not yet updated to the “new” channel name(s). Also, keep in mind that currently not all the WUfB-settings are easily configurable. There are even differences between Microsoft Intune hybrid and standalone. Having mentioned that, every WUfB-setting, available in the Policy CSP, can also still be configured via custom OMA-URI settings.

Microsoft Intune hybrid

The configuration for Microsoft Intune hybrid must be done by using the Configuration Manager console. Simply walking through the wizard as shown below, will create the required policy. The policy can be deployed like a configuration baseline. The nice thing about the created policy is that it can be applied to devices managed via MDM and devices managed with the Configuration Manager client. The focus of this post is the devices managed via MDM.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Windows 10 Servicing > Windows Update for Business Policies;
2 On the Home tab, click Create Windows Update to Business Policy to open the Create Windows Update to Business Policy Wizard;
3 On the General page, provide unique name (max 200 characters) and click Next;
4

CWUfBPW_DefPolOn the Deferral Policies page, configure the following settings and click Next.

  • Defer Feature Updates
    • Branch readiness level: Select Current Branch or Current Branch for Business;
    • Deferral period (days): Select a value between 0 and 180;
    • Select Pause Feature Updates starting to prevent feature updates from being received on their schedule;
  • Defer Quality Updates
    • Deferral period (days): Select a value between 0 and 30;
    • Select Pause Quality Updates starting to prevent quality updates from being received on their schedule;
  • Select Install updates from other products to make the deferral settings applicable to Microsoft Update as well as Windows Updates;
  • Select Include drivers from Windows updates to also update drivers from Windows Updates.
5 On the Summary page, click Next;
6 On the Completion page, click Close;

Note: At this moment the policy can only be deployed to devices.

Microsoft Intune standalone

The configuration for Microsoft Intune standalone must be done by using the Azure portal. Simply walking through the blades, as shown below, will create the required update ring. The update ring can be assigned, after the creation, like anything else created in the Azure portal.

1 Open the Azure portal and navigate to Intune > Software Updates > Windows 10 Update Rings;
2 On the Windows 10 Update Rings blade, select Create to open the Create Update Ring blade;
3 On the Create Update Ring blade, provide unique name and select Settings to open the Settings blade;
4

W10UR_SettingsOn the Deferral Policies page, configure the following settings and select OK to return to the Create Update Ring blade.

  • Servicing branch: Select CB or CBB;
  • Microsoft product updates: Select Allow or Block;
  • Windows drivers: Select Allow or Block;
  • Automatic update behavior: Select Notify download, Auto install at maintenance time, Auto install and restart at maintenance time, Auto install and restart at a scheduled time or Auto install and reboot without end-user control;
  • Active hours start: Choose a time between 12 AM and 11 PM;
  • Active hours end: Choose a time between 12 AM and 11 PM;
  • Quality update deferral period (days); Provide a value between 0 and 30;
  • Feature update deferral period (days): Provide a value between 0 and 180;
  • Delivery optimization: Select HTTP only, no peering, HTTP blended with peering behind same NAT, HTTP blended with peering across private group, HTTP blended with internet peering, Simple download mode with no peering or Bypass mode.

Note: Depending on the choice made with Automatic update behavior, Active hours start and Active hours end can change to Scheduled install day and Scheduled install time.

5 Back on the Create Update Ring blade, select Create;

Note: It’s good to mention that it’s also possible to use the pause functionality for quality and feature updates without using custom URI settings. That can be achieved by selecting the created update ring and choosing Pause Quality or Pause Feature.

End-user experience

Important: The end-user experience is based on the current experience on Windows 10, version 1709 (RS3), which is currently available as Insider Preview build (build 16251).

I used Windows 10, version 1709 (RS3), for the end-user experience as it provides a clear view on the applied update policies. The examples below are based on the available settings in the different consoles. Below on the left is of a Microsoft Intune hybrid environment and below on the right is of a Microsoft Intune standalone environment. The show overview is available by navigating to Settings > Update & security > Windows Update > View configured update policy.

Configured_Hybrid Configured_Standalone

Another interesting place to look, is the registry. This is on the end-user device, but is more of interest for administrators. Starting with Windows 10, version 1607, the WUfB-configuration, configured via MDM, is available in the registry via HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\current\device\Update. The examples below are based on the available settings in the different consoles. Below on the left is of a Microsoft Intune hybrid environment and below on the right is of a Microsoft Intune standalone environment.

Registry_Hybrid Registry_Standalone

More information

For more information about Windows Update for Business  and how it can be configured via Microsoft Intune hybrid and standalone, please refer to the following articles:

Set default app associations via Windows 10 MDM

This blog post will be about setting default app associations, or file type associations, on Windows 10 devices. Starting with Windows 10, version 1703, it’s possible to set the default app associations via Windows 10 MDM. In this post I’ll briefly go through this setting and I’ll show how to configure the setting via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

Starting with Windows 10, version 1703, a new setting was introduced that allows an administrator to set the default file type and protocol associations. When set, default associations will be applied on sign-in to the PC. Every sign-in. In other words, the end-user can make adjustments. However, once the end-user signs-out and signs-in again, the default associations will be applied again. This does require the PC to be Azure AD joined.

Get the required information

Let’s start by getting the required information to configure the custom OMA-URI setting. The required OMA-URI setting is available in the Policy CSP.

OMA-URI setting: ./Vendor/MSFT/Policy/Config/ApplicationDefaults/DefaultAssociationsConfiguration

The required OMA-URI value requires the following steps to get it in the correct format.

1 On Windows 10, version 1703, navigate to Settings > Apps > Default apps and configure the required default apps;
2 Open Command Prompt and run DISM /Online /Export-DefaultAppAssociations:DefAppAss.xml to export a required app associations file;
3

Base64Encode_orgOpen your favorite Base64 encoder and encode the content of DefAppAss.xml to Base64 format.

In my example I was only interested in switching to Internet Explorer as the default browser and keeping Microsoft Edge as the default for PDF reading. That allowed me to remove all the remaining content from the DefAppAss.xml. Then I used base64encode.org to easily encode the remaining content of the DefAppAss.xml to Base64 format (see screenshot).

4 The result in Base64 format is the OMA-URI value.

Configure the setting

After getting the required information, let’s have a closer look at the configuration of the setting. The setting can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

DefAppAss_MIhThe configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI setting and value.

Once the configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices.

Microsoft Intune standalone (Azure portal)

DefAppAss_MIsThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile, or add a row to an existing custom profile. With a new profile, make sure to select Windows 10 and later as Platform and Custom as Profile type. In the Custom OMA-URI Settings blade, add the custom settings by using the earlier mentioned OMA-URI setting and value.

Once the configurations are finished, the profile can be saved and can be deployed to Windows 10 devices.

Note: This post is based on the custom OMA-URI settings configuration. At some point in time this configuration can come available via the UI of Microsoft Intune standalone and/or hybrid.

End-user experience

Now let’s end this post by having a quick look at the end-user experience. Below on the left is the default Windows configuration and below on the right is the applied policy with the custom app associations. I know that this doesn’t provide a lot of information. However, it does show one important fact, which is that there is nothing preventing the end-user from making adjustments. The end-user can still make adjustments, but those adjustments will be reverted during the next sign-in.

DefaultBrowser_Edge DefaultBrowser_IE

More information

For more information about the Policy CSP, please refer to this article about the Policy CSP.