Configuration Policy

A while ago I did a blog post about managing AppLocker on Windows 10 via OMA-DM. During that post I showed how to use OMA-DM, via Microsoft Intune hybrid and standalone, to configure AppLocker. In this post I’ll do something similar for setting up kiosk mode on Windows 10. Windows 10 Enterprise and Windows 10 Education provide a configuration service provider (CSP) for setting up kiosk mode. That’s the AssignedAccess CSP.

During this blog post I’ll go through the AssignedAccess CSP, and its required input, I’ll go through the configuration steps in Microsoft Intune hybrid and standalone and I’ll show the end-user experience with the Twitter app as an example.

AssignedAccess CSP

Before using the AssignedAccess CSP it’s good to get a better understanding of the CSP. The CSP is used to set up the Windows 10 device to run in kiosk mode. Once the CSP has been executed, then the next user login, that is associated with the kiosk mode, puts the Windows 10 device in the kiosk mode running the specified application. Let’s go through the nodes of the AssignedAccess CSP.

./Vendor/MSFT/AssignedAccess– Defines the root node for the AssignedAccess configuration service provider;

ApplicationLaunchRestrictions – Defines a JSON string that contains the user account name and the Application User Model ID (AUMID) of the Kiosk mode app

The JSON string should look like the following example: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}

The account name can be a domain account as well as a local account. When a local account is used, the domain name should be the name of the device;

The Application User Model ID (AUMID) can be easily received through PowerShell. The following example can help with collecting the information:

Configuration

Now it’s time to use the AssignedAccess CSP to set up Windows 10 devices in kiosk mode. In this configuration I’m going to use the Twitter app as an example for my domain user account and I’m going to show the required configuration for Microsoft Intune standalone and hybrid.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure the required Configuration Item.

On the Create Policy page, click Save Policy to open the Deploy Policy dialog box;

6

In the Deploy Policy dialog box, click Yes to open the Manage Deployment dialog box;

7

In the Manage Deployment dialog box, select a group click Add and click OK.

End-user experience

Let’s end this post with the most important thing, the end-user experience. After the device receives the new configuration and the configured end-user logs on, the end-user will receive a full screen Twitter app as shown below. The end-user won’t be able to close the Twitter app and can only get out of the kiosk mode by pressing Ctrl+Alt+Del. That will bring the end-user back to the logon screen.

End-user experience

More information

Fore more information about kiosk mode on Windows 10, the AssignedAccess CSP and the AUMID, please refer to:

In this blog post I will provide nice tables of the different compliance rules, for Windows 10 devices, that are currently available for Microsoft Intune standalone and Microsoft Intune hybrid. In those tables I’ll show the different management scenarios and the currently available applicable compliance rules.

Overview

Before I’ll start with the overview, it’s good to provide a short explanation about the distinction between the conditional access policy and the compliance policy.

The conditional access policy is a required configuration to enable conditional access on a particular service and to help secure access to that particular service. In the conditional access policy, the targeted platforms and the targeted users of devices are configured. Also, important for Windows 10 devices, in the conditional access policy it is possible to determine if Windows 10 devices must be compliant or domain joined.

The compliance policies, on the other hand, are optional additional rules that can evaluate settings like PIN and encryption. The devices of targeted users must be compliant to those additional rules. When there are no compliance policies deployed, the device will automatically be evaluated as compliant.

Microsoft Intune standalone

Now let’s start with the overview of available compliance rules in Microsoft Intune standalone. In Microsoft Intune standalone, a Windows 10 device can be managed by the Microsoft Intune client and it can be enrolled as a mobile device. Those two options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

Intune client

MDM

Allow simple passwords

N/A

Yes (Mobile only)

Maximum Windows Phone or Windows 10 Mobile version

N/A

Yes (Mobile only)

Maximum Windows version

N/A

Yes (Desktop only)

Minutes of inactivity before password is required

N/A

Yes

Minimum password length

N/A

Yes

Minimum Windows Phone or Windows 10 Mobile version

N/A

Yes (Mobile only)

Minimum Windows version

N/A

Yes (Desktop only)

Require a password to unlock an idle device

N/A

Yes (Mobile only)

Password expiration

N/A

Yes

Remember password history – Prevent reuse of previous passwords

N/A

Yes

Required password type – Minimum number of character sets

N/A

Yes

Require a password to unlock mobile devices

N/A

