App Configuration Policies for iOS apps

This week another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. And again, it’s about a feature that already did exist in Microsoft Intune standalone. This post will be about the App Configuration Policies for iOS apps. These policies can make the life of an end-user a lot easier and are a very welcome addition to Microsoft Intune standalone and Microsoft Intune hybrid.

For now the biggest challenge might be finding the apps that support App Configuration Policies and, maybe even more important, apps that have the settings documented. During the deployment of an app via ConfigMgr, or Microsoft Intune, it’s already visible if  an app could support App Configuration Policies. However, a lot of apps have the potential, but not yet the complete implementation.

Introduction

App Configuration Policies in Microsoft Intune hybrid and Microsoft Intune standalone, can be used to supply settings that might be required when the end-user runs an app. Settings that the end-user would have to specify manually. Think about settings like, a server name, a custom port number, a user name, a password, specific language settings and specific security settings.

If these settings are incorrectly entered by the end-user, this can increase the burden on the service desk, and can also slow the adoption of new apps. App Configuration Policies can help with eliminating these problems by letting the organization deploy these settings to the end-users in a policy before they run the app. The settings are then supplied automatically, and the end-user doesn’t have to perform an action.

These App Configuration Policies are not deployed directly to users and devices. Instead, they are associated with a deployment type during the deployment of the application. The policy settings will be used whenever the app checks for them (typically, the first time it is run).

Configuration

App Configuration Policies are configured per app, because every app supports different settings. In the following configuration examples I’m using the Acronis Access app as an example. During the configuration I will use one specific configuration setting, named enrollmentServerName. For all other supported Acronis Access app configuration settings, please refer to: https://www.acronis.com/en-us/support/documentation/AcronisAccessAdvanced_7.0/index.html#28935.html

Microsoft Intune standalone

The configuration of App Configuration Policies in Microsoft Intune standalone can be achieved by performing the following steps. After the configuration of the App Configuration Policy, it can be used during the deployment of the Acronis Access app.

1 In the Microsoft Intune administration console, navigate to POLICY and click Add..;
2 In the Create a New Policy dialog box, select iOS > Mobile App Configuration Policy and click Create Policy  to open the Create Policy page;
3

On the General section of the Create Policy page, specify the following information.

  • MI_AppConfig_GenName: [Specify a unique name for the app configuration policy];
  • Description: [Specify details that help identifying the app configuration policy].
4

In the Mobile App Configuration Policy section of the Create Policy page, specify the following information and click Verify;

MI_AppConfig_Rule<dict>
   <key>enrollmentServerName</key>
   <string>[Specify an enrollment server name]</string>
</dict>

5 After verifying the created configuration, click Save Policy.

Microsoft Intune hybrid

The configuration of App Configuration Policies in Microsoft Intune standalone can be achieved by performing the following steps. After the configuration of the App Configuration Policy, it can be used during the deployment of the Acronis Access app.

1 In the Configuration Manager administration console, navigate to Software Library > Overview > Application Management > App Configuration Policies;
2 On the Home tab, click Create new Application Configuration Policy to open the Create App Configuration Policy Wizard;
3

CM_AppConfig_GenOn the General page, provide the following information and click Next.

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

CM_AppConfig_PolOn the iOS Policy page, select Specify name and value pairs (for simple property list files without nesting) and click New to open the Edit Name/Value Pair dialog box.

Note: Select Browse to a property list file (for more complex property list files with nesting) for adding more advanced configurations, or for adding the configuration in an XML format (like with the Microsoft Intune standalone configuration).

5

CM_AppConfig_RuleIn the Edit Name/Value Pair dialog box, provide the following information and click Ok to return to the iOS Policy page.

  • Type: String;
  • Name: enrollmentServerName;
  • Value: [Specify an enrollment server name].
6 CM_AppConfig_ConfBack on the iOS Policy page, verify the created configuration and click Next.
7 On the Summary page, click Next.
8 On the Completion page, click Close.

End-user experience

Now it’s time to look at the end-user experience. This time I will show the first start of the Acronis Access app after installation. The first screenshots shows the default start of the Acronis Access app and the second screenshot shows the start of the Acronis Access app after deploying the app together with the App Configuration Policy. As I don’t really have a server to connect to, it stops at the connection screen in which it did configure my custom server URL.

Before After
IMG_0018 IMG_0017

More information

For more information about iOS with mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

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

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

In this blog post I will provide nice tables of the different compliance rules, for Windows 10 devices, that are currently available for Microsoft Intune standalone and Microsoft Intune hybrid. In those tables I’ll show the different management scenarios and the currently available applicable compliance rules.

