Enable Windows Automatic Redeployment from the login screen

This week a short post about enabling Windows Automatic Redeployment form the login screen. It’s a follow up on enabling password reset and PIN reset from the login screen, as it enables another feature on the login screen, and a nice addition in combination with Windows AutoPilot. Windows Automatic Redeployment might be a familiar feature, but I couldn’t find much written information about it yet. In this post I’ll provide a brief introduction to Windows Automatic Redeployment, followed by the required configuration and the end-user experience.

Introduction

Now let’s start with a brief introduction about Windows Automatic Redeployment. Starting with Windows 10, version 1709, administrators can use Windows Automatic Redeployment to quickly remove personal files, apps, and settings, by resetting Windows 10 devices from the login screen at any time. That reset will apply the original settings and device management enrollment, so the devices are ready to use once the reset is completed. The device management enrollment is related to Azure Active Directory and Microsoft Intune (or other third-party MDM-providers).

In other words, Windows Automatic Redeployment allows administrators to reset devices to a known good managed state while preserving the management enrollment. After Windows Automatic Redeployment is triggered, the devices are ready for use by standard users.

Configuration

The configuration actually only contains one specific setting. To get that specific setting, the first step explains the location of the setting and the second step explains the usage of the setting.

Step 1: Get the required setting

The first step is to get the required setting. The Policy CSP contains CredentialProvider policies. One of those policies is DisableAutomaticReDeploymentCredentials. That policy is introduced in Windows 10, version 1709, and is used to enable or disable the visibility of the credential provider that triggers the reset on a device. This policy does not actually trigger the reset. This policy enables the administrator to authenticate and trigger the reset on the device. This setting supports the following values:

  • 0 – Enable the visibility of the credentials for Windows Automatic Redeployment;
  • 1 – Disable visibility of the credentials for Windows Automatic Redeployment.

Step 2: Configure the required setting

The second step is to actually configure the required setting to enable the option to automatically redeploy Windows from the login screen. In other words, the second 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

MSIntune_WAROn 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: ./Vendor/MSFT/Policy/Config/CredentialProviders/DisableAutomaticReDeploymentCredentials;
  • Data type: Select Integer;
  • Value: 0.

End-user experience

Let’s end this post by looking at the end-user experience. I’ll do that by showing how to trigger Windows Automatic Redeployment, followed by a screenshot of the start of the process and a screenshot of the end of the process.

To trigger the Windows Automatic Redeployment, press the combination of Ctrl +Windows key+ R on the login screen. As shown below, this will provide the user with the option to provide an administrator account to automatically redeploy Windows.

Windows_Redeploy_01

Once administrator credentials are provided the redeployment process will be triggered. As shown below, when the process is finished a success message will be shown.

Windows_Redeploy_02

Now the device is ready to go. Keep in mind that the device is still Azure AD joined and Microsoft Intune managed with the original account. So, the main use case for this reset is for information workers and students.

More information

For more information about Windows Automatic Redeployment, please refer to this article about resetting devices with Windows Automatic Redeployment.

Enable password reset from the login screen

This week is about something similar as last week. This week is all about the password reset option on the login screen. In other words, the Reset password option. Starting with Windows 10, version 1709, it’s possible to enable the Reset password option from the login screen for Azure AD joined devices. I know that a lot has been written already about this subject, but I have the feeling that this subject needs a place on my blog. My style and more details. In this post I’ll provide a short introduction about Azure AD self-service password reset (SSPR), followed by walking through the required configurations for SSPR and the Reset password option. I’ll end this post by looking at the end-user experience.

Introduction

Now let’s start this post with an introduction about Azure AD SSPR. With SSPR users can reset their passwords on their own when and where they need to. At the same time, administrators can control how a user’s password gets reset. That means that the user no longer needs to call a help desk just to reset their password. SSPR includes (the focus of this post is number 2):

  1. Self-service password change: The user knows their password but wants to change it to something new;
  2. Self-service password reset: The user is unable to sign in and wants to reset their password by using one or more of the following validated authentication methods:
    • Send a text message to a validated mobile phone;
    • Make a phone call to a validated mobile or office phone;
    • Send an email to a validated secondary email account;
    • Answer their security questions.
  3. Self-service account unlock: The user is unable to sign in with their password and has been locked out. The user wants to unlock their account without administrator intervention by using their authentication methods.

