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
Share

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:

Share

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.

Share

Easily configure desktop and lock screen image via Windows 10 MDM

This blog post uses the Personalization configuration service provider (CSP) to manage the desktop and lock screen image on Windows 10 devices. This CSP was added in Windows 10, version 1703, which is currently available as Insider Preview build.

This blog post is about the ability to easily configure separate images for the desktop and the lock screen on Windows 10 devices. Before Windows 10, version 1703, this was possible by using an MSI or by using the EnforceLockScreenAndLogonImage setting. However, the latter setting was only able to configure the lock screen image and not the desktop image. Windows 10, version 1703, introduces the Personalization CSP, which enables the administrator to manage the desktop and lock screen image. In this post I’ll briefly go through the available settings in the Personalization CSP and I’ll show how to configure the desktop and lock screen image via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

Now let’s start with the configuration. Like last week I’ll split the configuration in two sections. The first section is about the available settings in the Personalization CSP and the second section is about the configuration of the desktop and lock screen image.

Available settings

As the Personalization CSP is new in Windows 10, version 1703, I thought it would be good to briefly go through the available settings. The root node for the Personalization CSP is ./Vendor/MSFT/Personalization and it contains the following settings.

Setting Description
DesktopImageUrl This setting allows the administrator to specify an image to be used as desktop image.
DesktopImageStatus This setting allows the administrator to query the status of the desktop image.
LockScreenImageUrl This setting allows the administrator to specify an image to be used as lock screen image. 
LockScreenImageStatus This setting allows the administrator to query the status of the lock screen image.

Configure settings

After going through the available settings in the Personalization CSP, it’s good to know that only the DesktopImageUrl and the LockScreenImageUrl are configurable settings. The other two settings can only be used to query the status. To configure the desktop and lock screen image, the following OMA-URI configurations can be used (in both cases the data type and value are the same):

  • OMA-URI – Desktop image: ./Vendor/MSFT/Personalization/DesktopImageUrl
  • OMA-URI – Lock screen image: ./Vendor/MSFT/Personalization/LockScreenImageUrl
  • Data type: String
  • Value: [<PATH>\<FILE>]
    • In this value <PATH> can be a http(s) url, or a file url;
    • In this value <FILE> can be a jpg, jpeg or png image.

This configuration 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

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

Personalization_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

As usual, let’s end this post with the end-user experience. Before really going to the end-user experience, it’s good to show an easy method to verify the configuration. The configuration can be verified In the registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP. At this location it shows the url and the status of the desktop and lock screen image. Even better, it also show the local path of both images. In other words, whether the image is local, or remote, it will always be cached and used from a local location, as shown below.

Registry_Personalization

The real end-user experience is, of course, not in the registry. The real en-user experience can be easily found when logging on to the configured Windows 10 device. The desktop image will be configured, as shown below on the right, and the lock screen image will be configured, as shown below on the left.

LogonScreen_Example Desktop_Example

More information

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

Share

Offboard Windows 10 devices of Windows Defender Advanced Threat Protection

This week a follow-up on my post of last week. Last week was about onboarding Windows 10 devices for Windows Defender Advanced Threat Protection (ATP) and this week will be about offboarding Windows 10 devices of Windows Defender ATP. For devices that are leaving the company, for whatever reason, it’s good to first offboard those devices of Windows Defender ATP. That will remove the Windows Defender ATP settings from the device and the device will stop collecting and sending data. In this post I’ll show how to offboard Windows 10 devices, via Configuration Manager and Microsoft Intune, and I’ll show the end result. The steps in this post will be similar to the steps in the post of last week.

Configuration

Just like last week, there are multiple methods available to offboard Windows 10 devices of Windows Defender ATP. Those methods are Group Policy, Configuration Manager, mobile device management (including Microsoft Intune) and a local script. I’ll have a closer look at the configurations for offboarding Windows 10 devices via Configuration Manager and Microsoft Intune.

Create offboarding configuration file