Overview

Before I’ll start with the overview, it’s good to provide a short explanation about the distinction between the conditional access policy and the compliance policy.

The conditional access policy is a required configuration to enable conditional access on a particular service and to help secure access to that particular service. In the conditional access policy, the targeted platforms and the targeted users of devices are configured. Also, important for Windows 10 devices, in the conditional access policy it is possible to determine if Windows 10 devices must be compliant or domain joined.

The compliance policies, on the other hand, are optional additional rules that can evaluate settings like PIN and encryption. The devices of targeted users must be compliant to those additional rules. When there are no compliance policies deployed, the device will automatically be evaluated as compliant.

Microsoft Intune standalone

Now let’s start with the overview of available compliance rules in Microsoft Intune standalone. In Microsoft Intune standalone, a Windows 10 device can be managed by the Microsoft Intune client and it can be enrolled as a mobile device. Those two options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

Intune client MDM
Allow simple passwords N/A Yes (Mobile only)
Maximum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Maximum Windows version N/A Yes (Desktop only)
Minutes of inactivity before password is required N/A Yes
Minimum password length N/A Yes
Minimum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Minimum Windows version N/A Yes (Desktop only)
Require a password to unlock an idle device N/A Yes (Mobile only)
Password expiration N/A Yes
Remember password history – Prevent reuse of previous passwords N/A Yes
Required password type – Minimum number of character sets N/A Yes
Require a password to unlock mobile devices N/A Yes (Mobile only)
Require devices to be reported as healthy N/A Yes
Require encryption on mobile device N/A Yes

Microsoft Intune hybrid

Let’s continue with the overview of available compliance rules in Microsoft Intune hybrid. In Microsoft Intune hybrid, a Windows 10 device can be managed by the Microsoft Intune client, the ConfigMgr client and it can be enrolled as a mobile device. Those three options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined  the only additional configuration for those devices.

Intune client ConfigMgr client MDM
All required updates installed with a deadline older than X days N/A Yes N/A
Allow simple passwords N/A N/A Yes (Mobile only)
File encryption on mobile device N/A N/A Yes
Maximum operating system version N/a N/A Yes
Minimum classification of required updates N/A N/A Yes
Minimum operating system version N/A N/A Yes
Minimum password length N/A N/A Yes
Minutes of inactivity before password is required N/A N/A Yes
Require a password to unlock an idle device N/A N/A Yes (Mobile only)
Reported as healthy by Health Attestation Service N/A N/A Yes
Require Antimalware N/A Yes N/A
Require BitLocker drive encryption N/A Yes N/A
Require password settings on mobile devices N/A N/A Yes
Require registration in Azure Active Directory N/A Yes N/A

More information

For information about about conditional for Windows 10 devices with Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

Conditional access and health attestation

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

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

Introduction

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

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

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

Pre-configuration

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

Default client settings

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

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

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

Health attestation dashboard

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

CA_Intune_HealthAttestation

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

Configuration

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

Conditional access policy

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

Exchange Online Policy SharePoint Online Policy
CA_ExchOnl_Win10 CA_SPOnl_Win10

Compliance policy

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

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

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

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

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

4

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

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

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

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

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

7

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

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

End-user experience

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

Non-compliant Compliant
CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
wp_ss_20160319_0001 wp_ss_20160319_0002

More information

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

Conditional access for PCs managed by ConfigMgr

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week a blog post about the Conditional access for managed PCs feature that is introduced in ConfigMgr 1602. This feature is introduced as a pre-release feature. The requirements for using Conditional access for managed PCs are similar to the requirements of the blog series that I did a few months ago about Conditional access for PCs. Make sure that those requirements are in-place before starting with the configurations described in this post.

Introduction

Conditional access for managed PCs is basically an additional level of restricting access to Exchange Online and SharePoint Online. Before the only level of restricting access was that device had to be enrolled via Microsoft Intune, or that the device had to be domain joined. Now it’s also possible to create additional compliance policies for managed PCs. Managed PCs by ConfigMgr. Those compliance policies can contain the following rules:

  • Require registration in Azure Active Directory: This rule checks if the end-user device is workplace joined to Azure AD. If not, the device is automatically registered in Azure AD. Automatic registration is currently only supported on Windows 8.1.
  • All required updates installed with a deadline older than a certain number of days: This rule checks to see if the end-user device has all required updates within the configured deadline and grace period. If not, any pending required updates are automatically installed.
  • Require BitLocker drive encryption: This is a check to see if the primary drive on the device is BitLocker encrypted. If not, access to Exchange Online and SharePoint Online is blocked.
  • Require Antimalware: This is a check to see if the antimalware software is enabled and running. If not, access to Exchange Online and SharePoint Online is blocked. At this moment only supported for System Center Endpoint Protection and Windows Defender.