Yes (Mobile only)

Require devices to be reported as healthy

N/A

Yes

Require encryption on mobile device

N/A

Yes

Microsoft Intune hybrid

Let’s continue with the overview of available compliance rules in Microsoft Intune hybrid. In Microsoft Intune hybrid, a Windows 10 device can be managed by the Microsoft Intune client, the ConfigMgr client and it can be enrolled as a mobile device. Those three options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

Intune client

ConfigMgr client

MDM

All required updates installed with a deadline older than X days

N/A

Yes

N/A

Allow simple passwords

N/A

N/A

Yes (Mobile only)

File encryption on mobile device

N/A

N/A

Yes

Maximum operating system version

N/a

N/A

Yes

Minimum classification of required updates

N/A

N/A

Yes

Minimum operating system version

N/A

N/A

Yes

Minimum password length

N/A

N/A

Yes

Minutes of inactivity before password is required

N/A

N/A

Yes

Require a password to unlock an idle device

N/A

N/A

Yes (Mobile only)

Reported as healthy by Health Attestation Service

N/A

N/A

Yes

Require Antimalware

N/A

Yes

N/A

Require BitLocker drive encryption

N/A

Yes

N/A

Require password settings on mobile devices

N/A

N/A

Yes

Require registration in Azure Active Directory

N/A

Yes

N/A

More information

For information about about conditional for Windows 10 devices with Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

This week another blog post about conditional access. And another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. However, this time it’s about a feature that already did exist in Microsoft Intune standalone. I’m talking about the new conditional access rule that uses the Health Attestation Service. This new rule creates the ability to ensure that Windows 10 devices have trustworthy BIOS, TPM, and boot software configurations enabled.

In this blog post I’ll show the detailed configuration steps for Microsoft Intune hybrid and I’ll briefly note the most important configurations for Microsoft Intune standalone.

Introduction

Device health attestation is an additional level of restricting access to Exchange Online and SharePoint Online for Windows 10 devices. Currently only available for Windows 10 devices that are managed via OMA-DM. It adds the ability to create compliance policies that require Windows 10 devices to report as healthy. Device health attestation can be used to ensure that the following trustworthy configurations are enabled:

BitLocker: BitLocker provides encryption for all data stored on the Windows operating system volume.

Code integrity: Code Integrity provides improvements to the security of the operating system by validating the integrity of a driver, or system file, each time it is loaded into memory.

Early-launch antimalware (only applies to PCs): Early launch anti-malware (ELAM) provides protection for computers when they start up and before third-party drivers initialize.

Secure boot: Secure boot provides a security standard, which is developed by members of the PC industry, to help make sure that a PC boots with only software that is trusted by the PC manufacturer.

Note: A Windows 10 device must be compliant to all of the applicable configurations to be reported as healthy by the Health Attestation Service.

Pre-configuration

Before looking at the configuration of conditional access and device health attestation, I will begin with mentioning a new client setting and the health attestation dashboard. This is at least as important, as it will provide a good understanding about the impact of using conditional access based on the status reported by the Health Attestation Service.

Default client settings

To start with collecting information about the status, reported by the Health Attestation Service, of Windows 10 devices, it’s good to start with enabling the communication with the Health Attestation Service,. The following 2 steps will make sure that the information will be collected.

1

In the Configuration Manager administration console, navigate to Administration > Overview > Client Settings and open the Default Client Settings;

2

In the Default Client Setting, navigate to Computer Agent and select Yes with Enable communication with Health Attestation Service and click OK to close the Default Client Settings..

Health attestation dashboard

After configuring the Default Client Settings, the information of the Health Attestation Service, on Windows 10 devices, will start showing in the health attestation dashboard and the List of devices by Health Attestation state report. This information can be used to get a good understanding about the impact of enabling conditional access based on the status reported by the Health Attestation Service. The health attestation dashboard is available by navigating to Monitoring > Overview > Security > Health Attestation and will look like the following example.

Note: In Microsoft Intune standalone similar reports are available, in the Reports section, named Health Attestation Reports.

Configuration

Let’s continue with looking at the real configuration for conditional access. I will start with briefly mentioning the conditional access policy and I’ll end this configuration section with going through all the required steps for creating the compliance policy.

Conditional access policy

