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:

    Share

    Conditional access and health attestation

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

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

    Introduction

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

    • BitLocker: BitLocker provides encryption for all data stored on the Windows operating system volume.
    • Code integrity: Code Integrity provides improvements to the security of the operating system by validating the integrity of a driver, or system file, each time it is loaded into memory.
    • Early-launch antimalware (only applies to PCs): Early launch anti-malware (ELAM) provides protection for computers when they start up and before third-party drivers initialize.
    • Secure boot: Secure boot provides a security standard, which is developed by members of the PC industry, to help make sure that a PC boots with only software that is trusted by the PC manufacturer.

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

    Pre-configuration

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

    Default client settings

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

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

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

    Health attestation dashboard

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

    CA_Intune_HealthAttestation

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

    Configuration

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

    Conditional access policy

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

    Exchange Online Policy SharePoint Online Policy
    CA_ExchOnl_Win10 CA_SPOnl_Win10

    Compliance policy

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

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

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

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

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

    4

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

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

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

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

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

    7

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

    8 On the Summary page, click Next
    9 On the Completion page, click Close.
    CA_Intune_CompliancePolicyNote: In Microsoft Intune standalone a similar compliance policy setting is available, in the Device Health section, named Require devices to be reported as healthy.

    End-user experience

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

    Non-compliant Compliant
    CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
    wp_ss_20160319_0001 wp_ss_20160319_0002

    More information

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

    Share

    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:

    Share

    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:

    Share

    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

    Share

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

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

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

    Configuration

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

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

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

    Result

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

    MicrosoftIntune_OMAURI

    Further reading

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

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

    Share