Configuration

Now lets have a look at the configuration. I will briefly mention the conditional access policy, because I’ve written a lot about those in my previous blog series about Conditional access for PCs. After that I’ll go through all the required steps for creating the compliance policy and I’ll end this configuration section with the effect on the client.

Pre-release feature

As Conditional access for managed PCs is a pre-release feature, it must be specifically turned on. This can be achieved by simply performing the following 2 steps.

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

Conditional access policy

The reason why I do have to mention the conditional access policy, is one specific configuration setting. That specific setting is that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. This is very important, as any other configuration would make a domain join enough to be compliant, while in this configuration I want to create an additional compliance policy. That setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy SharePoint Online Policy
CA_ConfigMgr_ExchangeOnline CA_ConfigMgr_SharePointOnline

Compliance policy

More interesting is the new compliance policy. Within the compliance policy it’s now possible to create a compliance policy specifically for devices managed with the ConfigMgr client. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

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

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

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

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

  • CA_ConfigMgr_CP_PlatformAll Windows 7 (64-bit)
  • All Windows 7 (32-bit)
  • All Windows 8.1 (64-bit)
  • All Windows 8.1 (32-bit)
  • All Windows 10 (64-bit)
  • All Windows 10 (32-bit)
5 On the Rules page, click New… to open the Add Rule dialog box;
6

In the Add Rule dialog box, select the following rules one-by-one and click OK to return to the Rules page;

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

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

Note: As this screenshot shows, none of the rules require additional configuration except for the software updates rules. That rule requires the selection of the number of days that a deadline has been passed.

8 On the Summary page, click Next
9 On the Completion page, click Close.

Policy effect

A good place to look at the effect of the compliance policy, is to look at the reports. More specifically, the reports Compliance Access Compliance for Users and Compliance Access Compliance Report. However, I still like to think that the log files are the best place to look at the effect of the compliance policy. More specifically, the DcmWmiProvider.log. That log file provides detailed information about the compliance checks that are performed. Below is a log snippet about a successful compliance check.

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

This log snippet provides clear information about the 4 rules, of the compliance policy, that are being checked. It clearly shows the software update check, the BitLocker encryption check, the workplace join check and the antimalware check. The log snippet even provides some details about how those checks are performed. For example, it shows that my test device was a virtual machine and that, because of that, the encryption check was skipped and that the compliance, for that check, was automatically set to true.

End-user experience

Now it’s time to look at the end-user experience. At this moment the end-user experience is as shown below. When a non-compliant managed PC tries to access Exchange Online, or SharePoint Online, it will get a message as shown below. A compliant managed PC will be able to simply access Exchange Online and SharePoint Online. To get the detailed information about the compliance of the managed PC, the end-user can use the Device compliance section in Software Center, as shown below.

Non compliant Compliant
CA_ConfigMgr Not applicable. A compliant managed PC will automatically have access. Meaning there is no special screen that the en-user will get.
CA_SoftwareCenter_01 CA_SoftwareCenter_02

More information

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

Quick tip: Working with the device enrollment manager and automatic enrollment

This is another short and quick blog post. This time about the device enrollment manager in combination with the automatic enrollment in Microsoft Intune, which is powered by Azure AD. The device enrollment manager is a configuration within Microsoft Intune standalone, or Microsoft Intune hybrid (starting with ConfigMgr 1511). However, with really active use of the device enrollment manager, it is possible to run into some default configuration challenges. This post will provide a quick tip about those challenges.

Configuration

The documentation about the device enrollment manager contains a note that device enrollment manager user accounts, with more than 20 devices enrolled, might have problems using the Company Portal app. In case that potential problem is not an issue, for the usage within the company, it’s good to know that those 20 devices are not a hard limit to the maximum number of enrolled devices.

However, in case more than 20 devices must be enrolled, in combination with automatic device enrollment of Azure AD, make sure to adjust the following configuration. Without this adjustment problems will occur with the Azure AD join, simply because the default maximum number of devices is set to 20 per user.

  • MaxDevicesIn the Microsoft Azure
    portal, navigate to ACTIVE DIRECTORY >
    [Directory];
  • Select the CONFIGURE tab and scroll down to the devices section;
  • Adjust the number with MAXIMUM NUMBER OF DEVICES PER
    USER
    .