Now that I know what the impact will be of using the health of a Windows 10 device, reported by the Health Attestation Service, I can start with enabling conditional access. Just like last week, I’ll only mention the conditional access policy briefly. It’s important that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. Also, for supporting Windows 10 mobile, it’s important to also select Windows 10 Mobile. These settings can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy

SharePoint Online Policy

Compliance policy

Like last week, the more interesting configuration is the configuration of the new compliance policy. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

In the Add Rule dialog box, select the Reported as healthy by the Health Attestation Service rule and click OK to return to the Rules page;

7

Back on the Rules page, verify the created configuration and click Next;

8

On the Summary page, click Next

9

On the Completion page, click Close.

–

Note: In Microsoft Intune standalone a similar compliance policy setting is available, in the Device Health section, named Require devices to be reported as healthy.

End-user experience

Now it’s time to look at the end-user experience. This time I won’t show the end-user experience of a non-compliant device connecting to Exchange Online, or SharePoint Online, as it’s similar to the messages shown during last weeks post. This time I’ll only show the end-user experience in the Company Portal app on a Windows 10 Desktop device and a Windows 10 Mobile device. The messages will be similar as shown below. It will not just show a non-compliant device, it will actually show which configuration is reported as not healthy by the Health Attestation Service.

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week a blog post about the Conditional access for managed PCs feature that is introduced in ConfigMgr 1602. This feature is introduced as a pre-release feature. The requirements for using Conditional access for managed PCs are similar to the requirements of the blog series that I did a few months ago about Conditional access for PCs. Make sure that those requirements are in-place before starting with the configurations described in this post.

Introduction

Conditional access for managed PCs is basically an additional level of restricting access to Exchange Online and SharePoint Online. Before the only level of restricting access was that device had to be enrolled via Microsoft Intune, or that the device had to be domain joined. Now it’s also possible to create additional compliance policies for managed PCs. Managed PCs by ConfigMgr. Those compliance policies can contain the following rules:

Require registration in Azure Active Directory: This rule checks if the end-user device is workplace joined to Azure AD. If not, the device is automatically registered in Azure AD. Automatic registration is currently only supported on Windows 8.1.

All required updates installed with a deadline older than a certain number of days: This rule checks to see if the end-user device has all required updates within the configured deadline and grace period. If not, any pending required updates are automatically installed.

Require BitLocker drive encryption: This is a check to see if the primary drive on the device is BitLocker encrypted. If not, access to Exchange Online and SharePoint Online is blocked.

Require Antimalware: This is a check to see if the antimalware software is enabled and running. If not, access to Exchange Online and SharePoint Online is blocked. At this moment only supported for System Center Endpoint Protection and Windows Defender.

Configuration

Now lets have a look at the configuration. I will briefly mention the conditional access policy, because I’ve written a lot about those in my previous blog series about Conditional access for PCs. After that I’ll go through all the required steps for creating the compliance policy and I’ll end this configuration section with the effect on the client.

Pre-release feature

As Conditional access for managed PCs is a pre-release feature, it must be specifically turned on. This can be achieved by simply performing the following 2 steps.

Conditional access policy

The reason why I do have to mention the conditional access policy, is one specific configuration setting. That specific setting is that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. This is very important, as any other configuration would make a domain join enough to be compliant, while in this configuration I want to create an additional compliance policy. That setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy

SharePoint Online Policy

Compliance policy

More interesting is the new compliance policy. Within the compliance policy it’s now possible to create a compliance policy specifically for devices managed with the ConfigMgr client. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

On the Home tab, click Create Compliance Policy to open the Create Compliance Policy Wizard;

3

On the General page, specify the following information and click Next;

Name: [Specify a unique name for the compliance policy]

Description: [Specify details that help identifying the compliance policy]

Select Compliance rules for devices managed with the Configuration Manager client with Specify the type of compliance policy that you want to create

4

On the Supported Platforms page, select the following platforms and click Next;

All Windows 7 (64-bit)

All Windows 7 (32-bit)

All Windows 8.1 (64-bit)

All Windows 8.1 (32-bit)

All Windows 10 (64-bit)

All Windows 10 (32-bit)

5

On the Rules page, click New… to open the Add Rule dialog box;

6

In the Add Rule dialog box, select the following rules one-by-one and click OK to return to the Rules page;

Require registration in Azure Active Directory

All required updates installed with a deadline older than X days

Require BitLocker drive encryption

Require Antimalware

7

Back on the Rules page, verify the created configuration and click Next;

