Configuration Item

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:

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.

This blog post will be about a new functionality that got introduced in Cumulative Update 3. This is the ability to configure a Management Point (MP) affinity on a client. Justin Chalfant wrote a nice post about this functionality. That post describes the functionality in detail and also shows how it can be configured. The only thing left open is an automated method to configure the MP affinity. This post will fill that small gap by providing a Configuration Item (CI) that contains the scripts to configure the MP affinity.

Configuration Item

Now let’s start with the details about the CI. Personally I really like this CI, as it’s created in such a way that it doesn’t need any script modifications any more. The discovery script and the remediation script, both interact in a way with the compliance rule. The discovery script makes sure that it puts the data of the AllowedMPs value in a readable format to compare it with the value of the compliancy rule and the remediation script makes sure that it uses the value of the compliance rule as an input parameter for the remediation. Now let’s go through these scripts and the compliancy rule in a bit more detail.

Discovery script

The discovery script does nothing really fancy, but it does something important that I need for checking the data of the current AllowedMPs value. Basically the script performs the following four actions:

First, it checks if the registry key HKLM:SOFTWARE\Microsoft\CCM exists and if it does not exist it sets the compliance variable to “Key does not exist”. Actually, this check should always pass, as this registry key is created during the installation of the ConfigMgr client;

Second, it gets the data of the AllowedMPs value, when the registry key does exist .

Third, it checks if the AllowedMPs value exists and if it does not exist it sets the compliance variable to “Value does not exist”.

Fourth, it reads the data of the AllowedMPs value, adds it to a string separated by comma’s (“,”) and sets the compliance variable to that string. This makes sure that the compliance variable can be used to verify the server names configured in the compliance rule.

Remediation script

The remediation script also does nothing really fancy, but it does something really important for configuring the data of the AllowedMPs value. Basically the script performs the following two actions:

First, it checks if the registry key HKLM:SOFTWARE\Microsoft\CCM exists and if it does not exist it will create it. Actually, this check should always pass, as this registry key is created during the installation of the ConfigMgr client;

Second, it loops through the input arguments of the script and creates the AllowedMPs value with the input arguments as data. These input arguments are the server names configured in the compliance rule.

Compliance rule

The compliance rule is where it all comes together. In both, the discovery script and the remediation script, I mentioned the link with the compliance rule. In the compliance rule I can configure the MPs that I would like to be configured as data for the AllowedMPs value. In this compliance rule there are two core configurations to make this CI work:

The The value returned by the specified script setting is configured to Equals the following value servername1,servername2. The key here is that the server names are separated by only a comma (“,”).

The Run the specified remediation script when this settings is noncompliant box is checked. This is to make sure that the remediation script is used.

Usage

To make it really easy for everyone, I exported the CI and made it available for download via the TechNet Galleries. Simply download this CI and import it in ConfigMgr. After that there is only one important step left. That step is to configure the server names as mentioned in the compliance rule section. Currently it’s set to server names from my lab environment. Simply change these server names to the server names required for the specific environment. Keep in mind that it should be noted as servername1,servername2 and that those server names should be the FQDN of those servers. Also note that I would advise to specify at least two server names, to provide some sort of a fallback scenario for the ConfigMgr client.

Result

Now it’s time to take a look at the compliancy results of a client. Basically all clients should show compliant, simply because they will be remediated when they’re not. The first time this CI will run on the client, it will show the old value and the remediated value in the reports. As that will show a nice overview of the actions that are performed, I used that to show the results below. Also, I picked the client-side report instead of the server-side report. The only reason for that is its size, this report is more compact.

Before I start with this blog post I have to give some (read: a lot) of credits to Dexter. He helped me a lot with understanding the SDMPackageXML of a Configuration Item (CI) and also blogged about that experience. Also, this blog post won’t go into the details he already mentioned about modifying the XML and writing it to a CI.

Now let’s really start with this blog post. This blog post will be about creating a WQL query setting for a CI and more specifically the road to creating a WQL query setting for a CI.

Step 1: Locate the method to create the WqlQuerySetting

The first step is to locate the method that can be used to create the WqlQuerySetting. During the installation of the Configuration Manager Console many files are installed and registered including a DLL named Microsoft.ConfigurationManagement.DesiredConfiguration.dll. This specific DLL contains the functions that are needed to create settings and compliance rules for a CI. Opening this DLL with something like the Object Browser of Visual Studio will show the different methods and parameters included. This will show the following information about creating the setting WqlQuerySetting(Microsoft.ConfigurationManagement.DesiredConfiguration.Rules.DataType settingDataType, string logicalName, string name, string description).

Step 2: Locate and set the object information for the WqlQuerySetting

The second step is to set the information to different input parameters that are required to create the setting. Based on the information, found in the DLL, it’s clear what information is needed and based on an existing SDMPackageXML it’s also clear what it should look like. Specifically for setting the logicalName it’s good to know the prefix of the GUID (as it differs per setting type). Another thing to look at is the settingDataType. The easiest method to find correct values for this is by browsing to the object in Visual Studio. Together this brings me to the following input variables for creating the WqlQuerySetting:

Step 3: Create the WqlQuerySetting and set the properties

The third step is to really create the WqlQuerySetting object and to set the properties for the new object. Again the easiest method to find the available properties is by browsing the class. Together this brings me to the following code for creating the setting and setting the properties:

One might notice that I used all variables to fill these properties. That’s because I use this as part of a complete method that requires the values to those properties as input, so it can be reused. An example for these properties would be something like the following:

Step 4: Write the WqlQuerySetting to the Configuration Item

The fourth, and last, step is to add the WqlQuerySetting to a CI. To do this it is important to add it to the correct element of the SDMPackageXML. This is also were it differs from what Dexter did and by that also the reason why I’m mentioning it. The setting needs to be added to the RootComplexSetting element and the tricky part is that it’s an empty element at the beginning. The following code gets the right part of the WqlQuerySetting and adds it to the SDMPackageXML.

#Import the WqlQuerySettingXML node to the SDMPackageXML of the CI$ImportNodeXML= `
$CISDMPackageXML.ImportNode($WqlQuerySettingXML.SimpleSetting,$true)
#Add the imported node to the SDMPackageXML of the CI$CISDMPackageXML.DesiredConfigurationDigest.OperatingSystem.Settings.`
ChildNodes[0].AppendChild($ImportNodeXML)

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!