More information

For more information about the device enrollment manager, in Microsoft Intune standalone and hybrid, and automatic enrollment, please refer to:

When are devices blocked after enabling conditional access?

This week a blog post with only one purpose, and that purpose is, providing an overview. Providing an overview about when devices will be blocked after enabling conditional access. That information is available in the TechNet documentation (see the More information section of this post), but it might be a bit difficult to find. As the question pops up in the TechNet forums at a regular basis, I got the suggestion that it would be a good idea to provide a quick, but clear, overview.

This post will provide nice tables, for Microsoft Intune standalone and Microsoft Intune hybrid, with the time it will take before a device will be blocked from Exchange. That information will be provided for two different setups and three different scenarios. A quick spoiler, the tables for Microsoft Intune standalone and Microsoft Intune hybrid are identical.

Overview

Let’s have a look at the mentioned overview tables for Microsoft Intune standalone and Microsoft Intune hybrid. However, before looking at the overview tables, it’s important to understand the following details about the scenarios.

  • After user setting up email profile – This scenario is applicable when the end-user wants to configure email on a device that is not enrolled;
  • After user enrolling blocked device – This scenario is applicable when the end-user wants to get email on a device that’s just enrolled, or just remediated;
  • After user un-enrolling device – This scenario is applicable when the end-user has un-enrolled its device.

Microsoft Intune standalone

Below is the overview table for Microsoft Intune standalone.

After user setting up email profile After user enrolling blocked device After user un-enrolling device
Exchange Online Device is blocked immediately Device is unblocked within 2 minutes Device is blocked after around 6 hours
Exchange on-premises Device is blocked after around 1-3 hours Device is unblocked within 2 minutes Device is blocked after around 1-3 hours

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

Microsoft Intune hybrid

Below is the overview table for Microsoft Intune hybrid.

After user setting up email profile After user enrolling blocked device After user un-enrolling device
Exchange Online Device is blocked immediately Device is unblocked within 2 minutes Device is blocked after around 6 hours
Exchange on-premises Device is blocked after around 1-3 hours Device is unblocked within 2 minutes Device is blocked after around 1-3 hours

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

More information

For more information about managing email access via Microsoft Intune standalone or Microsoft Intune hybrid, 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:

Certificate profile deployment failed with the error ‘22004: Unsupported certificate configuration’

Tweet_NDESThis week a short blog post about an issue that I ran into, and tweeted about, the other week. Due to the strange error message I thought it would definitely be blog worthy. The error description was 22004: Unsupported certificate configuration. However, the actual issue did not come close to what the description would imply. This post will provide a brief overview of the scenario, the issue and the solution.

Scenario

Env_OverviewLet’s start with a brief overview of the scenario. The environment contains Active Directory Federation Services (AD FS) and Web Application Proxy (WAP) for providing single sign-on (SSO) to the cloud services of Office 365 and Microsoft Intune. Microsoft Intune is used in a hybrid configuration with ConfigMgr and is fully configured to deploy certificate profiles. The required Network Device Enrollment Service (NDES) is published through WAP.

Issue

Now let’s have a look at the issue that I started seeing with deploying Certificate Profiles via Microsoft Intune hybrid to mobile devices. It is good to mention that it was working before. I started seeing the following combination of error messages on specific Certificate Profile settings.

Name Type Error Category Error ID Description
Certificate already issued Setting Discovery 0x87D17D04 22004: Unsupported certificate configuration
Certificate configuration parameters Setting Enforcement 0x87D1FDE8 Remediation failed

The first error message seems very straight forward. At least, assuming that it is accurate. However, as the Certificate Profile deployment was working before, I couldn’t imagine that the issue was related to the configuration of the certificate, certificate profile or certificate template.

I had to look further. The first thing I did was checking the external availability of NDES. I did that by checking the external URL of NDES, via https://externalFQDN/certsrv/mscep/mscep.dll. That external URL gave me an HTTP Error 503. The service is unavailable error message. The logical second thing I did was checking the internal availability of NDES. I did that by checking the internal URL of NDES, on the WAP server, via https://internalFQDN/certsrv/mscep/mscep.dll. That internal URL gave me an expected 403 – Forbidden: Access is denied error message.

Now the issue is narrowed down to the publishing mechanism used for NDES.

Solution

In this case it turned out to be the Web Application Proxy Service service that was in a Stopped state. Simply starting the service again solved the issue. After looking a bit further, I noticed that the service initially failed to start due to connection issues with the AD FS server. By default, the service tries to restart twice. After the third failure the service won’t retry again. However, in this case the connection came back to life after the third failure of the service.

