Conditional access and requiring app protection policy

This week is focused on conditional access and the recently introduced grant control of Require app protection policy (preview). I already tweeted about it a couple of weeks a go, but I thought that it would be good to also write a little bit about this grant control. The Require app protection policy (preview) grant control could be seen as the successor of the Require approved client app grant control. The main difference is that the new Require app protection policy (preview) grant control will be more flexible. In this post I’ll start with a short introduction about this new grant control, followed by a configuration example. That example will be about a scenario for accessing Exchange Online. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Require app protection policy (preview) grant control. This grant control is not static and will be flexible as it will simply require that the user received an app protection policy for the app that is used for accessing the respective cloud app. That immediately checks a couple of boxes, as it will require the user to have an Intune license, it will require the user to receive app protection policies and it requires apps to be configured to receive an app protection policy. Besides that, this will also enables organizations to start using third-party apps and line-of-business apps in combination with conditional access. That should be a big advantage compared to the Require approved client app grant control.

There are also a couple of things keep in mind; the Require approved client app grant control only supports iOS and Android and the apps should be using the Intune App SDK. Also, at this moment, this grant control only applies to Microsoft OneDrive and Microsoft Outlook.

Configuration

Let’s continue by having a look at the configuration options, by looking at a simple scenario that is focused on the Require approved client app grant control. That scenario is requiring an app protection policy on any platform, for accessing Exchange Online. Not supported platforms should be blocked. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade;
2 On the Conditional Access – Policies blade, click New policy to open the New blade;
3

RAPP-UsersGroupsOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Done to return to the New tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

4

RAPP-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select Select apps and click Select to open the Select blade. On the Select blade, select the Office 365 Exchange Online cloud app and click Done to return to Cloud apps blade and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is only applicable to Exchange Online.

5

On the New blade, there is no need to select the Conditions assignment;

Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms, locations, client apps and device states. That will also make sure that platforms, which are not supported by this grant control, will be blocked.

6

RAPP-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access, select Require app protection policy (preview) and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will grant access for the assigned users, to the assigned cloud apps, when using an app with app protection policy applied.

7 Open the New blade, select On with Enable policy and click Create;

Note: Keep in mind that the Require app protection policy control is still in preview.

End-user experience

Now let’s end this post by having a look at the end-user experience on an iOS device. Specifically in scenarios when the end-user will be blocked. When the end-user wants to configure their email in the native iOS mail app, the end-user will receive a notification as shown below. It basically explains the end-user that this app is not approved.

IMG_0026

When the end-user wants to configure their email in the Outlook app, but no app protection policy is assigned to the app, the end-user will receive a notifications as shown below. It simply explains the end-user that no app protection policy is applied.

IMG_0027

Note: Keep in mind that this is still a preview feature. In some of my test I would receive the (returning) message in the Outlook app, but I could still send and receive email.

More information

For more information regarding conditional access and requiring app protection policies, please refer to the following articles:

Simple method for adding notifications to scripted installations

This week is focused on the end-user experience. More specifically, the end-user experience for scripted actions. Especially when deploying apps, or performing other scripted actions, by using the PowerShell functionality, there could be actions of interest for the end-user.In that case I would like to notify the end-user. The app deployment functionality already provides the option to display notifications to the end-user and in this post I’ll show a simple, but effective method, to also display notifications to scripted installations. That can be a nice addition to this post about combining the powers of the Intune Management Extension and Chocolatey. In this post I’ll provide an updated script, followed by the required configuration steps. I’ll end this post with the end-user experience.

Script

The first step is to create a PowerShell script that can be used to install Chocolaty packages and to show notifications to the end-user after a successful installation. The following script provides the exact mentioned functionality, nothing more, nothing less, and the script is documented to provide some more details about the exact actions. The script uses the BurntToast module, which is available in the PowerShell Gallery, to display notifications.

Note: The BurntToast module, which is used, will only work for the logged-on user. For functionality in SYSTEM context, additional adjustments are required.

Configuration

The next step is to configure the PowerShell script in Microsoft Intune. The script must run in SYSTEM context to easily install new Windows Features. To upload the script, follow the five steps below. After uploading the script, simply assign the script to the required devices. I deliberately mentioned devices, as I’m using a security group that filters on the version of Windows 10. The good thing is that nowadays these scripts can be assigned to devices and that users are not required to be logged on first.

1 Open the Azure portal and navigate to Intune > Device configuration > PowerShell scripts to open the Device configuration – PowerShell scripts blade;
2 On the Device configuration – PowerShell scripts blade, click Add to open the Script Settings blade;
3a Notification-AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Create;

  • Name: Provide a valid name for the PowerShell script;
  • Description: (Optional) Provide a description for the PowerShell script;
  • Script location: Browse to the created PowerShell script;
  • Settings: See step 3b;

