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.

    Updated Configuration Baseline and Hardware Inventory for Windows Phone 8.1

    Microsoft has started with releasing the GDR2 update for Windows Phone 8.1. The good thing from a management perspective is that this update contains new management features. There are seven new additions to the PolicyManager configuration service provider (CSP). As I created the Windows Phone 8.1 configuration baseline and the Windows Phone 8.1 hardware inventory extension, I’ve updated both of them with these latest additions. This blog post will describe the newly added settings and a reminder about the download locations.

    Note: Another new feature that comes with the GDR2 update is bulk enrollment. Even though it’s not part of this post, I thought it’s definitely worth mentioning. For more information see the Windows Phone 8.1 MDM Protocol document.

    New settings

    The newly added settings are described in the latest version of the Windows Phone 8.1 MDM Protocol document. Based on that document I’ve added the following policies to the inventory and the baseline:

    • ./Vendor/MSFT/PolicyManager/My/Connectivity/CellularAppDownloadMBLimit;
      This policy specifies the maximum app file size in MB allowed for downloading through cellular connection.
    • ./Vendor/MSFT/PolicyManager/My/Connectivity/AllowManualVPNConfiguration;
      This policy allows the enterprise to enforce a VPN protection by disabling all VPN settings.
    • ./Vendor/MSFT/PolicyManager/My/Wifi/WLANScanMode;
      This policy defines the frequency mode for active Wi-Fi scanning trigger when screen is off and on.
    • ./Vendor/MSFT/PolicyManager/My/Experience/AllowTaskSwitcher;
      This policy allows the company to disable the task switcher completely.
    • ./Vendor/MSFT/PolicyManager/My/Security/AntiTheftMode;
      This policy allows enterprises to prevent users from enabling the Anti Theft mode.
    • ./Vendor/MSFT/PolicyManager/My/DataProtection/RequireProtectionUnderLockConfig;
      This policy allows data encryption of email data and associated attachments.
    • ./Vendor/MSFT/PolicyManager/My/DataProtection/EnterpriseProtectedDomainNames;
      This policy specifies the enterprise domain names.

    Note: These settings will fail on devices that are not updated to Windows Phone 8.1 GDR2.

    Available for download

    Starting today these updated files are available for download via the TechNet Galleries on the following locations:

    Further reading

    The information about the configurable enterprise polices can be found in the Windows Phone 8.1 MDM Protocol document, starting with page 144. As mentioned before, this living document is available for downloaded here: http://go.microsoft.com/fwlink/?LinkID=279003

    Verify SSL Configurations of Site Roles via Compliance Settings in ConfigMgr 2012

    This will be a short blog post about the locations in the registry where the SSL configurations are stored for the different site roles. This can be very useful in larger environments, with many sites, site systems and multiple administrators. These registry keys can be used as Configuration Items in a Configuration Baseline. This makes it easier to keep track of the SSL configuration of the environment.

    Registry

    Before providing the different locations, I think it’s good to note that the most site roles simply use 0 or 1 as values for a SSL configuration. Exceptions on this are the management point and the distribution point. These site roles can have different values based on the connection configuration (intranet and Internet, intranet-only, Internet-only) and CRL checking configuration. For all roles 0 stands for HTTP and everything greater than 0 stands for HTTPS.

    Application Catalog web service point
    Hive Name: HKEY_LOCAL_MACHINE
    Key Name: SOFTWARE\Microsoft\SMS\AWEBSVC
    Value Name: UseSSL
    Compliance: UseSSL Equals 1 (UseSSL must exist)

    Application Catalog website point
    Hive Name: HKEY_LOCAL_MACHINE
    Key Name: SOFTWARE\Microsoft\SMS\PORTALWEB
    Value Name: UseSSL
    Compliance: UseSSL Equals 1 (UseSSL must exist)

    Distribution point
    Hive Name: HKEY_LOCAL_MACHINE
    Key Name: SOFTWARE\Microsoft\SMS\DP
    Value Name: IISSSLState
    Compliance: IISSSLState Greater than 0 (IISSSLState must exist)

    Management point
    Hive Name: HKEY_LOCAL_MACHINE
    Key Name: SOFTWARE\Microsoft\SMS\MP
    Value Name: SSLState
    Compliance: SSLState Greater than 0 (SSLState must exist)

    Software update point
    Hive Name: HKEY_LOCAL_MACHINE
    Key Name: SOFTWARE\Microsoft\Update Services\Server\Setup
    Value Name: UsingSSL
    Compliance: UsingSSL Equals 1 (UsingSSL must exist)

    Installing Windows Features via Compliance Settings in ConfigMgr 2012

    This weeks’ post will be about Installing Windows Features via Compliance Settings. In most cases the normal route for installing Windows Features will be the application model But what if checking for the installation of a Windows Feature is part of a Configuration Baseline, is it than possible to make the installation of a Windows Feature also part of the baseline? The answer to this question is, yes.

    In my case, I have a Windows 8.1 Configuration Baseline and one of the Configuration Items in the baseline checks for the installation of the Telnet Client. When the Telnet Client is not installed a script will start to remediate that by installing the Telnet Client. This way I get the complete compliance of a device, to my Windows 8.1 baseline, in one overview.

    The rest of this post will describe in three steps, how to create the Configuration Item, how to create the Configuration Baseline and how to deploy the Configuration Baseline.

    Step 1: Create the Configuration Item

    Now lets start with the first step of creating a Configuration Item that will check and remediate the installation of the Telnet Client. Both, the check and the remediation will be done by firing a PowerShell script.

    • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items.
    • On the Home tab, in the Create group, click Create Configuration Item and the Create Configuration Item Wizard will popup.
    • On the General page, fill in with Name <aCIName> and click Next.
    • On the Supported Platforms page, select Windows 8.1 and click Next.
    • TelnetClientSettingOn the Settings page, click New, fill in the following information and click Next.
      • On the General tab, fill in the following information and click OK.
        • Fill in as Name <aSName>.
        • Select as Setting Type Script.
        • Select as Data Type String.
        • Click with Discovery script Edit Script… and in the Edit Discovery Script popup add the following script and click Ok.
          $FeatureName = "TelnetClient" If (Get-WindowsOptionalFeature -Online | Where {$_.State ` -eq "Enabled" -and $_.FeatureName -eq $FeatureName}) { $Compliance = "Compliant" } Else { $Compliance = "NonCompliant" } Return $Compliance

        • Click with Remediation script (optional) Edit Script… and in the Edit Discovery Script popup add the following script and click OK.
          $FeatureName = "TelnetClient" Enable-WindowsOptionalFeature -Online -FeatureName $FeatureName

      • TelnetClientRuleOn the Compliance Rules tab, click New, fill in the following information and click OK.
        • Fill in as Name <aRName>.
        • Select as Rule Type Value.
        • Select with The settings must comply with the following rule: Equals.
        • Fill in with the following values Compliant.
          • Note: This value is important for it to function, as it is “hardcoded” in the script.
        • Select Run the specified remediation script when this setting is noncompliant.
        • Select with Noncompliance severity for reports: Information.
    • On the Compliance Rules page click Next.
    • On the Summary page click Next.
    • On the Completion page click Close.

    Step 2: Create the Configuration Baseline

    The second step is to create a Configuration Baseline that will allow the new Configuration Item to be evaluated for compliance.

    • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines.
    • TelnetClientBaselineOn the Home tab, in the Create group, click Create Configuration Baseline and the Create Configuration Baseline popup will show.
    • On the Create Configuration Baseline popup, fill in with Name <aCBName> and click Add > Configuration Item and the Add Configuration Items popup will show.
    • On the Add Configuration Items popup select the new Configuration Item <aCIName>, click Add, click OK and back on the Create Configuration Baseline popup click OK.

    Step 3: Deploy the Configuration Baseline

    The third and final step is to deliver the Configuration Baseline to the client devices by deploying it.

    • TelnetClientDeploymentIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines.
    • Select the new Configuration Baseline <aCBName> and on the Home tab, in the Deployment group, click Deploy and the Deploy Configuration Baselines popup will show.
    • On the Deploy Configuration Baselines popup, select Remediate noncompliant rules when supported, Browse to <aCollection> and click OK.

    Conclusion

    Even though a Configuration Baseline is not the most conventional way for installing Windows Features, it’s a good possibility for specific use cases. In case the check for existence of a feature is part of the baseline, then it would be an option to put the remediation in the same baseline. That way there is one view to check for the baseline compliance and not a specific view with deployment states. In most cases a normal application deployment, or task sequence deployment, will fit the needs. Don’t use this because it’s possible, but because it fits the needs.

    Allow Direct Installation of Windows 8 Apps via Compliance Settings in ConfigMgr 2012

    This weeks’ post will be about Allowing Direct Installation of Windows 8 Apps via Compliance Settings and can be seen as either a stand-alone post as well as a follow-up on my last post about Deploying Certificate Profiles with ConfigMgr 2012 . As there are two real requirements to deploy Windows 8 Apps:

    • The Certification Authority (CA), that is used to sign the App, is trusted by the Windows 8 device.
    • Allow Direct Installation of Windows 8 Apps is configured on the Windows 8 device.

    Of course these settings are configurable via Group Policies (as described in this post ), but, to use Group Policies, the device needs to be a member of the domain. So when either the device isn’t domain joined, or the company likes one way to configure a setting for all devices, see part 1 of this post for deploying a root certificate and read the rest of this post for Allowing Direct Installation of Windows 8 Apps .

    Create the Configuration Item

    Now lets start with creating a Configuration Item that will check and remediate the existence and value of the value AllowAllTrustedApps in the key HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx .

    • In the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items .
    • On the Home tab, in the Create group, click Create Configuration Item and the Create Configuration Item Wizard will popup.
    • On the General page, fill in with Name <aCIName> and click Next .
    • On the Supported Platforms page, select Windows 8 and Windows 8.1 Preview and click Next .
    • AllowAllTrustedAppsOn the Settings page, click New , fill in the following information and click Next .
      • On the General tab, fill in the following information and click OK .
        • Fill in as Name <aSName> .
        • Select as Setting Type Script .
        • Select as Data Type String .
        • Click with Discovery script Edit Script… and in the Edit Discovery Script popup add the following script and click Ok .
          $Path = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Appx" If (!(Test-Path -Path $Path)) { $Compliance = "NonCompliant" } Else { If ((Get-ItemProperty -Path $Path).AllowAllTrustedApps -ne 1) { $Compliance = "NonCompliant" } Else { $Compliance = "Compliant" } } Return $Compliance

        • Click with Remediation script (optional) Edit Script… and in the Edit Discovery Script popup add the following script and click OK .
          $Path = "HKLM:SOFTWARE\Policies\Microsoft\Windows\Appx" If (!(Test-Path -Path $Path)) { New-Item -Path $Path -Force } New-ItemProperty $Path -Name AllowAllTrustedApps -Value 1 -Force

      • AllowAllTrustedApps_CompliantOn the Compliance Rules tab, click New , fill in the following information and click OK .
        • Fill in as Name <aRName> .
        • Select as Rule Type Value .
        • Select with The settings must comply with the following rule: Equals .
        • Fill in with the following values Compliant .
          • Note : This value is important for it to function, as it is “hardcoded” in the script.
        • Select Run the specified remediation script when this setting is noncompliant .
        • Select with Noncompliance severity for reports: Information .
    • On the Compliance Rules page click Next .
    • On the Summary page click Next .
    • On the Completion page click Close .

    Create the Configuration Baseline

    The second thing to do is to create a Configuration Baseline to allow the new Configuration Item to be evaluated for compliance.

    • ConfBaseIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines .
    • On the Home tab, in the Create group, click Create Configuration Baseline and the Create Configuration Baseline popup will show.
    • On the Create Configuration Baseline popup, fill in with Name <aCBName> and click Add > Configuration Item and the Add Configuration Items popup will show .
    • On the Add Configuration Items popup select the new Configuration Item <aCIName> , click Add , click OK and back on the Create Configuration Baseline popup click OK .

    Deploy the Configuration Baseline

    The last thing to do is to deliver the Configuration Baseline to the client devices by deploying it.

    • DeplConfBaseIn the Configuration Manager Console navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines .
    • Select the new Configuration Baseline <aCBName> and on the Home tab, in the Deployment group, click Deploy and the Deploy Configuration Baselines popup will show.
    • On the Deploy Configuration Baselines popup, select Remediate noncompliant rules when supported , Browse to <aCollection> and click OK.

    Results

    As always, now it is time to take a look at the results! There is a lot to show, like log files, the checked and/or created registry key and even the compliance information. I think the nicest one, in this situation, is the DcmWmiProvider.log , as it will show the information about running the different scripts. The log will show the result of running the discovery script, followed by the remediation script and their results. DcmWmiProvLog

    Deployment of Configuration Baseline failed with error ‘Script is not signed’ in ConfigMgr 2012

    This week my post will still be a small one, as my time is still limited during the move to our new home. In between I was still doing some work and trying to find a subject for a presentation/ demo. During that I was working with the Configuration Baseline of UE-V. That baseline is completely based on one Configuration Item, which consists of eight script setting types and those scripts are all written in PowerShell. The deployment of the baseline resulted in error 0x87D00327, which translates to ‘Script is not signed’ (see picture).ScriptIsNotSigned

    Solution

    In most cases it’s not possible, or allowed, to change the execution policy for PowerShell on the system. So just let the ConfigMgr client “manage it” and then the solution is actually very simple. In the Client Settings, under Computer Agent, there is an option to configure the PowerShell execution policy. The only pitfall in here is that it means something different then someone might think. These are the options:

    • Bypass: The ConfigMgr client bypasses the PowerShell configuration on the local system so that unsigned scripts can run.
    • Restricted (default in ConfigMgr 2012): The ConfigMgr client uses the current PowerShell configuration on the local system, which determines whether, or not, unsigned scripts can run.
    • All Signed (default in ConfigMgr 2012 SP1):The ConfigMgr client runs scripts only if they are signed by a trusted publisher and applies independently from the current PowerShell configuration on the local system.

    PSExecPoliThe easiest way to configure this, for the Configuration Baseline, is to follow the next steps:

    • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
    • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
    • On the General page, fill in with Name <aName> and select Computer Agent.
    • On the Computer Agent page, select next to PowerShell execution policy Bypass and click Ok.
    • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
    • Select <aDeviceCollection> and click Ok.

    Result

    PoliSpyPSExecAs always, now it’s time to take a look at the result. In this case it would be easy to just show a good result of the deployment of the Configuration Baseline, but I want to show some more. I want to show the result of the deployment of the new Client Settings. Normally, the best places to look at the results are the log files. In this case, there is no log file that shows the current setting of the PowerShell execution policy. So the best place to look at that is the old-school Policy Spy. In this case it will show PowerShellExecutionPolicy = 1 as a setting under, Machine \ CCM_ClientAgentConfig. The meaning of the different possible values are:

    • 0 = All signed
    • 1 = ByPass
    • 2 = Restricted

    More information: http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_ComputerAgentDeviceSettings