Before starting with the configuration, it’s required to create an offboarding configuration file. The process for this is fairly simple and straightforward. Logon to the Windows Defender Security Center and select Endpoint Management. Now select Endpoint offboarding, select the configuration method and download the required file, as shown below. After selecting download, an additional confirmation message will show, mentioning the expiration date of the offboarding package. For security reasons an offboarding package will always expire after 30 days.

System Center Configuration Manager Mobile Device Management
WDATP_SCCM_Offboarding WDATP_MDM_Offboarding

Configure endpoints using Configuration Manager

The first configuration method that I would like to show is using Configuration Manager, by creating and deploying a Windows Defender ATP Policy.  This configuration method is only supported on Windows 10 devices, version 1607 and later, running the Configuration Manager client. On-premises mobile device management and Microsoft Intune hybrid MDM-managed computers are not supported. The following 6 steps show how to create the Windows Defender ATP Policy. After that, simply deploy the created policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Endpoint Protection > Windows Defender ATP Policies;
2 On the Home tab, in the Create group, click Create Windows Defender ATP Policy to open the Create Windows Defender ATP Policy Wizard;
3

CWDATPPW_General_OffOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Defender ATP policy;
  • Description: (Optional) Provide a description about the Windows Defender ATP policy;
  • Select Offboarding – Remove devices from the online service (for example, when the device is no longer managed).
4

CWDATPPW_ConfigFile_OffOn the Configuration File page, Browse to the WindowsDefenderATP.offboarding file that is available in the downloaded WindowsDefenderATPOffboardingPackage.zip file and click Next;

Note: The default name of the offboarding package, also contains the expiration date of the offboarding package.

5 On the Summary page, click Next;
6 On the Completion page, click Close.

Note: Make sure that a device is not targeted with an onboarding and offboarding configuration at the same time. This might cause unpredictable behavior.

Configure endpoints using Microsoft Intune

The second configuration method that I would like to show is using Microsoft Intune hybrid and Microsoft Intune standalone, Windows Defender ATP supports Microsoft Intune by providing OMA-URI settings to create policies to manage endpoints. To achieve this the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding
  • Date type: String
  • Value: [Content of the WindowsDefenderATP.offboarding file that is available in the downloaded WindowsDefenderATPOffboardingPackage_valid_until_yyyy-mm-dd.zip file]

Just to make sure that it’s absolutely clear, the value, of the OMA-URI configuration, is literally a copy-paste action of the content available in the WindowsDefenderATP.offboarding file. 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

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

CIRule_WindowsATP_OffboardingIn this case, I also provide a screenshot of the configured rule. Again to make absolutely sure that it’s a lot of characters that the rule should comply to.

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

CP_WindowsATP_OffboardingThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

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

Note: Make sure that a device is not targeted with an onboarding and offboarding configuration at the same time. This might cause unpredictable behavior.

End result

Let’s end this blog post by having a look at the end result. I’ll do that by showing that a successful offboarding can be verified in the registry of the Windows 10 device, as shown below. The OnboardingState should be set to 0.

WDATP_Registry_Offboarding

More information

For more information about Windows Defender ATP and the offboarding, please refer to the following articles:

Share

Onboard Windows 10 devices for Windows Defender Advanced Threat Protection

This week a blog post about onboarding Windows 10 devices for Windows Defender Advanced Threat Protection (ATP). Windows Defender ATP is a relatively new service that will help enterprises to detect, investigate, and respond to advanced attacks on their networks. In this post I’ll show how to onboard Windows 10 devices, via Configuration Manager and Microsoft Intune, and I’ll show the end result in the Windows Defender Security Center and the Configuration Manager administration console.

Configuration

There are multiple methods available to onboard Windows 10 devices for Windows Defender ATP, Group Policy, Configuration Manager, mobile device management (including Microsoft Intune) and a local script. I’ll have a closer look at the configurations for onboarding Windows 10 devices via Configuration Manager and Microsoft Intune.

Create onboarding configuration file

Before starting with the configuration, it’s required to create an onboarding configuration file. The process for this is fairly simple and straightforward. Logon to the Windows Defender Security Center and select Endpoint Management. Now simply select the configuration method and download the required file, as shown below.