Note: The script must be less than 200 KB.

3b Notification-ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK;

  • Run the script using the logged on credentials: Yes;
  • Enforce script signature check: No;
  • Run script in 64 bit PowerShell: Yes;

Explanation: This configuration will make sure that the script will run by using the user credentials on 32-bit and 64-bit devices.

Note: Keep in mind that the script will be running by using the user credentials, which will require the user to be local administrator for installing the different apps.

End-user experience

Let’s end this post by having a look at the end-user experience. This time I choose to go for an animated gif, as that will provide the best example of the end-user experience. Below is an example of the script installing 7-Zip and Notepad++.

Notification-Experience

More information

For more information about the BurtToast module, please refer to the PowerShell Gallery.

Always apply baseline to co-managed devices

Like the last couple of weeks, this week is also about co-management. This week is all about another nice detail that can be really useful, in specific use cases. That detail is the ability to always apply a configuration baseline to co-managed devices. Even when the Device configuration workload is switched from Configuration Manager to Microsoft Intune. That can be useful for configurations that are not available yet via Microsoft Intune, or for compliance checks that need to be performed and consolidated in one location. In this post I’ll provide a short introduction about the different configuration options, followed by the steps to configure a configuration baseline to co-managed devices when the workload is switched to Microsoft Intune. I’ll end this post with the end-results.

Introduction

When looking at the evaluation of baselines, co-management provides the administrator with 3 different configuration options (of which the third options is the main subject of this post):

  1. Apply Configuration Baselines via Configuration Manager when the Device configuration workload is set to Configuration Manager:
  2. Apply Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune:
  3. Apply Configuration Baselines via Configuration Manager as an exception to Device configuration profiles via Microsoft Intune when the Device configuration workload is set to Microsoft Intune

Configuration

Let’s start by having a look at the configuration. I’ll do that by going through an example that will create a baseline to verify the update compliance of co-managed devices. That will provide an easy method to verify compliance and consolidate the results. Below are 4 steps that walk through the process.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Baselines;
2 On the Home tab, click Create Configuration Baseline to open the Create Configuration Baseline dialog box;
3a

AlwaysApply-Step01On the Create Configuration Baseline dialog box, provide the following information and click OK to create the configuration baseline.

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description; 
  • Configuration data: See step 3b;
  • Select Always apply this baseline even for co-managed clients;

Explanation: The check Always apply this baseline even for co-managed clients in the baseline will make sure that the baseline is always applicable to co-managed devices. Even when the Device configuration workload is set to Microsoft Intune.

3b

AlwaysApply-Step02On the Create Configuration Baseline dialog box, click Add > Software Update to open the Add Software Updates dialog box. On the Add Software Updates dialog box, find the required software update and click OK.

Explanation: This configuration will make sure that this baseline will verify the compliance of all co-managed devices for the latest cumulative update.

4

AlwaysApply-Step03Right-click the just created baseline and click Deploy to open the Deploy Configuration Baselines dialog box. Leave everything default, select the collection for this baseline deployment and click OK.

Explanation: This configuration will make sure that this baseline is deployed to the required collection and will make sure that this baseline is only used for compliance and not for remediation.

Note: The setting Always apply this baseline even for co-managed clients in the baseline, as mentioned in step 3a, can be used to make sure that the baseline is always applied on co-managed devices.

End-results

Now let’s continue by having a look at the results on a co-managed device. Below are two examples of one of a co-managed device. First an overview of the Configuration Manager Properties, followed by a look in the DCMAgent.log file. Both are client-side details, as the server-side will provide status information similar like for any other device.

1 AlwaysApply-ConfigMgrPropertiesThe first example that I would like to show, is the Configurations tab in the Configuration Manager Properties. The Configurations tab shows the deployed baseline, including the last evaluation time and the compliance state. Similar to the evaluation of a baseline when the Device configuration workload is still set to Configuration Manager;
2 The second example that I would like to show, is the DCMAgent.log file. That log file records high-level information about the evaluation, conflict reporting, and remediation of configuration items and applications. Specifically to this post, this log file provides information about the status of the Device configuration workload (first arrow below) and provides information about specifically enabled baselines (second arrow below);
AlwaysApply-DCMAgent

More information

For more information about co-managed devices and configuration baselines, please refer to this article about creating configuration baselines in System Center Configuration Manager.

Switching the Office Click-to-Run apps workload

