Quick tip: Available token types for app configuration policies

This is a quick and short blog post to create awareness about the existence of token types. Token types are basically just variables that can be used within a property list of an app configuration policy in Microsoft Intune hybrid and Microsoft Intune standalone. This blog post will provide a quick overview about the available token types with example values.

Overview

The following table contains the currently available token types for Microsoft Intune hybrid and Microsoft Intune standalone. Before going through this table, it’s good to know that the {{ and }} characters are used by token types only and should not be used for other purposes.

Token type Example value
{{userprincipalname}} pvanderwoude@petervanderwoude.nl
{{mail}} pvanderwoude@petervanderwoude.nl
{{partialupn}} pvanderwoude
{{accountid}} fcc00012-123e-f479-aabe-abe2a1123b45
{{deviceid}} c7d01dd3-136f-40c5-b843-711e958c4eef
{{userid}} 2dda638e-28b7-4bdc-a4fd-70faaa811010
{{username}} Peter van der Woude
{{serialnumber}} F9FPVD86FCM5
{{serialnumberlast4digits}} FCM5

More information

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

Prevent specific devices from accessing Microsoft Intune

This week again something completely different. This week I’m going into the world of AD FS. More specifically, I’m going to use AD FS to prevent specific devices from accessing Microsoft Intune (and Office 365). I’ve received that question a few times lately, of which a couple of times on the Microsoft Intune forums, and I thought it would be worth a small blog post.

Using AD FS to deny specific claims is not the prettiest method to prevent users and/or devices from accessing Microsoft Intune (or Office 365). However, it can be very efficient for specific use cases. This blog post will provide an easy method to find the required information to construct the claim rules and a step-by-step direction for configuring the relying party trust. However, keep in mind that it’s only meant to provide a configuration suggestion and to show the many configuration capabilities of AD FS. This suggestion can be easily expanded to create a more specific scenario.

Construct claim rule

Let’s start with finding the required information to create and configure the claim rule. I always like to use an environment in which I can simply deny all the access to the specific relying party. That will make it fairly easy to find the required information for the claim rule. By not permitting access to the relying party, the Event Viewer will generate messages about every request for a token for the relying party. Especially the Event ID 501 messages are interesting. Those messages provide information about the caller identity, which includes the information about the device that’s being used.

The information that I’m looking for is available in the claim http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent. That claim contains the information that I’m looking for. However, keep in mind that it differs per application and per device, which information is provided as part of that claim. I used the Company Portal app, during my search for the required information, and that provided me with the following information about the devices that I used.

Device Value
iPad Mini 2 Mozilla/5.0 (iPad; CPU OS 9_3_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13E238
Nokia Lumia 930 Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/8.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 930) like Gecko

That information can be used during the construction of the required claim rules. In the claim rules I can check for the existence of a specific value that’s provided in the claim. Based on the information, that was provided, I created the following existence rules, in which “(?i)” means that it’s not case sensitive.

Device Value
iPad Mini 2 exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)ipad”])
Nokia Lumia 930 exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)lumia\ 930”])

Configure relying party trust

The existence rule can be used to deny the access to the relying party. The following step-by-step example will create a claim rule that checks if the device enters through the proxy (x-ms-proxy) and that checks for the device type (x-ms-client-user-agent). When both are evaluated  as true, the access will be denied.

  1. Open the AD FS Management console;
  2. Navigate to AD FS > Trust Relationships > Relying Part Trusts;
  3. Right-click the Microsoft Office 365 Identity Platform trust and select
    Edit Claim Rules…;
  4. Navigate to Issuance Authorization Rules and click Add Rule… to open the Add Issuance Authorization Claim Rule Wizard;
  5. On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next.
  6. On the Choose Claim Rule page, specify a Claim rule name, provide the following Claim rule and click Finish.

    exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) &&
    exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)lumia\ 930”])
      => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

  7. Verify that this new claim rule is created below the default Permit Access to All Users claim rule.

This example will prevent the end-user from using a Nokia Lumia 930 for accessing the relying party. Simply perform the same steps and adjust the existence rule to prevent an iPad from accessing the relying party.

End-user experience

Now it’s time to have a look at the end-user experience. This time it’s extra important to realize the impact on the end-user experience, as the end-user will not get a very clear error message. Based on the examples used in this blog post the end-user will have the following experience on an iPad Mini 2 and a Nokia Lumia 930.

iPad Mini 2 Nokia Lumia 930
IMG_0037 wp_ss_20160501_0001

More information

For more information about limiting access to Office 365 and using regex in claim rules, please refer to the following articles:

Use Group Policy to enable Office 365 clients to receive updates via ConfigMgr

Office365_GPOThis week something completely different, compared to the last couple of weeks. This week I want to take a quick look at enabling Office 365 clients to receive updates via ConfigMgr. More specifically, use Group Policy for configuring Office 365 clients to receive updates via ConfigMgr. There is a lot of information available about configuring the Office 365 clients via the initial installation and configuration (configuration.xml), but what about the existing Office 365 clients?

In this post I will provide the required information about using Group Policy to enable the existing Office 365 clients to receive update via ConfigMgr. I will show the Group Policy settings, related to updating the Office 365 clients, and I’ll show how those settings relate to the initial installation and configuration settings. Of course, once I know the registry keys, used by the Group Policy, I can also use Configuration Baselines to do something similar. However, that’s not part of the scope of this post, but I will mention a few Group Policy settings that are ideal candidates for that.

Prerequisites

Let’s start with a few important prerequisites for managing Office 365 client updates with ConfigMgr, mainly related to versions of products. Before enabling the Office 365 client to receive updates via ConfigMgr, make sure the following version requirements are in place:

  • System Center Configuration Manager current branch 1602 or later;
  • Windows Server Update Services (WSUS) 4.0 or later;
  • Office 365 client with version 16.0.6741.2014 or later;
    • This functionality is now available for First Release for Deferred Channel and Current Channel. Deferred Channel is expected in June 2016.

Group Policy settings

Before looking at the available Group Policy settings, make sure to download and install the Office 2016 Administrative Template files from the Microsoft Download Center. Once installed, the Office 365 client update settings can be found at Computer Configuration\Policies\Administrative Templates\Microsoft Office 2016 (Machine)\Updates.

Overview of Group Policy settings

Below is an overview of the Group Policy settings, that can be used to configure the Office 365 client update settings, including how those settings translate to the settings in the installation and configuration files (configuration.xml) and the available values.

Setting Value XML example
Enable Automatic Updates Not Configured | Enabled | Disabled Enabled=”TRUE”
Hide option to enable or disable updates Not Configured | Enabled | Disabled N/A
Hide Update Notifications Not Configured | Enabled | Disabled N/A
Office 365 Client Management Not Configured | Enabled | Disabled OfficeMgmtCOM=”TRUE”
Update Channel

Not Configured | Enabled | Disabled

Channel identifier:
[Specify one of the following Current | Business | Validation | FirstReleaseCurrent]

Branch=”Current”
Update Deadline

Not Configured | Enabled | Disabled

Deadline:
[Specify UTC deadline format MM/DD/YYYY HH:MM]

Deadline=”08/05/2016 20:30”
Update Path

Not Configured | Enabled | Disabled

Location for updates:
[Specify location on the network, local on the device, or on Internet]

UpdatePath=”\\server\share”
Target Version

Not Configured | Enabled | Disabled

Update version:
[Specify version number]

TargetVersion=”16.1.2.3”

Note: The Group Policy settings are written in the registry in the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate.

Configure Office 365 client to use ConfigMgr for updates

The most important Group Policy setting, for enabling the Office 365 client to receive updates via ConfigMgr, is shown in blue italic. That setting, Office 365 Client Management, will make sure that the Office COM object takes commands from ConfigMgr to download and install Office 365 client updates.

Configure end-user experience

There are also a few Group Policy settings that can configure a little bit of the end-user experience. Enabling the Hide option to enable or disable updates setting, makes sure that the end-user can’t disable the update behavior of the Office 365 client and the combination of enabling the Enable Automatic Updates setting and disabling the Hide Update Notifications setting, makes sure that the end-user receives notifications about pending updates for the Office 365 client. That combination is definitely recommended.

Configure update channel

There is also a Group Policy setting that can configure the update channel of the Office 365 client. Enabling the Update Channel setting, enables the channel identifier. That identifier can be used to configure the update channel, by specifying Current, Business, Validation or FirstReleaseCurrent. With configuring the update channel keep in mind that the following information is applicable to the updates delivered to the channels.

Channel GPO/XML Feature updates Security updates Non-security updates
Current Channel Current Monthly Monthly Monthly
First Release for Deferred Channel Validation Every four months Monthly Monthly
Deferred Channel Business Every four months Monthly Every four months

Note: The FirstReleaseCurrent value, is referring to the First Release for Current Channel, which is the Office Insider Program.

Other Group Policy settings

The remaining Group Policy settings, the Update Deadline, the Update Path and the Target Version, are only relevant when ConfigMgr is not used for deploying Office 365 client updates.