Configuration

Let’s continue by having a look at the required configuration, to enable the Reset password option from the login screen. As the configuration of the actual settings requires SSPR to be enabled, I divided the configuration into two steps. The first step is to enable SSPR and the second step is to configure the Reset password option.

Step 1a: Enable SSPR

The first step is to enable SSPR, as it’s the starting point for enabling the Reset password option from the login screen. Without SSPR enabled, and still configuring the Reset password option, the user will receive a message that SSPR is not enabled for the user and that the user should contact the administrator. The following seven steps walk through the relatively simple configuration to enable SSPR.

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

AAD_PR_PropertiesOn the Password reset – Properties blade, select All and click Save;

3

AAD_PR_AuthOn the Password reset – Authentication methods blade, select the number of required methods to reset and the available methods to user and click Save;

Note: Make sure that you have at least as many methods available to users as you have required to reset.

4

AAD_PR_RegistrationOn the Password reset – Registration blade, configure whether or not to require users to register when signing in and click Save;

5

AAD_PR_NotificationsOn the Password reset – Notifications blade, configure the notification settings and click Save;

6

AAD_PR_CustomizationsOn the Password reset – Customization blade, configure the customization settings and click Save;

7

AAD_PR_OnPremOn the Password reset – On-premises integration blade, and configure the password write back configuration and click Save;

Note: This is required when using an on-premises directory and also requires the configuration of step 1b.

Step 1b: (Optional) Configure password writeback

Another part of the first step is the optional configuration of password writeback. This should be configured to write the passwords from Azure AD back to the on-premises directory. To achieve this, use the following seven steps to reconfigure Azure AD Connect.

1 On the Azure AD Connect server, start Azure AD Connect to open the Microsoft Azure Active Directory Connect wizard;
2 On the Welcome page, click Configure;
3 On the Additional tasks page, select Customize synchronization options and click Next;
4 On the Connect to Azure AD page, provide the required credentials and click Next;
5 On the Connect Directories page, click Next;
6 On the Domain/OU Filtering page, click Next;
7

MAADC_OptionalFeaturesOn the Optional Features page, select Password writeback and click Next;

Note: I’ve also got Device writeback configured, which causes the next page to appear.

8 (Optional) On the Writeback page, click Next;
9 On the Configure page, click Configure and once completed click Exit;

Step 2: Enable Reset password option

The second step is to configure the required setting to enable the Reset password option from the login screen. In other words, the second step is to configure a device configuration profile with at least a custom OMA-URI setting. The required setting is part of the Authentication node of the Policy CSP. It’s the AllowAadPasswordReset policy. That policy allows administrators to enable the self-service password reset feature on the windows logon screen. An integer value of 0 means not enabled and an integer value of 1 means enabled.

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

MSI_AllowPasswordResetOn 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/Policy/Config/Authentication/AllowAadPasswordReset;
  • Data type: Select Integer;
  • Value: 1.

Note: For testing purposes it’s also possible to configure the Reset password option by using the HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount registry key with the value, type and data of AllowPasswordReset, REG_DWORD and 1.

End-user experience

Now let’s end this post by walking through the end-user experience. On the login screen a new option is available when selecting password as the sign-in option, the Reset password option.

RP_01

When the user selects Reset password, the user will be redirected to the Azure AD self-service password reset service.

RP_02

The User ID is already prepopulated and when the user clicks on Next, the user should choose a verification method. In my case a text to my mobile phone.

RP_03

When the user provides the correct mobile phone number and clicks on Next, the user must provide the actual verification code of the text message.

RP_04

When the user provides the correct verification code and clicks on Next, the user must provide a new password.

RP_05

When the user provides a new password and clicks Next, the user will be provided with the message that the password has been reset. When the user than clicks on Finish, the user will be redirected to the login screen.

RP_06

More information

For more information about SSPR, Windows 10 and the Reset password option, 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.

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.

Deep dive configuring Windows 10 ADMX-backed policies