Note: As this screenshot shows, none of the rules require additional configuration except for the software updates rules. That rule requires the selection of the number of days that a deadline has been passed.

8

On the Summary page, click Next

9

On the Completion page, click Close.

Policy effect

A good place to look at the effect of the compliance policy, is to look at the reports. More specifically, the reports Compliance Access Compliance for Users and Compliance Access Compliance Report. However, I still like to think that the log files are the best place to look at the effect of the compliance policy. More specifically, the DcmWmiProvider.log. That log file provides detailed information about the compliance checks that are performed. Below is a log snippet about a successful compliance check.

This log snippet provides clear information about the 4 rules, of the compliance policy, that are being checked. It clearly shows the software update check, the BitLocker encryption check, the workplace join check and the antimalware check. The log snippet even provides some details about how those checks are performed. For example, it shows that my test device was a virtual machine and that, because of that, the encryption check was skipped and that the compliance, for that check, was automatically set to true.

End-user experience

Now it’s time to look at the end-user experience. At this moment the end-user experience is as shown below. When a non-compliant managed PC tries to access Exchange Online, or SharePoint Online, it will get a message as shown below. A compliant managed PC will be able to simply access Exchange Online and SharePoint Online. To get the detailed information about the compliance of the managed PC, the end-user can use the Device compliance section in Software Center, as shown below.

Non compliant

Compliant

Not applicable. A compliant managed PC will automatically have access. Meaning there is no special screen that the en-user will get.

A while ago I did a blog post about managing Windows Defender of Windows 10 via OMA-DM. During that specific post I showed how to use OMA-DM, via Microsoft Intune standalone and hybrid, to configure Windows Defender. In this post I’ll do something similar for AppLocker. However, I have to admit that it was a bit more challenging for AppLocker. The main difference is that Windows 10 includes many different separate policy settings for Windows Defender, but provides a separate configuration service provider (CSP) for AppLocker.

During this post I’ll show how to create the required AppLocker XML, what the AppLocker XML looks like, what the AppLocker CSP looks like and how to combine the AppLocker XML and the AppLocker CSP. I’ll end this post with the end-user experience. During this post I’ll use the build-in Windows 10 app Candy Crush Soda Saga as an example.

Create the AppLocker XML

The required AppLocker XML can be created by using the Local Security Policy snap-in, the Local Group Policy Editor snap-in or the Group Policy Management snap-in. Any of these snap-ins will work in a similar way for creating the required AppLocker XML. It doesn’t matter which snap-in is used, as long as it’s being used on a Windows 10 device. That makes it easier with configuring and selecting the required apps. During the following twelve steps, I’ll use the Local Group Policy Editor snap-in for configuring the Candy Crush Soda Saga app.

Right-click the AppLocker node and select Export Policy to open the Export Policy dialog box;

12

In the Export Policy dialog box, provide a name and location and click Save;

Inside the AppLocker XML

Now let’s have a look at the AppLocker XML that I just created. That AppLocker XML should look like the one shown below. It should show a default allow rule and a specific deny rule on the Candy Crush Soda Saga app, both within the RuleCollection element of the Appx type. That element of the AppLocker XML is what’s required during the further configurations.

Inside the AppLocker CSP

Before using the AppLocker CSP it’s good to get a better understanding of the different nodes. The AppLocker CSP contains nodes for the different configuration components of AppLocker. Let’s go through these different nodes.

./Vendor/MSFT/AppLocker – Defines the root node for the AppLocker configuration service provider;

Policy – Defines the policy for launching executable applications, Windows Installer files, scripts, store apps, and DLL files. The contents of this node is precisely the RuleCollection element as discussed in the previous paragraph.

Create AppLocker OMA-URI

Now it’s time to use the created AppLocker XML for configuring Windows 10 devices. The key with this is that only the RuleCollection element is required that matches with the node in AppLocker CSP. With the RuleCollection element of the Appx type, I need the StoreApp node in the AppLocker CSP. This is applicable to Microsoft Intune hybrid and standalone.

Microsoft Inune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure the required OMA-URI configuration item.

Note: [MyGroup0] is a custom GUID that can be literally anything. That GUID makes sure that the un-enrollment of a device will behave as expected. Also, the complete RuleCollection element, about the Appx type, should be provided in the value configuration.

5

On the Create Policy page, click Save Policy to open the Deploy Policy dialog box;

6

In the Deploy Policy dialog box, click Yes to open the Manage Deployment dialog box;

7

In the Manage Deployment dialog box, select a group click Add and click OK.

End-user experience

Let’s end this post with the most important thing, the end-user experience. Actually, the end-user experience will be exactly the same as with a local or domain group policy configuration. The end-user will receive the message as shown below and the end-user can find messages in the Event Viewer. Those messages in the Event Viewer will wrongly indicate that the app is blocked by group policy.

End-user message

Event Viewer message

More information

Fore more information about how AppLocker works, AppLocker policies and the AppLocker CSP, please refer to:

This blog post will be about the other magical store world of Windows Phone 8.1 and that’s the world of the Windows Phone Store. By now, I think many are already aware of the different possibilities for the Windows Phone Store, but I thought it would be time for a complete overview like I did for Windows Phone 8.1 and the Microsoft Intune Company Portal app.

This post will contain the different scenarios for providing (limited) access to the Windows Phone Store. These scenarios will be explained for Microsoft Intune standalone and Microsoft Intune hybrid.

Scenarios

Now lets start with summarizing the different scenarios that are possible for providing (limiting) access to the Windows Phone Store. I found the following three scenarios and I’ll go through them in detail after listing them:

Scenario 1: Completely block the Windows Phone Store;

This scenario will be about completely blocking the access to the Windows Phone Store;

Scenario 2: Block the Windows Phone Store except…;

This scenario will be about blocking the access to all the apps from the Windows Phone Store except for specifically configured exceptions;

Scenario 3: Allow the Windows Phone Store except…;

This scenario will be about allowing the access to all the apps from the Windows Phone Store except for specifically configured exceptions.

Scenario 1: Completely block the Windows Phone Store

The first scenario is also the most restricting scenario. This scenario will completely block the access to the Windows Phone Store. On a high-level, this can be configured by performing the configurations mentioned below. These configurations are based on the current versions of ConfigMgr and Microsoft Intune.

Environment

Configuration

Microsoft Intune standalone

This can be achieved by creating and deploying a Windows Phone Configuration Policy (Windows Phone 8.1). In the Applications section enable the Allow application store (Windows Phone 8.1 +) setting and configure it to No.

Microsoft Intune hybrid

This can be achieved by creating a Configuration Item of the Mobile device type and selecting the Store mobile device settings group. Configure the Application store setting to Prohibited, add the configuration item to a configuration baseline and deploy it.

Note: In both cases this is also still possible via a custom OMA-URI. The value should be set to 0 and the location would be the following ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowStore.

Scenario 2: Block the Windows Phone Store except…

The second scenario provides a bit more room for movement within the Windows Phone Store. In this scenario the Windows Phone Store will be accessible, but only for specifically specified applications. Every application that’s not specified will be disabled when it was already installed, or will not be available when the installation is tried via the Windows Phone Store. On a high-level, this can be configured by performing the configurations mentioned below. These configurations are based on the current versions of ConfigMgr and Microsoft Intune.

Environment

Configuration

Microsoft Intune standalone

This can be achieved by creating and deploying a Windows Phone Configuration Policy (Windows Phone 8.1). In the Allowed & Blocked Apps list for Windows Phone section make sure the Allow devices to install only the listed apps setting and add the App URL to the app in the Windows Phone Store.

Microsoft Intune hybrid

This can be achieved by creating a configuration item for a mobile device and selecting the Allow and Blocked Apps list (Windows Phone 8.1) mobile device settings group. Make sure the Allowed apps list setting is selected and add the App URL to the app in the Windows Phone Store. Now add the configuration item to a configuration baseline and deploy it.

Note: In both cases this is also still possible via a custom OMA-URI. Via OMA-URI there is also a bit more flexibility, as it also provides the ability to allow a specific publisher. The location of the OMA-URI would be the following ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ApplicationRestrictions.

Scenario 3: Allow the Windows Phone store except…

The third scenario provides the most room for movement within the Windows Phone Store. In this scenario the Windows Phone Store will be accessible, except for specifically specified applications. Every application that’s specified will be disabled when it was already installed, or will not be available when the installation is tried via the Windows Phone Store. This could even be used to block certain line-of-business applications. On a high-level, this can be configured by performing the configurations mentioned below. These configurations are based on the current versions of ConfigMgr and Microsoft Intune.

Environment

Configuration

Microsoft Intune standalone