More information

For more information about configuring the Microsoft Office 365 client and specifically the update configuration, please refer to:

Microsoft Intune and the AppConfig Community

This week I would like to write about Microsoft Intune and the AppConfig Community. I want to create some awareness about what the AppConfig Community is and I want to show how even Microsoft Intune can, and will, benefit of that great alliance.

What is the AppConfig Community?

Let’s start with what the AppConfig Community actually is. I could do that by providing my own explanation about the AppConfig Community, but to prevent any possible misinterpretation from my side, I will provide the good and clear explanation as provided on the AppConfig Community website.

The AppConfig Community is a collection of industry leading Enterprise Mobility Management (EMM) solution providers and app developers that have come together to make it easier for developers and customers to drive mobility in business. The community’s mission is to streamline the adoption and deployment of mobile enterprise applications by providing a standard approach to app configuration and management, building upon the extensive app security and configuration frameworks available in the OS. Working together, the members of the AppConfig Community are making it simpler for developers to implement a consistent set of controls so that enterprise IT administrators can easily configure and manage apps according to their business policies and requirements.

Historically, developers used proprietary software development kits (SDKs) to enable configuration and management features of their apps through EMM. This required app developers to build different versions of their apps for each EMM vendor. Now, with the AppConfig Community tools and best practices, developers do not require EMM-specific integrations for many enterprise use cases. End users also benefit from automated features such as an out-of-the-box experience to give the users instant app access without requiring cumbersome setup flows or user credentials.

Microsoft Intune and the AppConfig Community

Let’s continue with how Microsoft Intune works with the AppConfig Community. Well, it’s good to know that, at this moment, Microsoft Intune is not part of the collection of industry leading EMM solution providers that started the AppConfig Community. However, that doesn’t mean that the apps, created with the AppConfig Community standards, won’t work with Microsoft Intune. The XML format used by the AppConfig Community is similar to the XML format used by Microsoft and the Microsoft Intune app partners. In other words, the apps created by the partners, of the AppConfig Community, should also work with Microsoft Intune.

Microsoft Intune example

Now I want to show how Microsoft Intune works with an app, of a partner, of the AppConfig Community, to proof my previous statement. As an example app I use the amazing Nacho Mail app. Not only is it a great email app, it also has a great support team and some awesome configuration options. The support team is more than willing to help with providing the required information to apply app configurations to the Nacho Mail app.

Configuration

As I’m currently looking at multiple mail apps, with one of my customers, I’m also looking at the Nacho Mail app. One of the big pros, of the Nacho Mail app, is the fact that it allows the configuration of the app. It has the ability to configure a mail profile and it even has the ability to apply custom branding to the app. After contacting the support team, of the Nacho Mail app, they provided me with the following configuration key-value-pairs.

Type Key Description
String AppServiceHost Name of server
Integer AppServicePort Port number
String UserName User name
String UserDomain Domain name
String UserEmail User email address
String BrandingName Name of app to be displayed
String BrandingLogo Link to image to be displayed with app

I could use those key-value-pairs to create a mail profile for Office365, including custom branding. It’s not required to specify AppServiceHost with outlook.office365.com, as the Nacho Mail app is intelligent enough to figure it out based on the provided mail address. However, I noticed that it would save me a certificate warning. Below is the configuration that I’ve created and to use this configuration, please refer to my post about App Configuration Policies for iOS.

<dict>
   <key>AppServiceHost</key>
   <string>outlook.office365.com</string>
   <key>BrandingName</key>
   <string>petervanderwoude.nl</string>
   <key>BrandingLogo</key>
   <string>[Specify URL to logo]</string>
   <key>UserEmail</key>
   <string>{{userprincipalname}}</string>
</dict>

Note: I used the {{userprincipalname}} token type that is supported by Microsoft Intune to provide the user principal name of the end-user. However, at this moment Microsoft Intune hybrid seems to be having problems with the supported token types. Microsoft Intune standalone works like a charm.

End-user experience

After creating the app configuration, it’s time to look at the end-user experience. This time I will show the first two screens of the Nacho Mail app, after installation. That will provide a clear picture about how app configuration policies can be helpful for an end-user. The screenshots on the left show the default start of the Nacho Mail app and the screenshots on the right show the start of the Nacho Mail app after deploying the app together with the app configuration policy.

On the second screenshot, on the right, it clearly shows the complete configuration of the mail profile and my custom branding. I love it!

Before After
IMG_0034 IMG_0030
IMG_0035 IMG_0033

More information

For more information about the AppConfig Community and mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

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.