This week is all about the Office Click-to-Run apps workload. More specifically, this week is all about what’s happening, from a Configuration Manager perspective, when switching the Office Click-to-Run apps workload to Microsoft Intune. Switching the Office Click-to-Run apps workload to Microsoft Intune will make sure that the Office Click-to-Run app will be installed via Microsoft Intune and no longer via Configuration Manager. In this post I’ll show how to switch the Office Click-to-Run apps workload to Microsoft Intune, followed by what is actually making sure that Configuration Manager will no longer install Office Click-to-Run apps. I’ll end this post with a summary.

Configuration

Let’s start with the easy part, in this case, the configuration. Assuming that co-management is already configured, the following 3 steps will walk through the process of switching the Office Click-to-Run apps workload to Microsoft Intune.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Co-management;
2 Select CoMgmtSettingsProd and click Properties in the Home tab, to open the Properties dialog box;
3

O365W-ComanangementPropertiesOn the Properties dialog box, navigate to the Workloads tab. On the Workloads tab, move the slider with Office Click-to-Run apps to Intune.

Note: When there is a need to first test this configuration with a pilot group, simply move the slider with Office Click-to-Run apps to Pilot Intune. In that case make sure to configure a Pilot collection on the Staging tab of the Properties dialog box. 

Note: This configuration change will update the configuration baseline that is used to apply the co-management configuration to Configuration Manager clients. That baseline is shown on Configuration Manager clients as CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot).

Effect of the configuration

Now let’s continue by looking at the effect of this configuration, from a Configuration Manager perspective. I’ll do that by showing the Global Condition that is used, I’ll do that by showing how that Global Condition is used and I’ll do that by showing what happens on the client device.

1 The first thing that I want to look at is the Global Condition that is used. Starting with Configuration Manager, version 1806, the Intune O365 ProPlus management condition is created as a Global Condition in Configuration Manager. That condition is used to make sure that the Configuration Manager client can no longer install the Office Click-to-Run app on co-managed devices, as the condition will be added as a requirement to the app. That is achieved by a VBScript, in the condition, that queries SELECT * FROM DeviceProperty WHERE DeviceIsO365IntuneManaged=TRUE in the root\ccm\cimodels namespace. Based on the results of the query, the VBScript will either return true or false. That return value will be used to evaluate the requirement of the app.
O365W-ConfigMgrConsole
2 O365W-AppRequirementThe second thing that I want to look at is the default configuration of the Office Click-to-Run app that is created when walking through the Microsoft Office 365 Client Installation Wizard. More specifically, the Requirements tab of the created Deployment Type. After a new Office Click-to-Run app is created, the Intune O365 ProPlus management condition is added as requirement to the Deployment Type. The value is configured to False, to make sure that the Office Click-to-Run app is not installed when the Office Click-to-Run apps workload is switched to Intune (or to Pilot Intune).
3 O365W-WbemTestThe third thing that I want to look at is the change on a co-managed device after the Office Click-to-Run apps workload is switched to Intune. Starting with Configuration Manager, version 1806, the Configuration Manager client has a new DeviceProperty named DeviceIsO365IntuneManaged in the root\ccm\cimodels namespace.Based on the configuration of the Office Click-to-Run apps workload, this property is configured to either TRUE or FALSE. That is done during the evaluation of the CoMgmtSettingsProd (and for pilot devices also CoMgmtSettingsPilot) baseline on Configuration Manager clients.

Note: Together these 3 things will make sure that the Configuration Manager client will no longer install any deployed Office Click-to-Run apps when the Office Click-to-Run apps workload is switched.

Summary

Let’s end this post with a summary of what is happening from a Configuration Manager perspective.

  • A relatively new Global Condition, named Intune O365 ProPlus management, is available in Configuration Manager;
  • The Intune O365 ProPlus management condition is used to verify if the co-managed device should use Configuration Manager or Intune for installing the Office Click-to-Run app;
  • The Intune O365 ProPlus management condition is added by default to to Office Click-to-Run apps created through the Microsoft Office 365 Client Installation Wizard;
  • A relatively new DeviceProperty, named DeviceIsO365IntuneManaged, is available in the Configuration Manager client configuration in WMI;
  • The DeviceIsO365IntuneManaged property is used to contain the status of the co-managed device, regarding whether Configuration Manager or Intune should be used to install the Office Click-to-Run app;
  • The DeviceIsO365IntuneManaged property is configured based on the status of the Office Click-to-Run apps workload in the co-management configuration;
  • The Office Click-to-Run app is deployed via Configuration Manager and the Configuration Manager client verifies the status of the DeviceIsO365IntuneManaged property by using the Intune O365 ProPlus management condition.