A couple of weeks ago, I did a my blog post about configuring a Windows 10 ADMX-backed policy. That time I used a relatively easy setting to configure and I briefly mentioned how to configure a more advanced setting. That raised some questions, which triggered me to do a deep dive in configuring those more advanced settings. In this blog post I’ll show, in a step-by-step overview,  how to construct the OMA-URI setting and value for a more advanced setting.

Setting

I’ll use the ClientConnectionEncryptionLevel setting as an example again. A big difference with the previous time is that the docs are greatly improved. By default, the docs now already provide information about the corresponding Group Policy setting and the location of the Group Policy setting. The docs already provide the following information about the settings.

MDM CSP setting path/ name
RemoteDesktopServices\ClientConnectionEncryptionLevel
Group Policy English name
Set client connection encryption level
Group Policy English category path
Windows Components\Remote Desktop Services
Group Policy name
TS_ENCRYPTION_POLICY
Group Policy ADMX file name
terminalserver.admx

Value

The default information in the docs make it relatively easy to find the required setting and it’s basic values. Now let’s go through the steps to find all the required information for more advanced settings. A more advanced setting, to me, is a setting that must be enabled and requires additional data.

Step 1: Enable the setting

Let’s start with the first step, which is enabling the setting. The following steps will go through the steps to find the Group Policy setting and enabling it.

1 Open the Group Policy Management Editor and navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security;
2 Right-click the setting Set client connection encryption level and select Edit;
3

GPO_SetClientConnectionEncryptionLevel_1In the Set client connection encryption level dialog  box, it’s possible to enable and disable the setting. After enabling the setting it shows an advanced setting to configure, the Encryption Level. In this example I want to enable the setting. That means that I need to use <enabled/> as value for my OMA-URI setting. However, as the advanced setting needs an additional data element, I also need to find the appropriate data for that element.

Step 2: Configure the setting

The next step is the advanced configuration of the Group Policy setting. The following steps will go through finding the available values and how those values can be used in a OMA-URI setting.

1 Open TerminalServer.admx and navigate to the TS_ENCRYPTION_POLICY policy setting;
2

TerminalServerADMXThe <elements> section contains the configurable data elements and its possible values. As shown on the right, the configurable data element is named TS_ENCRYPTION_LEVEL and the configurable values are:

  • 1 = TS_ENCRYPTION_LOW_LEVEL;
  • 2 = TS_ENCRYPTION_CLIENT_COMPATIBLE;
  • 3 = TS_ENCRYPTION_HIGH_LEVEL.
3 Open TerminalServer.adml and navigate to the TS_ENCRYPTION_POLICY string;
4

TerminalServerADMLThe ADML contains the readable string of the display names mentioned in the ADMX. Around the TS_ENCRYPTION_POLICY string I can see the following display names for the previously mentioned values:

    • TS_ENCRYPTION_LOW_LEVEL =  Low Level;
    • TS_ENCRYPTION_CLIENT_COMPATIBLE = Client Compatible;
    • TS_ENCRYPTION_HIGH_LEVEL = High Level.
5

GPO_SetClientConnectionEncryptionLevel_2Back to the Set client connection encryption dialog box, I can now translate the available configuration options to values for my OMA-URI setting. When I compare the TerminalServer.admx (and TerminalServer.adml) with the available configuration options, I can translate them like this:

  • Client Compatible = 2;
  • High Level = 3;
  • Low Level = 1.
6 Putting the advanced setting and its available configurations together, gives me the following data element for configuring the Encryption Level to Low Level: <data id=”TS_ENCRYPTION_LEVEL” value=”1″/>;

Step 3: Complete setting

Now I can put step 1 and step 2 together and enable the setting and configure the required additional configuration. When I want to enable Set client connection encryption level and set the Encryption Level to Low Level, I can use the following value for the OMA-URI setting: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.

Result

Let’s have a look at the result, when I’m configuring the following OMA-URI setting:

  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/ClientConnectionEncryptionLevel
  • Date type: String
  • Value: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>

As I’m basically configuring Group Policy settings, the best place to look for a successful configuration is the registry. Below on the left is another look at the TerminalServer.admx in which I show the registry key that will be configured. On the right I show the configured registry key and it’s value.

TerminalServerADMX_Reg TerminalServer_Reg

Allow users to connect remotely to this computer via Windows 10 MDM (ADMX-style)

This week another blog post about new MDM capabilities that are introduced in Windows 10, version 1703. This post is focused on enabling the setting to allow users to connect remotely to this computer via Remote Desktop. To enable that specific setting, Windows 10, version 1703, introduced ADMX-backed policy via the Policy CSP. In this post I’ll provide a short introduction about ADMX-backed policies, which is actually a short summary of the Microsoft docs, and I’ll show a configuration example. I’ll end this post by showing the end-user experience.

Introduction

Starting with Windows 10, version 1703, the Policy CSP can now also handle ADMX-backed policies. In an ADMX-backed policy, an administrative template contains the metadata of a GPO. Each administrative template specifies the registry keys, and their values, that are associated with a GPO and defines the policy settings that can be managed. Each setting in an administrative template corresponds to a specific registry value. Windows maps the name and category path of a GPO to a MDM policy area, and policy name, by parsing the associated ADMX-file, finding the specified GPO, and storing the metadata in the Policy CSP. When the MDM policy is referenced, this metadata is referenced and determines which registry keys are set or removed.

Configuration

Now let’s have look at the configuration for enabling the setting to allow users to connect remotely to this computer. I’ll do that by first going through the available settings, related to Remote Desktop, and getting the required values. After that I’ll put those two together in a configuration example.

Available settings

As Windows 10, version 1703, introduced a few new settings to manage Remote Desktop, I thought it would be good to briefly go through these new settings. The root node for the Remote Desktop related settings is, in the Policy CSP, ./Vendor/MSFT/Policy. The Remote Desktop related settings are grouped below ./Vendor/MSFT/Policy/Config/RemoteDesktopServices and contains the following settings.

Setting Description
AllowUsersToConnectRemotely This setting allows the administrator to configure remote access to computers by using Remote Desktop Services.
ClientConnectionEncryptionLevel This setting allows the administrator to specify whether to require the use of a specific encryption level.
DoNotAllowDriveRedirection This setting allows the administrator to specify whether to prevent the mapping of client drives in a Remote Desktop Services session (drive redirection).
DoNotAllowPasswordSaving This setting allows the administrator to control whether passwords can be saved on this computer from Remote Desktop Connection.
PromptForPasswordUponConnection This setting allows the administrator to specify whether Remote Desktop Services always prompts the client for a password upon connection.
RequireSecureRPCCommunication This setting allows the administrator to specify whether a Remote Desktop Session Host server requires secure RPC communication with all clients.

Available values

Now that I’ve been through the available settings related to Remote Desktop, let’s have closer look at the setting that enables the administrator to allow users to connect remotely to this computer. That’s the setting AllowUsersToConnectRemotely.

To get the available values for the AllowUsersToConnectRemotely setting, it’s good to double-check the configuration options in the local Group Policy Editor. The related GPO setting is named Allow users to connect remotely by using Remote Desktop Services and can be found at Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections. That shows that the only available values are Not Configured, Enabled and Disabled. Related to ADMX-backed policies, this translates to a value of <enabled /> or <disabled />. AllowRDP_GPO

Note: When a setting contains more configuration options, like the ClientConnectionEncryptionLevel setting, which relates to the Set client connection encryption level setting, then it’s required to dive into the ADMX-file that contains the GPO setting. The ADMX-file contains the available elements that are required when the setting is enabled. In this case the TerminalServer.admx. Minor detail, this ADMX-file doesn’t contain readable information related to the required setting. To find the related setting in that AMDX-file, my advise is to first find the setting in the related AMDL-file. In this case the TerminalServer.adml. That file contains readable information and shows the name of the setting in the ADMX-file. In this case the setting is TS_ENCRYPTION_POLICY. The additional element for that setting is TS_ENCRYPTION_LEVEL and the available values for that element are 1, 2 and 3. Every element must show as data in the ADMX-backed policy. Related to ADMX-backed policies, this could translate to a value of <enabled /><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.

Together this means that to  enable the setting to allow users to connect remotely to this computer, the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/AllowUsersToConnectRemotely
  • Date type: String
  • Value: <enabled />

Configure settings and values

Let’s put the setting and values together. Together this information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

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

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)

AllowRDP_IntuneStandaloneThe 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 settings.

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

End-user experience