In case the HTTP Error 503. The service is unavailable error message also shows while checking the internal URL of NDES, the problem is likely related to NDES itself. In that case the issue is likely related to the application pool, named SCEP, used by NDES.

A good summary would be that the 22004: Unsupported certificate configuration error message is often related to any HTTP Error 503. The service is unavailable error message in the NDES publishing chain.

Custom Terms and Conditions

This week I’m back in ConfigMgr and I’m back with custom Terms and Conditions. A few months ago I did my latest post about custom Terms and Conditions. That post was completely focused on Microsoft Intune standalone. Starting with ConfigMgr 1511 it’s now also possible to deploy custom Terms and Conditions through Microsoft Intune hybrid.

Custom Terms and Conditions can be deployed to end-users to explain how device enrollment, access to work resources, and using the Company Portal affects them and their devices. End-users must accept the custom Terms and Conditions before they can use the Company Portal to enroll and access their company data.

In this post I’ll show how to create, deploy, update and monitor custom Terms and Conditions in Microsoft Intune hybrid. I’ll also briefly show the end-users experience. Keep in mind that custom Terms and Conditions are deployed to users and that users only need to accept the Terms and Conditions once, unless specifically configured in an updated version of the custom Terms and Conditions.

Configuration

Now let’s start with the configuration of custom Terms and Conditions. I’ll first go through the configuration steps to create custom Terms and Conditions, followed by the configuration steps to deploy custom Terms and Conditions and I’ll finish with the configuration steps to update the custom Terms and Conditions.

Create Terms and Conditions

The first configuration activity is creating the custom Terms and Conditions. This configuration activity can be performed by simply going through the following six steps.

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

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

  • CustomTandC._GenName: [Specify a unique name for the custom Terms and Conditions]
  • Description: [Specify details that help identifying the custom Terms and Conditions]
4

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

  • CustomTandCTitle: [Specify the title that will be displayed to the end-users in the Company Portal]
  • Text for terms: [Specify the custom Terms and Conditions that will be displayed to the end-users in the Company Portal]
  • Text to explain what it means if the user accepts: [Specify a short explanation that will be displayed to the end-users in the Company Portal]
5 On the Summary page, click Next;
6 On the Completion page, click Close.

Deploy Terms and Conditions

The second configuration activity is deploying the custom Terms and Conditions to an user collection. This configuration activity can be performed by simply going through the following three steps.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Terms and Conditions;
2 Select the new custom Terms and Conditions and in the Home tab click Deploy to open the Deploy Terms and Conditions dialog box;
3

In the Deploy Terms and Conditions dialog box, specify the following information and click OK;

  • CustomTandC_DeplName: [Grayed out]
  • Collection: [Select to the collection containing the required users]

Update Terms and Conditions

The last configuration activity is updating the custom Terms and Conditions. This is an optional activity that is only required when an update to an existing custom Terms and Conditions is required. This configuration activity can be performed by simply going through the following three steps.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Terms and Conditions;
2 Select the new custom Terms and Conditions and in the Home tab click Properties to open the Terms and Conditions Properties dialog box;
3

In the General tab and Terms tab, make the required updates, choose between the following options on the Terms tab and click OK;

  • CustomTandC_EditIncrease the version number, and require all users to accept the updated terms the next time they open the Company Portal: [Select this option when significant changes are made to the custom Terms and Conditions];
  • Keep the current version number, and require only new users to accept the updated terms: [Select this option when typos, or formats are fixed in the custom Terms and Conditions].

End-user experience

Before I’ll go to the reporting capabilities, for the custom Terms and Conditions, I think it’s important to first show the end-user experience. Depending on the number of targeted custom Terms and Conditions, the end-users can experience the behavior as shown below.

Single custom Terms and Conditions Multiple custom Terms and Conditions
IMG_0013 IMG_0014

Reporting

Let’s finish this post with the reporting abilities of custom Terms and Conditions. Out-of-the-box there is one report available, named Terms and Conditions acceptance, that shows which user accepted which version of which custom Terms and Conditions. That report is available in the category Compliance and Settings Management and only shows the information about end-users that accepted the custom Terms and Conditions.

Filters Report

This report can use the following filters:

  • Terms and Conditions: [Select a specific Terms and Conditions to display];
  • User filter: [No function];
  • User Name: [Select a specific user to display].
CustomTandC_Report

More information

For more information about creating, deploying, updating and monitoring custom Terms and Conditions, please refer to: