Setting up kiosk mode on Windows 10 via OMA-DM

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.

  • AA_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:
      foreach ($App in (Get-AppxPackage)) { foreach ($Id in (Get-AppxPackageManifest $App).package.applications.application.id) { Write-Output ($App.packagefamilyname + "!" + $Id) } }

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.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items;
2 On the Home tab, click Create Configuration Item to open the Create Configuration Item Wizard;
3

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

  • Name: [Specify a unique name for the configuration item]
  • Description: [Specify details that help identifying the configuration item]
  • Select Windows 8.1 and Windows 10 with Settings for devices managed without the Configuration Manager client.
4

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

  • All Windows 10 (64-bit)
  • All Windows 10 (32-bit)
5 On the Device Settings page, select Configure additional settings that are not in the default settings groups and click Next;
6 On the Additional Settings page, click Add to open the Browse Settings dialog box.
7 In the Browse Settings dialog box, click Create Setting to open the Create Setting dialog box;
8

KioskModeAppIn the Create Setting dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

  • Name: [Specify a unique name for the setting]
  • Description: [Specify details that help identifying the setting]
  • Setting type: OMA-URI
  • Data type: String
  • OMA-URI (Case Sensitive): ./Vendor/MSFT/AssignedAccess/KioskModeApp
    9 In the Browse Settings dialog box, select the newly created setting and click Select to open the Create Rule dialog box;
    10

    KioskModeApp_RuleIn the Create Rule dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

    • Name: [Specify a unique name for the rule]
    • Description: [Specify details that help identifying the rule]
    • Rule type: Value
    • The setting must comply with the following rule: Equals
    • the following values: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • Select Remediate noncompliant rules when supported
    11 In the Browse Settings dialog box, click Close to return to the Additional Settings page;
    12 On the Additional Settings page, click Next;
    13 On the Platform Applicability page, click Next;
    14 On the Summary page, click Next;
    14 On the Completion page, click Close;

    Note: This created a configuration item that can be deployed like any other configuration item, as a part of a configuration baseline.

    Microsoft Intune hybrid

    Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure the required Configuration Policy.

    1 In the Microsoft Intune administration console, navigate to Policy > Configuration Policies and click Add to open the Create a New Policy dialog box;
    2 In the Create a New Policy dialog box, select Windows > Custom Configuration (Windows 10 Desktop and Mobile and later) and click Create Policy to open the Create Policy page;
    3

    On the Create Policy page, specify the following information in the General section and click Add in the OMA-URI Settings section to open the Add or edit OMA-URI Setting dialog box;

    • Name: [Specify a unique name for the policy]
    • Description: [Specify details that help identifying the policy]
    4

    KioskModeApp_SAIn the Add or edit OMA-URI Setting dialog box, specify the following information and click OK to return to the Create Policy page;

    • Setting name: [Specify a unique name for the setting]
    • Setting description: [Specify details that help identifying the setting]
    • Data type: String
    • OMA-URI (case sensitive): ./Vendor/MSFT/AssignedAccess/KioskModeApp
    • Value: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    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. 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
    TwitterApp

    More information

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

    Conditional access, Windows 10 and Microsoft Intune: What are the compliance options?

    Recently Microsoft released a couple of blog posts about The Path to Modernizing Windows Management and about Clear & Simple Guidance: When ConfigMgr and Intune should be used with Windows 10, which should be really helpful with deciding how to managing the Windows 10 devices within an organization. I would really recommend everybody to read those posts. This blog post will not be directly related, but will continue on a more detailed level about the options for conditional access and Windows 10 devices.

    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:

    Conditional access and health attestation

    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

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

    CA_Intune_HealthAttestation

    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
    CA_ExchOnl_Win10 CA_SPOnl_Win10

    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.

    1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
    2 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;

    • CA_ConfigMgrIntune_CP_GeneralName: [Specify a unique name for the compliance policy]
    • Description: [Specify details that help identifying the compliance policy]
    • Select Compliance rules for devices managed without the Configuration Manager client with Specify the type of compliance policy that you want to create
      • Select Windows 8.1 and Windows 10

    Note: Select Windows Phone and Windows 10 Mobile for supporting the configuration on Windows 10 Mobile devices.

    4

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

    • CA_ConfigMgrIntune_CP_PlatformAll Windows 10 (64-bit)
    • All Windows 10 (32-bit)

    Note: Select All Windows 10 Mobile and higher for supporting the configuration on Windows 10 Mobile devices.

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

    ICA_ConfigMgrIntune_CP_AddRulen 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

    CA_ConfigMgrIntune_CP_RulesBack 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.
    CA_Intune_CompliancePolicyNote: 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.

    Non-compliant Compliant
    CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
    wp_ss_20160319_0001 wp_ss_20160319_0002

    More information

    For more information about conditional access, Windows 10 device health attestation and the HealthAttestation CSP, please refer to:

    Conditional access for PCs managed by ConfigMgr

    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.

    1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
    2 Right-click Pre-release – Conditional access for managed PCs and select Turn on.

    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
    CA_ConfigMgr_ExchangeOnline CA_ConfigMgr_SharePointOnline

    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.

    1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
    2 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;

    • CA_ConfigMgr_CP_GeneralName: [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;

    • CA_ConfigMgr_CP_PlatformAll 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;

    • CA_ConfigMgr_CP_AddRuleRequire registration in Azure Active Directory
    • All required updates installed with a deadline older than X days
    • Require BitLocker drive encryption
    • Require Antimalware
    7

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

    CreateInstanceEnumAsync called for the provider
    Class name CCM_SoftwareUpdateCompliance
    Days 5
    CCMSoftwareUpdateCompliance 20160313160716
    CCMSoftwareUpdateCompliance Select * from CCM_UpdateCIAssignment
    Determined 0 as not compliant with deadline exceeded by 5 days
    CCMEncryptionCompliance: Get instance of CCM_EncryptionCompliance
    Detected virtual machine: Drive encryption not applicable. Setting compliance to true
    Setting Encryption Compliance to: 1
    CheckWPJCert – Checking Machine\ cert store
    Found WorkplaceJoin cert
       Status: 2
       Error: 0
    CCMAntimalwareCompliance: Get instance of CCM_AntimalwareCompliance
    Retrieved RealTimeProtectionEnabled property = 1
    Retrieved AntivirusEnabled property = 1
    Setting Antimalware Compliance to: 1

    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
    CA_ConfigMgr Not applicable. A compliant managed PC will automatically have access. Meaning there is no special screen that the en-user will get.
    CA_SoftwareCenter_01 CA_SoftwareCenter_02

    More information

    For more information about conditional access for PCs that are managed by ConfigMgr, please refer to this article about Manage access to O365 services for PCs managed by System Center Configuration Manager.

    Managing AppLocker on Windows 10 via OMA-DM

    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.

    1 In the Local Group Policy Editor snap-in, navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker;
    2 In the Configure Rule Enforcement section, click Configure rule enforcement to open the AppLocker Properties;
    3 AppLockerPropertiesIn the AppLocker Properties, enable Configured with Package app Rules, select Enforce rules and click OK to return to the AppLocker node;
    4 Right-click the Packaged app Rules node and select Create Default Rules;
    5 Right-click the Packaged app Rules node and select Create New Rule to open the Create Package app Rules wizard;
    6 On the Before You Begin page, click Next;
    7 On the Permissions page, select Deny and click Next;
    8 AppLockerAppOn the Publisher page, select Use an installed packaged app as a reference and click Select to open the Select application dialog box;
    9 In the Select applications dialog box, select Candy Crush Soda Sage, click OK to return to the Publisher page and click Next;
    10 On the Exceptions page, click Next;
    11 On the Name and Description page, click Create;
    10 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.

    <AppLockerPolicy Version="1"> <RuleCollection Type="Exe" EnforcementMode="NotConfigured" /> <RuleCollection Type="Msi" EnforcementMode="NotConfigured" /> <RuleCollection Type="Script" EnforcementMode="NotConfigured" /> <RuleCollection Type="Dll" EnforcementMode="NotConfigured" /> <RuleCollection Type="Appx" EnforcementMode="Enabled"> <FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba" Name="(Default Rule) All signed packaged apps" Description="Allows members of the Everyone group to run packaged apps that are signed." UserOrGroupSid="S-1-1-0" Action="Allow"> <Conditions> <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*"> <BinaryVersionRange LowSection="0.0.0.0" HighSection="*" /> </FilePublisherCondition> </Conditions> </FilePublisherRule> <FilePublisherRule Id="8ea1fe67-536d-4324-99e2-88f9c9c70321" Name="king.com.CandyCrushSodaSaga, version 1.58.0.0 and above, from king.com" Description="" UserOrGroupSid="S-1-1-0" Action="Deny"> <Conditions> <FilePublisherCondition PublisherName="CN=F80C3B33-B9E8-4F23-AB15- B97C700EFF2F" ProductName="king.com.CandyCrushSodaSaga" BinaryName="*"> <BinaryVersionRange LowSection="1.58.0.0" HighSection="*" /> </FilePublisherCondition> </Conditions> </FilePublisherRule> </RuleCollection> </AppLockerPolicy>

    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.

    • AppLockerAppLaunch./Vendor/MSFT/AppLocker – Defines the root node for the AppLocker configuration service provider;
    • ApplicationLaunchRestrictions – Defines restrictions for applications;
    • Grouping – Defines dynamic nodes. These nodes contains a GUID naming that can be literally anything. That GUID makes sure that the un-enrollment of a device will behave as expected;
    • EXE | MSI | Script | StoreApps | DLL | CodeIntegrety – Defines restrictions for launching executable applications, Windows Installer files, scripts, store apps and DLL files;
    • 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.

    1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items;
    2 On the Home tab, click Create Configuration Item to open the Create Configuration Item Wizard;
    3

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

    • Name: [Specify a unique name for the configuration item]
    • Description: [Specify details that help identifying the configuration item]
    • Select Windows 8.1 and Windows 10 with Settings for devices managed without the Configuration Manager client.
    4

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

    • All Windows 10 (64-bit)
    • All Windows 10 (32-bit)
    • (Optional) All Windows 10 Mobile and higher
    5 On the Device Settings page, select Configure additional settings that are not in the default settings groups and click Next;
    6 On the Additional Settings page, click Add to open the Browse Settings dialog box.
    7 In the Browse Settings dialog box, click Create Setting to open the Create Setting dialog box;
    8

    AppLockerSettingIn the Create Setting dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

    • Name: [Specify a unique name for the setting]
    • Description: [Specify details that help identifying the setting]
    • Setting type: OMA-URI
    • Data type: String
    • OMA-URI (Case Sensitive): ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/[MyGroup0]/StoreApps/Policy

    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.

    9 In the Browse Settings dialog box, select the newly created setting and click Select to open the Create Rule dialog box;
    10

    AppLockerRuleIn the Create Rule dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

    • Name: [Specify a unique name for the rule]
    • Description: [Specify details that help identifying the
      rule]
    • Rule type: Value
    • The setting must comply with the following rule: Equals
    • the following values: <RuleCollection Type=”Appx” EnforcementMode=”Enabled”>[…]</RuleCollection>
    • Select Remediate noncompliant rules when supported

    Note: The complete RuleCollection element, about the Appx type, should be provided in this compliance rule configuration.

    11 In the Browse Settings dialog box, click Close to return to the Additional Settings page;
    12 On the Additional Settings page, click Next;
    13 On the Platform Applicability page, click Next;
    14 On the Summary page, click Next;
    14 On the Completion page, click Close;

    Note: This created a configuration item that can be deployed like any other configuration item, as a part of a configuration baseline.

    Microsoft Intune standalone

    Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure the required OMA-URI configuration policy.

    1 In the Microsoft Intune administration console, navigate to Policy > Configuration Policies and click Add to open the Create a New Policy dialog box;
    2 In the Create a New Policy dialog box, select Windows > Custom Configuration (Windows 10 Desktop and Mobile and later) and click Create Policy to open the Create Policy page;
    3

    On the Create Policy page, specify the following information in the General section and click Add in the OMA-URI Settings section to open the Add or edit OMA-URI Setting dialog box;

    • Name: [Specify a unique name for the policy]
    • Description: [Specify details that help identifying the policy]
    4

    AppLockerSetting_InIn the Add or edit OMA-URI Setting dialog box, specify the following information and click OK to return to the Create Policy page;

    • Setting name: [Specify a unique name for the setting]
    • Setting description: [Specify details that help identifying the setting]
    • Data type: String
    • OMA-URI (case sensitive): ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/[MyGroup0]/StoreApps/Policy
    • Value: <RuleCollection Type=”Appx” EnforcementMode=”Enabled”>[…]</RuleCollection>

    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
    AppLocker_OMA_URI AppLockerEventId

    More information

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

    Windows Phone 8.1 and the Windows Phone Store

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

    For the second and third scenarios I’ve used the wonderful app Snapcat, which is basically a selfie app for cats, as an example. The App URL for this app is the following: http://www.windowsphone.com/en-us/store/app/snapcat/7a1a6000-4956-4030-8862-831d3633d8b9.

    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 Standalone_ProhibitStoreThis 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 Hybrid_ProhibitStoreThis 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 Standalone_AllowedAppThis 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 Hybrid_AllowedAppThis 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 Standalone_BlockedAppThis 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 Hybrid_BlockedAppThis 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
    wp_ss_20150531_0001 wp_ss_20150531_0002 wp_ss_20150531_0003
    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:

    Manage Windows Defender, of Windows 10, via OMA-DM

    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 Windows10DefenderBaseline_Conditions_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 AllowRealtimeMonitoring_SettingThe 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 Monitoring
    Setting description: Allows or disallows Defender’s Realtime Monitoring functionality.
    Data type: Integer
    OMA-URI (case sensitive): ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoring
    Value: 1
    3 Windows10DefenderBaseline_Deployment_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 AllowRealtimeMonitoring_GeneralThe 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 Monitoring
    Description: Allows or disallows Defender’s Realtime Monitoring functionality.
    Setting type: OMA URI
    Data type: Integer
    OMA-URI (case sensitive): ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoring
    2 AllowRealtimeMonitoring_RuleThe 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 Monitoring
    Description: 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 1
    Select Remediate noncompliant rules when supported.
    3 Windows10DefenderBaseline_ConditionsThe 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 Windows10DefenderBaseline_DeploymentThe 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
    10222_DefenderBefore 10222_DefenderResult

    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
    AllowCloudProtection
    To 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.
    AVGCPULoadFactor
    Represents the average CPU load factor for the scan (in percent).
    Valid values (Integer): 0–100.
    DaysToRetainCleanedMalware
    Time period (in days) that quarantine items will be stored on the system.
    Valid values (Integer): 0–90.
    AllowArchiveScanning
    Allows or disallows scanning of archives.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowBehaviorMonitoring
    Allows or disallows Defender’s Behavior Monitoring functionality.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowEmailScanning
    Allows or disallows scanning of email.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowFullScanOnMappedNetworkDrives
    Allows or disallows a full scan of mapped network drives.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowFullScanRemovableDriveScanning
    Allows or disallows a full scan of removable drives.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowIntrusionPreventionSystem
    Allows or disallows Defender’s Intrusion Prevention functionality.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowIOAVProtection
    Allows or disallows Defender’s IOAVP Protection functionality.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowOnAccessProtection
    Allows or disallows Defender’s On Access Protection functionality.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowRealtimeMonitoring
    Allows or disallows Defender’s Realtime Monitoring functionality.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowScanningNetworkFiles
    Allows or disallows a scanning of network files.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowScriptScanning
    Allows or disallows Defender’s Script Scanning functionality.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    AllowUserUIAccess
    Allows or disallows user access to the Defender UI. If disallowed, all Defender notifications will also be suppressed.
    Supported values (Integer):

    • 0 – Not allowed;
    • 1 (default) – Allowed.
    ExcludedExtensions
    Allows an administrator to specify a list of file type extensions to ignore during a scan.
    Each file type in the list must be separated by | (String). For example, zip|exe.
    ExcludedPaths
    Allows an administrator to specify a list of directory paths to ignore during a scan.
    Each path in the list must be separated by | (String). For example, C:\Data|C:\Temp.
    ExcludedProcesses
    Allows an administrator to specify a list of files opened by processes to ignore during a scan.
    Each file type must be separated by a | (String). For example, C:\Program Files\7-Zip\7zG.exe|C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitReader.exe.
    RealTimeScanDirection
    Controls which sets of files should be monitored.
    Supported values (Integer):

    • 0 (default) – Monitor all files (bi-directional).
    • 1 – Monitor incoming files.
    • 2 – Monitor outgoing files.
    ScanParameter
    Selects whether to perform a quick scan or full scan.
    Supported values (Integer):

    • 1 (default) – Quick scan;
    • 2 – Full scan.
    ScheduleQuickScanTime
    Selects the time of day (in minutes) that the Defender quick scan should run.
    Valid values (Integer): 0–1380
    ScheduleScanDay
    Selects the day that the Defender scan should run.
    Supported values (Integer):

    • 0 (default) – Every day;
    • 1 – Monday;
    • 2 – Tuesday
    • 3 – Wednesday;
    • 4 – Thursday;
    • 5 – Friday;
    • 6 – Saturday;
    • 7 – Sunday;
    • 8 – No scheduled scan
    ScheduleScanTime
    Selects the time of day (in minutes) that the Defender scan should run.
    Valid values: 0–1380 (Integer).
    SignatureUpdateInterval
    Specifies the interval (in hours) that will be used to check for signatures.
    Valid values: 0–24 (Integer).
    SubmitSamplesConsent
    Checks for the user consent level in Defender to send data. If the required consent has already been granted, Defender submits them.
    Supported values (Integer):

    • 0 – Always prompt;
    • 1 (default) – Send safe samples automatically;
    • 2 – Never send;
    • 3 – Send all samples automatically.

    More information

    For more information about all the possible configuration policies in Windows 10, see the Policy Configuration Service Provider documentation: https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962%28v=vs.85%29.aspx

    Manage company policies on Windows Phone 8.1 via OMA-URI settings in Microsoft Intune

    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:

    • MicrosoftIntune_OMAURI_AddEditLogon on to the Microsoft Intune administration console;
    • Navigate to Policy > Configuration Policies;
    • Click Add… and the Create a New Policy dialog box will show;
    • Navigate to Windows > Windows Phone OMA-URI Policy;
    • Select Create and Deploy a Custom Policy, click Create Policy and the Create Policy page will show;
    • Provide a <Name> and click Add… with OMA-URI Settings and the Add or Edit OMA-URI Setting dialog box will show.
    • Provide the following information and click OK:
      • Setting name: Allow Cellular Data Roaming;
      • Setting description: Allow or disallow cellular data roaming;
      • Data type: Integer;
      • OMA-URI (case sensitive): ./Vendor/MSFT/PolicyManager/My/Connectivity/AllowCellularDataRoaming;
      • Value: 0;
    • Click Save Policy and the Deploy Policy: <Name> dialog box will show;
    • Click Yes and the Manage Deployment: <Name> dialog box will show;
    • Select (a) group(s), click Add and click OK.

    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.

    MicrosoftIntune_OMAURI

    Further reading

    More information about using OMA-URI settings with ConfigMgr (integrated with Microsoft Intune) can be found in this post about THE Windows Phone 8.1 Configuration Baseline. Additional to that post is this post about Extending the hardware inventory for PolicyManager settings on the Windows Phone 8.1. That post describes the same OMA-URI settings, but then how to add them to the hardware inventory.

    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.