This can be achieved by creating and deploying a Windows Phone Configuration Policy (Windows Phone 8.1). In the Allowed & Blocked Apps list for Windows Phone section make sure the Block devices from opening the listed apps setting and add the App URL to the app in the Windows Phone Store.

Microsoft Intune hybrid

This can be achieved by creating a configuration item for a mobile device and selecting the Allow and Blocked Apps list (Windows Phone 8.1) mobile device settings group. Make sure the Blocked apps list setting is selected and add the App URL to the app in the Windows Phone Store. Now add the configuration item to a configuration baseline and deploy it

Note: In both cases this is also still possible via a custom OMA-URI. Via OMA-URI there is also a bit more flexibility, as it also provides the ability to block a specific publisher. The location of the OMA-URI would be the following ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ApplicationRestrictions.

Results

Now that I’ve gone through the different scenarios it’s time to look at the results of those configurations. Below are screenshots available per scenario. For the first and second scenario I choose to go for a screenshot of the App list, as it provides the best visible result. For a similar reason I choose to go for a screenshot of the specific app, in the Windows Phone Store, for the third scenario.

Scenario 1

Scenario 2

Scenario 3

The result of the first scenario is a completely blocked Windows Phone Store.

The result of the second scenario is that every app from the Windows Phone Store is blocked, except for the Snapcat app.

The result of the third scenario is that every app from the Windows Phone Store is allowed, except for the Snapcat app.

More information

For more information about Microsoft Intune standalone, or Microsoft Intune hybrid, in combination with the Windows Phone Store, please refer to the following links:

A couple of weeks ago I did a blog post about the different management options for Windows 8.1. In that specific post I already mentioned OMA-DM as a very valid method to manage Windows 8.1 and Windows 10 devices. To refresh the memories, OMA Device Management (OMA-DM) is an open management standard designed for mobile devices. The nice thing is that OMA-DM is also fully utilized in Windows 10, even the desktop version. That means that OMA-DM can be used to fully manage specific parts of a Windows 10 device.

In this post I’ll show how OMA-DM can be used to fully manage Windows Defender in Windows 10. For Windows 10 it’s possible to manage all the settings available for Windows Defender. This includes everything, from managing exclusions until blocking the access to the user interface. Managing Windows Defender can be very useful for Windows 10 devices connecting to the work resources. Also, this level of management can be useful for both personal and company owned devices.

Disclaimer: This blog post is based on a technical preview build of Windows 10 (build 10122). The configurations described in this post might change in future releases. I’ll update this post, if needed, with the next release.

Configuration

Now let’s have a look at the configuration. Actually it doesn’t differ a lot from the configurations required for managing settings on Windows Phone 8.1, but I’ll go through the required configurations anyway. I’ll go through the required configurations for both, Microsoft Intune standalone and Microsoft Intune hybrid.

Microsoft Intune standalone

The first configuration steps are for Microsoft Intune standalone. I’ll go through the high-level steps for creating the required policies and the required deployment. It shows the creation of a single OMA-URI setting, which can be used to (not) allow real-time monitoring. The creation of the other OMA-URI settings is similar and can be created by repeating step 2. A complete list of available settings can be found later in this post.

Step

Configuration

1

The first step is to create a new Windows Custom Policy (Windows 10 and Windows 10 Mobile). Simply provide a valid name for the new configuration policy and it’s all ready for adding OMA-URI settings.

2

The second step is to add OMA-URI settings. This can be done by clicking the Add button and simply providing the required information. In this example I’ll create an OMA-URI setting for allowing real-time monitoring.Setting name: Allow Realtime MonitoringSetting description: Allows or disallows Defender’s Realtime Monitoring functionality.Data type: IntegerOMA-URI (case sensitive): ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoringValue: 1

3

The third step is to create a deployment for the configuration policy. The nice thing is that this is simply the last step after providing the right configurations. Simply click the Save Policy button, click Yes and select a group.

Microsoft Intune hybrid

The last configuration steps are for Microsoft Intune hybrid. I’ll go through the high-level steps for creating the required configuration items, the required configuration baseline and the required deployment. It shows the creation of a single configuration item, that’s used for a single OMA-URI setting, which can be used to (not) allow real-time monitoring. The creation of the other configuration items is similar and can be created be repeating step 1 and 2. A complete list of available settings can be found later in this post.

Step

Configuration

1