System Center Configuration Manager Mobile Device Management
WDATP_SCCM_Enrollment WDATP_MDM_Enrollment

Configure endpoints using Configuration Manager

The first configuration method that I would like to show is using Configuration Manager, by creating and deploying a Windows Defender ATP Policy. By adding and deploying a client onboarding configuration file, via the Windows Defender ATP Policy, Configuration Manager can monitor the deployment status and the  Windows Defender ATP agent health. Windows Defender ATP is only supported on Windows 10 devices, version 1607 and later, running the Configuration Manager client. On-premises mobile device management and Microsoft Intune hybrid MDM-managed computers are not supported. The following 7 steps show how to create the Windows Defender ATP Policy. After that, simply deploy the created policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Endpoint Protection > Windows Defender ATP Policies;
2 On the Home tab, in the Create group, click Create Windows Defender ATP Policy to open the Create Windows Defender ATP Policy Wizard;
3

CWDATPPW_GeneralOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Defender ATP policy;
  • Description: (Optional) Provide a description about the Windows Defender ATP policy;
  • Select Onboarding – Add devices to the online service and start sending threat data for analysis.
4

CWDATPPW_ConfigFileOn the Configuration File page, Browse to the WindowsDefenderATP.onboarding file that is available in the downloaded WindowsDefenderATPOnboardingPackage.zip file and click Next;

5

CWDATPPW_AgentConfigOn the Agent Configuration page, select, depending on the requirements, None or All the file types and click Next;

6 On the Summary page, click Next;
7 On the Completion page, click Close.

Configure endpoints using Microsoft Intune

The second configuration method that I would like to show is using Microsoft Intune hybrid and Microsoft Intune standalone, Windows Defender ATP supports Microsoft Intune by providing OMA-URI settings to create policies to manage endpoints. To achieve this the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Onboarding
  • Date type: String
  • Value: [Content of the WindowsDefenderATP.onboarding file that is available in the downloaded WindowsDefenderATPOnboardingPackage.zip file]

Just to make sure that it’s absolutely clear, the value, of the OMA-URI configuration, is literally a copy-paste action of the content available in the WindowsDefenderATP.onboarding file. 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

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

CIRule_WindowsATP_OnboardingIn this case, I also provide a screenshot of the configured rule. Again to make absolutely sure that it’s a lot of characters that the rule should comply to.

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

Microsoft Intune standalone

CP_WindowsATP_OnboardingThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

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

End result

Let’s end this blog post by having a look at the end result. I’ll do that by providing a status view from the Windows Defender Security Center. Before doing that, it’s good to mention that a successful onboarding can be verified in the registry of the Windows 10 device, as shown below.

WDATP_Registry

Once the onboarding is successful for the Windows 10 devices, the information about those devices will start flowing to the Windows Defender Security Center. The Machines section in the Windows Defender Security Center will provide an overview of those devices and their status, as shown below.

WDATP_Machines

To see more information about the Windows 10 devices, click on a device and it will show a Machines view about the selected device. This view contains information about the logged on users, the reporting status, the alerts and the machine timeline. To get information in the Alerts section, I’ve simply created an EICAR test file, as shown below. This also enables me to select the alert and get more information about the alert, see the process tree and see the incident graph.

WDATP_Alerts

From a Configuration Manager perspective, I’ve saved the coolest information until the end. Windows 10 devices managed with the Configuration Manager client and successfully onboarded with the Windows Defender ATP Policy will also report information to Configuration Manager. This information can be viewed via additional columns in normal device views and collections. Even better, it will also show agent information in the Windows Defender ATP Status dashboard, as shown below.

WDATP_SCCM

Keep in mind that the Windows Defender ATP Status dashboard only shows information for Windows 10 devices managed with the Configuration Manager client and not for Windows 10 devices managed via MDM.

More information

For more information about Windows ATP and the onboarding, please refer to the following articles:

Share

Managing Windows 10 IoT Core devices via MDM

This week a new challenge for a new blog post, managing Windows 10 IoT Core devices. The nice thing about Windows 10, even Windows 10 IoT Core, is the availability of MDM. The availability of MDM is what will help me with managing Windows 10 IoT Core devices. In this post I’ll go through the steps to create an enrollment profile to enroll Windows 10 IoT Core devices in Microsoft Intune hybrid. I’ll end this post with an overview of the end result in Configuration Manager

Configuration

Let’s start by looking at the configuration in Configuration Manager. To create an enrollment profile, for Windows 10 IoT Core devices, it’s required to provide a certificate profile and it’s optionally to provide a Wi-Fi profile.

Create certificate profile

The required component of the enrollment profile is, as mentioned before, a certificate profile. The certificate profile is used to automatically provision a trusted root certificate to the enrolled device. As part of preparing for the certificate profile, export a root certificate.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Compliance Settings > Company Resources > Certificate Profiles;
2 On the Home tab, in the Create group, click Create Certificate Profile to open the Create Certificate Profile Wizard;
3

CCPW_GeneralOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the certificate profile (max. 256 characters);
  • Description: (Optional) Provide a description about the certificate profile;
  • Select Trusted CA certificate.
4

CCP_TCACOn the Trusted CA Certificate page, provide the following information and click Next;

  • Browse to and select the Certificate file;
  • Select Computer certificate store – Root;
  • Certificate thumbprint will automatically populate.
5

CCPW_SPOn the Supported Platforms page, select Windows 10 and click Next;

Note: Windows 10 IoT Core doesn’t have it’s own platform option, which means that the generic Windows 10 should be used to make it applicable to all Windows 10 devices.

6 On the Summary page, click Next;
7 On the Completion page, click Close.

(Optional) Create Wi-Fi profile

The optional component of the enrollment profile is, as mentioned before, a Wi-Fi profile. In some scenarios this might be a required component, but it’s not required for the creation of an enrollment profile. Including a Wi-Fi profile in the enrollment profile can be useful when the Windows 10 IoT Core device needs the Wi-Fi profile for connecting with the Internet.

Create enrollment profile

After creating the required and optional components for the enrollment profile, it’s time to create the enrollment profile. The enrollment profile specifies settings that are required for the Windows 10 IoT Core device enrollment, including a certificate profile that will dynamically provision a trusted root certificate to the device and a Wi-Fi profile that will provision network settings if required.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > All Corporate-owned Devices > Windows > Enrollment Profile;
2 On the Home tab, in the Create group, click Create Enrollment Profile to open the Create Enrollment Profile wizard;
3

CEPW_GeneralOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the enrollment profile (max. 256 characters);
  • Description: (Optional) Provide a description about the enrollment profile;
  • Select as management authority Cloud.
4

CEPW_TrustedRootCertificateOn the Select Trusted Root Certificate page, select the earlier created certificate profile and click Next

5 On the Wi-Fi profiles page, optionally select the earlier created Wi-Fi profile and click Next;
6 On the Summary page, click Next;
7 On the Completion page, click Close.

Enrollment

After creating the enrollment profile and its required components, it’s time to look at delivering the enrollment profile to the Windows 10 IoT Core device. A Windows 10 IoT Core device doesn’t have the full-blown Windows 10 capabilities to perform a MDM enrollment. However, that doesn’t mean that they’re not capable. That’s were the enrollment package comes into the picture.

Export enrollment package

The first step in bringing the enrollment profile to the Windows 10 IoT Core device, is exporting the enrollment profile as an enrollment package.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > All Corporate-owned Devices > Windows > Enrollment Profile;
2 Select the earlier created enrollment profile and on the Home tab, in the Enrollment Profile group, click Export to open the Export Enrollment Package dialog box;
3

On the Export Enrollment Package dialog box, provide the following information and click Export;

  • EEP_GeneralValidity Period (days): Select the number of days that this package is valid;
  • Package File: Provide a unique name for the enrollment package;
  • Do not select the checkbox with Encrypt Package.
4 On the Export Enrollment Package dialog box, click OK;

Deploy enrollment package