More information

For more information regarding the Office Click-to-Run apps workload, please refer to this article about Co-management workloads.

Using the power of ConfigMgr together with Microsoft Intune to determine device compliance

This week is all about device compliance. More specifically, about using the combination of ConfigMgr and Microsoft Intune for device compliance. In a cloud-attached scenario, in which ConfigMgr is attached to Microsoft Intune, it’s possible to use the ConfigMgr client in combination with a MDM enrollment. This is also known as co-management. In that scenario it’s possible to slowly move workloads from ConfigMgr to Microsoft Intune, like the compliance policies workload. In that scenario Microsoft Intune will become responsible for the compliance state of the device. However, switching that workload to Microsoft Intune, also limits the available device compliance checks. In case the organization still needs to verify the availability of certain apps, or updates, there’s a solution. Even when the workload is switched to Microsoft Intune. That solution is: Configuration Manager Compliance. In this post I’ll start with an introduction about Configuration Manager Compliance and using that in combination with Microsoft Intune, followed by the configuration in Microsoft Intune. I’ll end this post by showing the end-user experience.

Introduction about Configuration Manager Compliance

Now let’s start with an introduction about Configuration Manager Compliance. Configuration Manager Compliance is a recently introduced configuration option in a device compliance policy in Microsoft Intune. That configuration options enables the administrator to use the device compliance policy in Microsoft Intune together with the device compliance state send from Configuration Manager. That enables the administrator to still use the configuration options from a compliance policy in Configuration Manager, even though the workload is switched to Microsoft Intune. In other words, it enables the administrator to still verify if specific required apps are installed, or that the device has the latest updates installed. End-to-end the following happens for the user/device:

  • Device is managed by Configuration Manager;
  • Device is enrolled with Microsoft Intune;
  • Configuration Manager evaluates the device compliance;
  • Configuration Manager sends the compliance state to Microsoft Intune;
  • Microsoft Intune evaluates the device compliance;
  • Microsoft Intune generates a combined compliance report;
  • Azure AD enforces conditional access;
  • Azure AD allows (or blocks) access for (non)compliant devices;
  • End-user receives a friendly remediation experience via Microsoft Intune and Configuration Manager (see the section about the end-user experience).

Note: This configuration option requires Configuration Manager 1810, or later.

Configuration of Configuration Manager Compliance

Let’s continue by having a look at the configuration. The configuration assumes that a Configuration Manager compliance policy is already available. The following 3 steps walk through the configuration of the Configuration Manager Compliance policy setting in a device compliance policy. Nothing more, nothing less. After creation, the device compliance policy can be assigned like any other device compliance policy. The created device compliance policy is applicable to all targeted users and/or devices. The Configuration Manager Compliance policy setting is only applicable to co-managed devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device compliance > Policies to open the Device compliance – Policies blade;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3a

CMC_CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Settings: See step 3b;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

Note: Configuring non-standard values for Actions for noncompliance and Scope (Tags), is out of scope for this post.

3b

CMC_Windows10CompliancePolicyOn the Windows 10 compliance policy blade, select Configuration Manager Compliance to open the Configuration Manager Compliance blade;

Note: Configuring non-standard values for the Device Health, Device Properties, System Security and Windows Defender ATP, is out of scope for this post.

3c On the Configuration Manager Compliance blade, select Require with Require device compliance from System Center Configuration Manager and click OK to return to the Windows 10 compliance policy blade;
CMC_ConfigurationManagerCompliance
3d Back on the Windows 10 compliance policy blade, click OK;

Note: To take full advantage of this device compliance policy configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Let’s end this post by having a look at the end-user experience. As a starting point for the example below I’ve created a compliance policy that requires all applications (and software updates) with a deadline older than 30 days to be installed. When one (or more) of the required applications is not installed, the end-user will receive a message in Software Center as shown below. It clearly explains the end-user that not all required applications are installed. Mentioning the required applications would be a nice addition.

CMC_Example_SoftwareCenter

Via the Company Portal app the message will be a little less clear. The end-user will simply receive the message that some changes need to be made. A referral to Software Center could be a nice addition.

CMC_Example_CompanyPortal

The administrator can always see the status in the different consoles. Microsoft Intune will show a not compliant message for the Require with Require device compliance from System Center Configuration Manager setting and Configuration Manager will show a not compliant message for the specific rule of the compliance policy.

More information

For more information regarding Configuration Manager Compliance, please refer to the section Configuration Manager Compliance in the  Add a device compliance policy for Windows devices in Intune article.