The first step is to create a Configuration Item that contains the OMA URI setting. Personally, I prefer to use a configuration item per setting. In this example I’ll create an OMA-URI setting for allowing real-time monitoring.Name: Allow Realtime MonitoringDescription: Allows or disallows Defender’s Realtime Monitoring functionality.Setting type: OMA URIData type: IntegerOMA-URI (case sensitive): ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoring

2

The second step is to add a Compliance Rule for the OMA-URI setting. In this example I’ll also create an compliance rule for allowing real-time monitoring.Name: Rule for Allow Realtime MonitoringDescription: The following list shows the supported values:•0 – Not allowed.•1 (default) – Allowed.This setting must comply with the following rule: Allow Realtime Monitoring Equals 1Select Remediate noncompliant rules when supported.

3

The third step is to create a Configuration Baseline for the created configuration items. Simply provide a valid name and use Add > Configuration Item to add the created configuration items.

4

The fourth step is to create a deployment for the configuration baseline. Make sure that the configuration has Remediate noncompliant rules when supported and Allow remediation outside maintenance window selected. Also, don’t forget to add a compliance evaluation schedule, but only use every 1 hours for testing purposes.

Result

There is nothing better than looking at the results, especially with something relatively new. Below are two screenshots of the settings of Windows Defender. The first screenshot is before applying the OMA-URI settings and the second screenshot is after applying the configured OMA-URI settings. It shows that every configured setting can also not be changed anymore (besides the configuration of the exceptions). The best thing is that once the Windows 10 device is un-enrolled, the before-state will be applicable again.

Before

After

Windows Defender Settings

There are more than 30(!) settings available that can be configured via OMA-URI and are specifically targeted on Windows Defender. All of these settings are configurable via the path of ./Vendor/MSFT/Policy/Config/Defender/<PolicyName>. The following table shows the available policies including the supported and valid values. Many of these values are also available in the documentation, but I’ve noticed that many of the Allowed/ Not allowed values are switched.

PolicyName

Values

AllowCloudProtectionTo best protect your PC, Windows Defender will send information to Microsoft about any problems it finds.

Supported values (Integer):

0 – Not allowed;

1 (default) – Allowed.

AVGCPULoadFactorRepresents the average CPU load factor for the scan (in percent).

Valid values (Integer): 0–100.

DaysToRetainCleanedMalwareTime period (in days) that quarantine items will be stored on the system.

A bit more than a month ago, I created THE Windows Phone 8.1 Configuration Baseline for usage with ConfigMgr 2012 (integrated with Microsoft Intune). That Configuration Baseline contains all the currently configurable company policies via OMA-URI settings. At that time the management of OMA-URI settings on Windows Phone 8.1 wasn’t possible via Microsoft Intune standalone, but this has changed with the latest update to Microsoft Intune. That’s why I thought it would be good to dedicate this blog post to creating OMA-URI settings in Microsoft Intune standalone.

As it’s not possible, yet, to export a Configuration Policy in Microsoft Intune, like a Configuration Baseline in ConfigMgr, I will simply show how to create an OMA-URI setting in Microsoft Intune. Also good to know, OMA-URI settings can be used for a lot more then “just” company policies. For example, it can also be used to manage WiFi profiles. Like I mentioned in previous blog posts, and like I will keep on mentioning, all the OMA-URI settings can be found in the Windows Phone 8.1 MDM Protocol document.

Configuration

In this example configuration, I’m going to show how to create a Windows Phone OMA-URI Policy to disable cellular data roaming. The same steps are applicable to all the different OMA-URI settings that are currently available for managing company policies on Windows Phone 8.1. To disable cellular data roaming via an OMA-URI setting, simply perform the following steps:

Note: It’s not necessary to create a new Windows Phone OMA-URI Policy for every OMA-URI setting. To add more OMA-URI settings to an existing policy, simply select the Configuration Policy and click Edit….

Result

In this case I really like to show the results, but not by showing a screenshot of the device. I want to do this by showing something way cooler in the Microsoft Intune administration console, I want to show the Policy tab, of the Mobile Device Properties, of a device. This tab shows an overview of the deployed policies and more importantly the status of the policies. In this case it shows that my Windows Phone 8.1 device now Conforms with the OMA-URI setting.

More information about the configurable company polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 140. This is a living document that gets updated by Microsoft when required. That also means that the mentioned page number might change in the (near) future.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!