The second step in bringing the enrollment profile to the Windows 10 IoT Core device, is copying the exported enrollment package to the Windows 10 IoT Core device. An alternative could be adding the enrollment package as a provisioning package to a Windows 10 IoT Core image.

1 Open File Explorer and remotely connect to the Windows 10 IoT Core device;
2 Copy the earlier created enrollment package to C:\Windows\Provisioning\Package;
3 Restart the Windows 10 IoT Core device.

End result

Now let’s end this post by looking at some of the information that will flow through the MDM channel into Configuration Manager. After restarting the Windows 10 IoT Core device it can take a couple of minutes before the device appears in Configuration Manager. The Windows 10 IoT Core device will show as a mobile device with the operating system IoTUAP (as shown below).

ConsoleOverview

After the first inventory of the Windows 10 IoT Core device, the information of the deivce will populate in the Resource Explorer. In my case, I used a Raspberry Pi 3 (as shown below on the left) and I installed a custom app (as shown below on the right).

RBP_DeviceInformation RBP_InstalledApps

The nice thing is that, as Windows 10 MDM is used in combination with Configuration Manager, I can extend the inventory (see the PTCLOUD entry above) and I can configure settings. For this I can use the available configuration service providers (CSP).

More information

For more about managing Windows 10 IoT Core devices and enrollment profiles (documentation for on-premises MDM), please refer to:

Share

Managing Windows Defender via Windows 10 MDM is getting easier and easier

This post is an updated version of a blog post that I did one-and-a-half year ago about managing Windows Defender, of Windows 10, via OMA-DM. As I still get questions about that post and the OMA-URI settings that are used in that post, I thought it would be good to mention that easier methods are available nowadays. Starting with Configuration Manager 1610 and the Microsoft Intune standalone update around March/ April 2016, it’s simply configurable through the console. No need anymore to configure all those OMA-URI settings manually.

Within this post I’ll provide a quick overview of the configuration options, followed by an overview of the end result. That end result will show how the configured settings simply translate to the known OMA-URI settings.

Configuration

Now let’s have a quick look at the required configurations for Microsoft Intune hybrid and Microsoft Intune standalone. I won’t provide a step-by-step guidance, but I will show were to find the settings and what to do with them.

Environment Configuration
Microsoft Intune hybrid

CCIW_WinDefThe 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 select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page. Now select Windows Defender on the Device Settings page and the configuration can begin.

Once the configuration is finished the created configuration item can be added to a configuration baseline and can be deployed to Windows 10 devices managed via the MDM channel.

Microsoft Intune standalone

WinDef_MSISThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for General Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the Endpoint Protection section and the Windows Defender settings will show.

Once the configuration is finished the policy can be saved and can be deployed to Windows 10 devices managed via the MDM channel.

Note: That these configuration options are available nowadays, doesn’t mean that it’s not possible anymore to create custom OMA-URI settings. That is still a valid method to configure these type of settings and changes to these types of settings will always be the first available via custom OMA-URI settings.

End result

Let’s finish this post by looking at the end result. I could do this by showing the Windows Defender section in the Settings panel on a Windows 10 device, but that will only show grayed out settings and the message Some settings are managed by your organization. I think it’s more interesting to link the created settings to the OMA-URI settings. A great place to look at that is the Deployments node in the Configuration Manager administration console. When I’m looking at the compliance state of the deployment, it will show the Setting Name and the related Instance (in this case the OMA-URI setting), as shown below.

WinDef_Compl

Like last week, I can use a combination of PSEXEC and my favorite WMI Explorer, to locate the created instance with the results of the created policies. As should be familiar by now, the Policy/Result node groups the evaluated policies from all available providers that can be configured. That’s the reason why the example below shows the MDM_Policy_Result01_Defender02 class instead of the MDM_Policy_Config01_Defender02 class. The first class relates to the Policy/Result node and the second class relates to the Policy/Config node.

MDM_Defender02

More information

Fore more information about the managing Windows Defender and the Policy CSP, please refer to:

Share

Automatic edition upgrade for Windows devices

My first blog post in this new year will be about the feature to automatically upgrade the edition of Windows devices. This is already possible, for a while, for Windows 10 devices managed via the MDM channel. However, starting with Configuration Manager 1610 this is now also possible for Windows 10 devices managed via the Configuration Manager client.

In this post I’ll provide the general information and configuration settings that are applicable for Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the details of the end result on a Windows 10 device managed via the Configuration Manager client. Think about details like how this is achieved and the relation to the MDM channel.

Information

The edition upgrade feature can be used to, for example, automatically upgrade devices bought with Windows 10 Pro to Windows 10 Enterprise, without the requirement to reimage the devices. This enables users to buy their own device and get their license upgraded after enrollment. With the new addition to Configuration Manager 1610, the following management scenarios are supported for Windows 10 devices:

  1. Managed via the MDM channel by Microsoft Intune standalone;
  2. Managed via the MDM channel by Microsoft Intune hybrid;
  3. Managed via the Configuration Manager client by Microsoft Intune hybrid (or Configuration Manager standalone).

Within each of those management scenarios the following upgrade paths are supported.

From edition To edition
Windows 10 Pro Windows 10 Enterprise
Windows 10 Pro N Windows 10 Enterprise N
Windows 10 Home Windows 10 Education
Windows 10 Home N Windows 10 Education N
Windows 10 Mobile Windows 10 Mobile Enterprise
Windows 10 Holographic Windows 10 Holographic Enterprise

Configuration

Now let’s have a quick look at the configuration. To perform an edition upgrade, Microsoft Intune hybrid and Microsoft Intune standalone, both require the following information during the creation of the policy:

  • Name: A name for the edition upgrade policy;
  • Description (optional): A description for the edition upgrade policy;
  • SKU to upgrade device to/ Edition to upgrade to: A selected edition that the edition upgrade policy should upgrade to;
  • Product Key: For Windows 10 Desktop, a valid product key that can be used by the edition upgrade policy to install the new version of Windows. This can be either Multiple Activation Keys (MAK) or Key Management Server (KMS) keys;
  • License File: For Windows 10 Mobile and Windows 10 Holographic, a valid license file that can be used by the edition upgrade policy to install the new version of Windows.

This information is requested during different wizards, in Microsoft Intune hybrid and Microsoft Intune standalone, as shown below.

Microsoft Intune hybrid Microsoft Intune standalone
EdiUpgrPol_MSIH EdiUpgrPol_MSIS

End result

Let’s end this post by looking at the end result. In this case it’s not really interesting to look at a screenshot of before and after, as it will simply show a different edition. It’s a lot more interesting to look at how it’s achieved. For Windows 10 devices that are managed via the MDM channel, the WindowsLicensing CSP is used.

Now let’s have a look at how this is achieved on Windows 10 devices that are managed via the Configuration Manager client. As the edition upgrade policy is applied like a configuration baseline, a good place to start with looking is the DcmWmiProvider.log. Below is a log snippet about a successful edition upgrade.

>>>>>>Starting PutInstanceAsync in OsEditionUpgradeProvider<<<<<<
Class name: MDM_WindowsLicensing
>>>>>>Starting PopulateKeyValueParameters in OsEditionUpgradeProvider<<<<<<
Getting properties of wrapper class MDM_WindowsLicensing.
>>>>>>Finished PopulateKeyValueParameters in OsEditionUpgradeProvider<<<<<<
Using created object instance __PATH = \\.\root\cimv2\mdm\dmmap:MDM_WindowsLicensing.ParentID=’./Vendor/MSFT’,InstanceID=’WindowsLicensing’
Creating parameters for method CheckApplicabilityMethod
Requesting productkey for EditionUpgrade
Successfully requested productkey for EditionUpgrade
Calling method CheckApplicabilityMethod
Successfully Executed method CheckApplicabilityMethod, return value 0
Calling method UpgradeEditionWithProductKeyMethod
Successfully Executed method UpgradeEditionWithProductKeyMethod, return value 0
PutInstanceAsync Succeeded
>>>>>>Finished PutInstanceAsync in OsEditionUpgradeProvider<<<<<<

That log snippet provides clear information about the class (MDM_WindowsLicensing) and the methods (CheckApplicabilityMethod and UpgradeEditionWithProductKeyMethod) that are used to upgrade the edition by creating a new instance. By using a combination of PSEXEC and my favorite WMI Explorer, I can simply locate the created instance, as shown below.

MDM_WindowsLicensing

After locating the MDM_WindowsLicensing class, or after a logic interpretation of the name of the class, and the created instance, it’s pretty clear that the MDM Bridge WMI Provider is used to perform the edition upgrade action. In other words, the Configuration Manager client is simply using the existing MDM capabilities. Basically this means that all management scenarios use the same configuration method, but just use another path to get the job done.

More information

Fore more information about the Windows edition upgrade policy, the Windows licensing CSP and the Windows licensing WMI class, please refer to:

Share

Windows 10 MDM and the MDM Bridge WMI Provider

This week another blog post about Windows 10 and OMA-DM, but this week will be short and different. Starting this week I won’t be referring to OMA-DM anymore, instead I’ll be referring to Windows 10 MDM. The main reason for that is change is to align with Microsoft. Also, it simply makes more sense. OMA-DM is the standards based protocol on which the Windows 10 MDM protocol is based. In other words, Windows 10 MDM is not exactly the same as the OMA-DM standards. Technically speaking it’s not wrong to refer to OMA-DM, but it simply makes more sense to refer to Windows 10 MDM.

That being said, this blog post will be different for another reason. This week I’ll try to bring Windows 10 MDM closer to the regular methods, by simply pointing out the existence of the MDM Bridge WMI Provider. This post is all about creating awareness.

MDM Bridge WMI Provider

One of the most heard comments about Windows 10 MDM is related to the lack of knowing what’s happening. Well, I can’t really take that away, maybe the newly introduced logging in 1607 can, but I can show how to see the changes of the Windows 10 MDM configurations.

The MDM Bridge WMI Provider is the bridge to the Windows 10 MDM capabilities. An easy method to see what’s happening is using a WMI Explorer, or something simple as Windows Management Instrumentation Tester (wbemtest). Simply connecting to the root\cimv2\mdm\dmmap namespace is similar to connecting to the MDM Bridge WMI Provider. The classes in this namespace all translate to a configuration service provider (CSP) of Windows 10 MDM. This makes it fairly easy to see what’s happening to the configurations done via Windows 10 MDM.

Below is an example of the MDM_Policy_Result01_Experience02 class, in which the AllowManualMDMUnenrollment instance property was changed during the enrollment of the device. That class and instance property relates to the configuration OMA-URI of ./Vendor/MSFT/Policy/Config/Experience/AllowManualMDMUnenrollment.

Before After
BeforeEnroll AfterEnroll

Knowing this immediately opens up another world. This enables everyone to get information through the MDM Bridge WMI Provider by simply using PowerShell. Looking at the previous example, I can simply use the following PowerShell command, as there is only one instance, to get the information as shown in the table below.

Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" ` -ClassName "MDM_Policy_Result01_Experience02"

Before After
BeforeEnroll_PS AfterEnroll_PS

This also means that the MDM Bridge WMI Provider can be used to trigger configuration changes through Windows 10 MDM. For now, I’ll leave that up to everyone’s imagination.

Important notes

There are a few important notes about the MDM Bridge WMI Provider that should be known and I’ll try to summarize them briefly:

  • Administrative permissions are required to connect with the MDM Bridge WMI Provider. Without those permissions there will be an access denied error when connecting to the MDM Bridge WMI Provider;
  • The local system context is required to view and adjust device settings. This can be achieved by using something like PsExec.exe;
  • Be aware that there is a difference between user settings and device settings. Specific user settings won’t show when connected in the system context and specific device settings won’t show when connected in the user context;
  • Be aware that my example mixed Config and Result properties and nodes. That’s related to the design of the Policy CSP. The Config section handles the configurations requests and the Result section provides a read-only path to the actual configuration.

More information

Fore more information about Windows 10 MDM, the Windows 10 CSP and the MDM Bridge WMI Provider, please refer to:

Share