Let’s end this post with the end-user experience. This time I’ll do that by showing the configuration in the user interface and in the registry. Like with configuring the setting to allow users to connect remotely  to the computer, via GPO, the Allow remote connections to the computer setting is enabled and grayed-out, as shown below on the right. This also corresponds to the registry setting fDenyTSConnections at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services, as shown below on the right. As these are ADMX-backed policies, the settings are configured in the registry.

AllowRDPReg_MDM AllowRDPScr_MDM

More information

For more information about ADMX-backed policy and the Policy CSP, please refer to:

Easily configure Start via Windows 10 MDM

This blog post is about the ability to configure Start on Windows 10 devices. Mainly focused on Windows 10 Desktop devices. Before Windows 10, version 1703, it was already possible to configure the layout of Start by using the StartLayout setting. Windows 10, version 1703, introduces many, many more settings related to configuring Start via Windows 10 MDM. All of these settings are available via the existing Policy CSP. These new settings range from configuring settings available in the Settings panel until configuring settings related to the Power button and the user tile.

In this post I’ll go through almost all newly introduced settings and I’ll briefly show how to configure these settings by using Microsoft Intune hybrid and standalone. I’ll end this post by showing the effect of the configured settings for the end-user.

Available settings

As Windows 10, version 1703, introduced many new settings to manage Start, I thought it would be good to briefly go through these new settings. The root node for the Start related settings is, in the Policy CSP, ./Vendor/MSFT/Policy. The Start related settings are grouped below ./Vendor/MSFT/Policy/Config/Start and contains the following settings.

Setting Value Description
ForceStartSize 0 – Do not force
1 – Force non-fullscreen
2 – Force fullscreen
This setting allows the administrator to force the Start screen size
HideAppList* 0 – None
1 – Hide all app list
2 – Hide and disable
3 – Hide, remove and disable
This setting allows the administrator to configure Start by collapsing or removing the all app list.
HideChangeAccountSettings 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Change account settings option from the user tile.
HideFrequentlyUsedApps* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the the most used apps.
HideHibernate 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Hibernate option from the Power button.
HideLock 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Lock option from the user tile.
HidePowerButton* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the the Power button.
HideRecentJumplists* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Recently used items option from the jumplists.
HideRecentlyAddedApps* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the recently added apps.
HideRestart 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Restart option from the Power button.
HideShutDown 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Shutdown option from the Power button.
HideSignOut 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Sign out option from the user tile.
HideSleep 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Sleep option from the Power button.
HideSwitchAccount 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Switch account option from the user tile.
HideUserTile* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the user tile.
NoPinningToTaskbar 0 – Pinning enabled
1 – Pinning disabled
This setting allows the administrator to configure the taskbar by hiding the option to pin and unpin apps on the taskbar.

*Setting requires restart to take effect.

Configure settings

After going through the available settings in the Start node, of the Policy CSP, let’s have a closer look at the configuration of those settings. These available 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

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

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)

Start_IntuneStandAloneThe 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 settings.

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

Effective settings

Let’s end this post with the end-user experience. However, I’ll do that a bit different as I usually do. I’ll do that by showing the settings, and options, that are affected by the available settings.

Start_SettingsThe first section of configurable settings are all related to settings in the Settings panel. More specifically, Settings > Personalization > Start. In this section the following settings can be configured (as shown in the screenshot):

  • HideAppList;
  • HideRecentlyAddedApps;
  • HideFrequentlyUsedApps:
  • ForceStartSize;
  • HideRecentJumpLists.

Note: I’ve had some issues with configuring the HideAppList setting.

Start_PowerButtonThe second section of configurable settings are all related to the Power button. I’ll show these settings, by showing the available options of the Power button and the related setting. In this section the following settings can be configured (as shown in the screenshot):

  • HideSleep:
  • HideHibernate;
  • HideShutdown;
  • HideRestart;
  • HidePowerButton.

Start_UserTileThe third section of configurable settings are all related to the user tile. I’ll show these settings, by showing the available options of the user tile and the related setting. In this section the following settings can be configured (as shown in the screenshot):

  • HideChangeAccountSettings;
  • HideLock;
  • HideSignOut;
  • HideSwitchAccount;
  • HideUserTile.

More information

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