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:

Share

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.

Share

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

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

Block and allow apps on Samsung KNOX devices

This week a blog post about the capabilities to block apps from starting and to allow apps to install on Samsung KNOX devices. I thought it would be good to mention these capabilities, as many are only familiar with the capability to work with compliant or noncompliant apps on Android. That capability can only be used for reporting functionalities. These capabilities are specifically for Samsung KNOX devices and can truly, and literally, block apps from starting. During this post I’ll go through the high-level steps to configure a blocked app and the end-user experience for both capabilities.

Information

Let’s start with some information about what can be achieved by using the block apps from starting and the allow apps to install capabilities. When using the block apps from starting capability, a list must be created of apps that are blocked from running on the device. Apps in this list are blocked from being run, even if they were already installed when the policy was applied. This list doesn’t prevent users from installing the apps. When using the the allow apps to install capability, a list must be created of apps that users of the device are allowed to install from the Google Play store. Only the apps in this list can be installed. No other apps can be installed from the store. This list doesn’t prevent users from starting the apps.

Configuration

Now let’s have a look at the high-level steps for these configuration. However, before I’m going to look at these steps, it’s good to mention that the configurations can be achieved by using OMA-URI settings. The following OMA-URI settings are available for these configurations:

  • To create a block apps from starting list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/PreventStartPackages
  • To create an allow apps to install list, use the following OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowInstallPackages

To find the value for these OMA-URI settings, the Google Play Store can be used. The app identifier that is used within the store, is what is needed to add a value to the block or allow lists. For example, when I’m looking at the OWA for Android app, in the store, the bold section, in the following URL, represents the required value: https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en.

Now let’s have a look at how these two come together in the configurations for Microsoft Intune hybrid and Microsoft Intune standalone.

Environment Configuration
Microsoft Intune hybrid

PreventStartPackages_MSIhThe 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 Android and Samsung KNOW (below Settings for devices managed without the Configuration Manager client) on the General page and to select Android KNOX Samsung Standard 4.0 and higher 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 configuration is finished the created configuration item can be added to a configuration baseline and can be deployed to Samsung KNOX devices.

Microsoft Intune standalone

PreventStartPackages_MSIsThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Android 4.0 and later, Samsung KNOX Standard 4.0 and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added.

Once the configuration is finished the policy can be saved and can be deployed to Samsung KNOX.

Note: When the block or allow lists must contain multiple apps, one of the following four characters ; : , | can be used as a delimiter.

End-user experience

Let’s end this blog post by having a look at the end-user experience. Below, on the left, is the end-user experience when the end-user starts an app that is blocked from starting. It’s indeed correct that it doesn’t show a screenshot. Reason behind that is because it actually lacks a real end-user experience. When the end-user tries to start a blocked app, the app won’t start and the end-user won’t get any notifications. Below, on the right, is the end-user experience when the end-user tries to install an app that is not allowed to install. The end-user will receive an error message accompanied by the message “Security policy prevents installation of this application”, which is a clear end-user experience.

Block app from starting Allow app to install
The app won’t start and the end-user won’t get a notification about what’s happening. Screenshot_20170122-125800

More information

Fore more information about blocking and allowing apps on Android devices, 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