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:

    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

    Windows Phone 8.1 and the Microsoft Intune Company Portal app

    CompanyPortalAppLogoThis blog post will be about the magical world of Windows Phone 8.1 and the Microsoft Intune Company Portal app. More specifically, about Windows Phone 8.1 and the two Microsoft Intune Company Portal apps. The Microsoft Intune Company Portal app of the Windows Phone Store and the Microsoft Intune Company Portal app deployed via either Microsoft Intune or ConfigMgr.

    Yes, I know there was recently a KB article released about the same subject. In this post I’ll go through more scenarios and I’ll go in more detail about the possible solutions and the pro’s and cons of those solutions.

    Scenarios

    Now lets start with summarizing the different scenarios that are possible with the combination of Microsoft Intune, ConfigMgr, Windows Phone 8.1 and the Microsoft Intune Company Portal app. I found the following three scenarios and I’ll go through them in detail after listing them:

    • Scenario 1: Microsoft Intune standalone without code-signing certificate;
      • This scenario will be about the management of just Windows Phone 8.1 devices and no requirement of a code-signing certificate;
    • Scenario 2: Microsoft Intune standalone with code-signing certificate;
      • This scenario will be about the management of Windows Phone 8.1 devices and the requirement of either a code-signing certificate, or the management of Windows Phone 8 devices;
    • Scenario 3: Microsoft Intune integrated with ConfigMgr;
      • This scenario will be about the management of Windows Phone devices.

    Scenario 1 – Microsoft Intune standalone without code-signing certificate

    Intune_WindowsPhoneThe first scenario is also the easiest scenario. With Microsoft Intune standalone and no need for code-signing certificates, or the management of Windows Phone 8 devices, there will not be a problem with possibly installing the two versions of the Microsoft Intune Company Portal app.

    In this scenario simply use the the Microsoft Intune Company Portal app of the Windows Phone Store.

    Scenario 2 – Microsoft Intune standalone with code-signing certificate

    Intune_WindowsPhone881The second scenario will be more complicated. With Microsoft Intune standalone and the requirement of either a code-signing certificate, or the management of Windows Phone 8 devices, there can be challenges with possibly installing the two versions of the Microsoft Intune Company Portal app.

    When a code-signing certificate, or the management of Windows Phone 8 devices, is required, it’s also required to upload a signed Microsoft Intune Company Portal app to Microsoft Intune. That process will automatically create a deployment for the Microsoft Intune Company Portal app. After this, even the enrollment of Windows Phone 8.1 is not possible without a deployment of the Microsoft Intune Company Portal app. This gives us two options to choose from for the Microsoft Intune Company Portal app.

    Company Store app

    The first option is to make the Microsoft Intune Company Portal app, deployed via Microsoft Intune, the only available Microsoft Intune Company Portal app by blocking the version from the Windows Phone Store.

    Intune_CompanyPortalBlockThis can be achieved by creating a Configuration Policy in Microsoft Intune. That Configuration Policy  has to be a Windows Phone Configuration Policy and has to be configured to Block devices from opening the listed apps. The list of blocked apps has to contain the Microsoft Intune Company Portal app URL of http://www.windowsphone.com/en-us/store/app/company-portal/0b4016fc-d7b2-48a2-97a9-7de3b5ea742 in the App URL.

    That configuration will make sure that the Microsoft Intune Company Portal app, deployed via Microsoft Intune, truly is the only available Microsoft Intune Company Portal app. It’s now not possible anymore to have two functional Microsoft Intune Company Portal apps on a Windows Phone 8.1 device.

    Windows Phone Store app

    The other option would be to make the Microsoft Intune Company Portal app, of the Windows Phone Store, (close to) the only available Microsoft Intune Company Portal app by changing the deployment of the Microsoft Intune Company Portal app in Microsoft Intune. Intune_CompanyPortalUninstallThat’s possible because the deployment is accepted in both the install and the uninstall state.

    This can be achieved by editing the standard created deployment of the Microsoft Intune Company Portal app. The standard Approval configuration is Available Install and that can be adjusted to Uninstall. Using Not applicable is not an option as it will cause failures similar to when no deployment exists.

    wp_ss_20150412_0001That configuration will make the Microsoft Intune Company Portal app, of the Windows Phone Store, almost always the only available Microsoft Intune Company Portal app. There remains one situation in which it’s still possible to install the Microsoft Intune Company Portal app, deployed via Microsoft Intune. That situation comes when the workplace settings of the company are opened. This provides the option of download hub, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed through Microsoft Intune. No matter how the deployment is configured, this option will always be available in this scenario.

    Scenario 3 – Microsoft Intune integrated with ConfigMgr

    ConfigMgr_WindowsPhone881The third scenario is as complicated as the second scenario. With Microsoft Intune integrated with ConfigMgr, there can also be challenges with possibly installing the two versions of the Microsoft Intune Company Portal app.

    When Windows Phone enrollment is enabled, it’s also required to add an application of a signed Microsoft Intune Company Portal app. That application has to be deployed to be able to enroll a Windows Phone 8.1 device. This gives us two options to choose from for the Microsoft Intune Company Portal app.

    Company Store app

    The first option is to make the Microsoft Intune Company Portal app, deployed via ConfigMgr, the only available Microsoft Intune Company Portal app by blocking the version from the Windows Phone Store.

    This can be achieved by creating a Configuration Baseline in ConfigMgr. That Configuration Baseline has to contain a Configuration Item with at least the following configuration:

    • imageSetting type: OMA URI
    • Data type: String
    • OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ ApplicationRestrictions
    • Compliance: Equals <AppPolicy Version=”1″ xmlns=”http://schemas.microsoft.com/phone/2013/policy”><Deny> <App ProductId=”{0b4016fc-d7b2-48a2-97a9-7de3b5ea7424}”/> </Deny></AppPolicy>

    That configuration will make the Microsoft Intune Company Portal app, deployed via Microsoft ConfigMgr, truly the only available Microsoft Intune Company Portal app. It’s now not possible anymore to have two functional Microsoft Intune Company Portal apps on a Windows Phone 8.1 device.

    Windows Phone Store app

    The other option would be to make the Microsoft Intune Company Portal app, of the Windows Phone Store, (close to) the only available Microsoft Intune Company Portal app by changing the requirements of the Microsoft Intune Company Portal app in ConfigMgr.

    imageThis can be achieved by editing the requirements of the standard Deployment Type of the Microsoft Intune Company Portal app and adding a requirement for only Windows Phone 8.0 devices. This requirement will make sure that the Microsoft Intune Company Portal app will not show in any Company Portal, on a Windows Phone 8.1 device, as an optional installation.

    That configuration will make the Microsoft Intune Company Portal app, of the Windows Phone Store, almost always the only available Microsoft Intune Company Portal app. There remains a couple of situations in which it’s still possible to install the Microsoft Intune Company Portal app, deployed via ConfigMgr.

    • wp_ss_20150413_0001The first situation comes during the enrollment of a Windows Phone 8.1 device. After the account is added there is the option of Install company app, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed via ConfigMgr.
    • The second situation comes when the workplace settings of the company are opened. This provides the option of download hub, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed via ConfigMgr.

    No matter how the application is configured, these option will always be available in this scenario.

    Conclusion

    Even though I like the Microsoft Intune Company Portal app, of the Windows Phone Store, more, it does not seem to be possible, yet, to completely remove the Microsoft Intune Company Portal app that’s deployed through either Microsoft Intune or ConfigMgr. There always seems to be a way to “secretly” install a second Microsoft Intune Company Portal app that’s deployed via either Microsoft Intune or ConfigMgr. Simply keep this in mind with determining how to manage applications on Windows Phone 8.1 devices. That will save a lot of confusion with the end-user.

    Set the allowed Management Points via a Configuration Item in ConfigMgr 2012

    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

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

    This all comes together in the following script:

    try { $strKeyPath = "HKLM:SOFTWARE\Microsoft\CCM" if (!(Test-Path -Path $strKeyPath)) { $Compliance = "Key does not exist" } else { $strAllowedMPs = (Get-ItemProperty ` -Path $strKeyPath).AllowedMPs if ($strAllowedMPs -eq $null) { $Compliance = "Value does not exist" } else { $Compliance = $strAllowedMPs -join "," } } } catch { $Compliance = $Error.Exception $Error.Clear() } finally { $Compliance }

    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.

    This all comes together in the following script:

    try { $strKeyPath = "HKLM:SOFTWARE\Microsoft\CCM" if (!(Test-Path -Path $strKeyPath)) { New-Item -Path $strKeyPath -Force } foreach ($arg in $args) { New-ItemProperty $strKeyPath -Name AllowedMPs ` -Value $arg -PropertyType MultiString -Force } } catch { $Error.Exception $Error.Clear() }

    Compliance rule

    Rule_AllowedMPsThe 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:

    1. 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 (“,”).
    2. 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.

    >> The complete configuration item is available via download in the TechNet Galleries! <<

    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.

    Result_AllowedMPs

    Create a WQL query setting for a Configuration Item in ConfigMgr 2012 via PowerShell

    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

    WqlQuerySettingThe 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

    WqlSettingXMLThe 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:

    #Set the WqlQuerySetting object information $WqlQuerySettingDataType = ([Microsoft.ConfigurationManagement.` DesiredConfiguration.Rules.ScalarDataType]::Int64) $WqlQuerySettingLogicalName = "WqlSetting_$([Guid]::NewGuid())" $WqlQuerySettingName = "$WqlQuerySettingClass"+"_"+"$WqlQuerySettingProperty" $WqlQuerySettingDescription = "Scripted setting"

    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:

    #Create the WqlQuerySetting object and set the properties $WqlQuerySetting = New-Object -TypeName Microsoft.ConfigurationManagement.` DesiredConfiguration.Settings.WqlQuerySetting -ArgumentList ` $WqlQuerySettingDataType,$WqlQuerySettingLogicalName,` $WqlQuerySettingName,$WqlQuerySettingDescription $WqlQuerySetting.Class = $WqlQuerySettingClass $WqlQuerySetting.Namespace = $WqlQuerySettingNamspace $WqlQuerySetting.Where = $WqlQuerySettingWhere $WqlQuerySetting.Property = $WqlQuerySettingProperty

    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:

    #Set the WqlQuerySetting properties $WqlQueryClass = "Win32_OptionalFeature" $WqlQueryNamespace = "root\cimv2" $WqlQueryWhere = "Name='BITS'" $WqlQueryProperty = "InstallState"

    Step 4: Write the WqlQuerySetting to the Configuration Item

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

    >> The complete function is available via download here on the TechNet Galleries! <<