Conditional access and persistent browser sessions

Like last week, this week is also about conditional access. This week is about the recently introduced session control of Persistent browser session (preview). It was already possible to configure the persistence of browser sessions by using the company branding configuration, but this new session control provides the administrator with a lot more granularity. In this post I’ll start with a short introduction about this new session control and the behavior that the session control controls. After that I’ll show the configuration steps, followed by the administrator experience. 

Introduction

IMG_0029 1Now let’s start with a short introduction about the Persistent browser session (preview) session control. A persistent browser session allows the end-user to remain signed in after closing and reopening their browser window. The default configuration for browser session persistence, allows the end-user on a personal device to choose whether to persist the session by showing a “Stay signed in?” prompt after successful authentication.

The “Stay signed in?” prompt can be controlled on tenant-level, by editing the company branding, or by using the Persistent browser session (preview) session control. The session control provides a lot more flexibility, as it enables the administrator to differentiate on persistent browser sessions, based on the location, the sign-in risk, the location, the client app and the device state conditions that are applicable to the sign-in of the end-user. That and of course based on the end-user itself.

Configuration

Let’s continue by having a look at the configuration options. Let’s do that by looking at a simple scenario that is focused on the Persistent browser session access control. That scenario is to never have persisting browser sessions on any platform, for accessing any cloud app, on personal devices. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or navigate 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

KMSI-UserGroupsOn 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

KMSI-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 All cloud apps and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all cloud apps. This is also a required condition for the Persistent browser session (Preview) session control.

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 only personal devices are affected, as the “Stay signed in?” prompt is only shown on personal devices.

6

KMSI-SessionControlOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Persistent browser session (preview), select Never persistent and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will never persist browser sessions for the assigned users, to the assigned cloud apps.

Note: This Persistent browser session (preview) session control, will overwrite the “Stay signed in?” configuration in the company branding pane.

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

Note: Keep in mind that the Persistent browser session control is still in preview.

Administrator experience

Now let’s end this post by having a look at the administrator experience. I’m deliberately not showing the end-user experience, as the configuration of this post will suppress the “Stay signed in?” prompt that was shown at the beginning of this post. A successful configuration would mean that the end-user no longer receives the “Stay signed in?” prompt. From an administrator perspective, this can be simply verified by looking at the Sign-ins report that is available in Azure Active Directory. That report will show the conditional access result for the applied conditional access policies and their session controls.

KMSI-SignIn

More information

For more information regarding conditional access and persistent browser sessions, please refer to the following article

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.

The different ways of enrolling devices in Windows Analytics

After a week of silence, due to the MVP Summit, this week another new blog post. This week is all about enrolling devices in to Windows Analytics. An updated version, with a slightly different angle, of a post of about two years ago. This time I’ll summarize the different methods to achieve the same goal and the changes since Windows 10, version 1803. I’ll start this post with an overview of the required settings, followed by an overview of the different configuration methods. I’ll end this post by going through my preferred method, for a cloud scenario, and the administrator experience.

Settings to configure

Now let’s start by looking at the settings that are required to enroll devices in to Windows Analytics. Those settings are the commercial ID, the telemetry level (and with that enabling Windows telemetry) and allowing the device name in the telemetry data (since Windows 10, version 1803). The following table describes the settings that are required, including a description, and starting point for my preferred method, for a cloud scenario, of configuring these settings.

Policy Description

AllowTelemetry

Values: 0 (Security), 1 (Basic), 2 (Enhanced), or 3 (Full)

This setting should be used to enable Windows telemetry. Windows Analytics requires a minimum Windows telemetry level of enhanced (optional together with the policy LimitEnhancedDiagnosticDataWindowsAnalytics to limit the telemetry data to the minimal required).

AllowDeviceNameInDiagnosticData

Values: 0 (Disabled) or 1 (Enabled)

This setting should be used to allow the device name in the Windows telemetry that is sent to Windows Analytics. That will enable that the different solutions within Windows Analytics can actually be used for really tracking update compliance.

CommercialID

Values: [YourCommercialID]

This setting should be used to specify the workspace id that should be used for Windows Analytics. The commercial ID can be found in the Settings of the different Windows Analytics solutions.

Note: The first two policies are available in the node ./Vendor/MSFT/Policy/Config/System and the third policy is available in the node ./Vendor/MSFT/DMClient/Provider/MS DM Server.

Configuration options

Let’s continue with looking at the different configuration methods. Every configuration option has pros and cons, which can differ per scenario.

1 WA-ConfigMgrWhen using Configuration Manager, the Configuration Manager client can be used to enroll a device in to Windows Analytics. This can be achieved by using the Windows Analytics section in the Client Settings. This configuration method can configure the commercial ID and the telemetry level. This can be a useful method in an on-premises, or a co-management scenario. Only allowing the device name in the telemetry data would require an additional configuration method.
2 WA-GPOWhen using Group Policy, Administrative Templates can be used to enroll a device in to Windows Analytics. This can be achieved by using the Data Collection and Preview Builds section in the Windows Components section of the Administrative Templates. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in any on-premises, or cloud scenario (by using a third-party tool like PolicyPak: MDM Edition). Only reporting on a setting-level will be limited in a cloud scenario.
3 When using Configuration Manager or Microsoft Intune, PowerShell scripts can be used to enroll a device in to Windows Analytics. This can be achieved by using the New-Item and the New-ItemProperty cmdlets to directly create the required registry keys. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in any on-premises, or cloud scenario. Only reporting on a setting-level will be limited.
4 WA-MDMWhen using Microsoft Intune, Windows 10 MDM can be used to enroll a device into Windows Analytics. This can be achieved by using custom OMA-URI settings. This configuration method can configure the commercial ID, the telemetry level and the device name. This can be useful in a co-management, or cloud scenario.

Preferred configuration option

Let’s continue by looking at my preferred configuration option, at least in a cloud scenario. Besides using Group Policy, this is the most reliable and complete option for configuring the required settings. It allows setting-level configuration and reporting. The following 3 steps walk through the required actions.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Devices configuration – Profiles blade;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

WA-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b;

Explanation: This configuration will make sure that a custom profile is created that can be used to add the required Windows Analytics settings.

3b

WA-AddRowOn the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: Specify a the required policy setting;
  • Data type: Select Integer;
  • Value: Specify the required value;

Note: Simply repeat this step for every policy setting that should be configured.

WA-MDM

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

Administrator experience

Let’s end this post by looking at the administrator experience. Of course I can simply show the configurations on the device, but I thought that showing a device including the device name in a solution would show the complete picture. It proofs that Windows telemetry is enabled, that it’s sending data to the correct workspace and that it’s sending the device name (even for devices with Windows 10, version 1803 and newer). See below for that example.

WA-Result

More information

For more information about Windows Analytics and Microsoft Intune, please refer to the following articles:

The conditional access policy flow

This week is still all about conditional access. However, this week it’s not about a specific configuration. This week it’s about the conditional access policy flow. The flow that will help with determining if a conditional access policy is applicable to the user’s attempt to access a cloud app and if access will be allowed or blocked. The idea is similar to the What if tool. The big difference is that the What if tool does a technical check to see which conditional access policy is applicable and this flow can help with determining why a conditional access policy is applicable, or not. Also, almost as important, this flow will clearly show how many options are available to exclude specific users and devices. This is important to know, because if no conditional access policy is applicable, the user’s attempt to access a cloud app (which means company resources) will be allowed. The flow is shown below.

TheConditionalAccessFlow

Note: The sign-in risk condition is left out of this flow, as it requires Azure AD Identity Protection. The idea for that condition would be similar to the other conditions. Also, the session controls are left out of this flow. The idea for that control should be similar to other controls, except that this control will not directly block access as it will only provide a limited experience.

The main idea of this flow is to make it very clear that there can be many reasons for a conditional access policy to not be applicable (see all the yellow ovals in the flow above). The flow goes through the following conditions and controls:

  • Conditions (can be used to filter):
    • Users and groups: Required condition, which is captured in this flow with “Is the policy assigned to the user?”. This should be the result of the included and excluded user groups;
    • Cloud apps: Required condition, which is captured in this flow with “Is the policy assigned to the cloud app?”. This should be the result of the included and excluded cloud apps;
    • Sign-in risk: Condition not part of this flow (see note);
    • Device platforms: Optional condition (“Is the device platform condition enabled?”), which is captured in this flow with “Does the policy include the device platform?”. This should be the result of the included and excluded device platforms;
    • Locations: Optional condition (“Is the device locations condition enabled?”), which is captured in this flow with “Does the policy include the location?”. This should be the result of the included and excluded locations;
    • Client apps: Optional condition (“Is the client app condition enabled?”), which is captured in this flow with “Does the policy include the client app?”. This should be the result of the included and excluded client apps;
    • Device state: Optional condition (“Is the device state condition enabled?”), which is captured in this flow with “Does the policy include the device state?”. This should be the result of the included and excluded device states;
  • Controls (can be used to set an action)
    • Grant: Optional control that can be used to block or grant access, which is captured in this flow with “Does the policy grant access?”, and when used to grant access it must set requirements, which is captured in this flow with “Does the device and/or app meet the requirements?”.
    • Session: Control not part of this flow;

The main message of this flow is awareness. Be aware of which users and devices are excluded from the conditional access policy. Those users and devices should be assigned to separate conditional access policies, to make sure that the conditional access configuration creates a secure environment without any (unknown) backdoors.

More information

For more information about conditional access, please refer to the docs that are available here: https://docs.microsoft.com/en-us/intune/conditional-access

Conditional access and blocking downloads

This week is all about using conditional access for blocking downloads. I already did something similar before by using app enforced restrictions for Exchange Online and SharePoint Online. This time I’m going to take it one step further by looking at recently adjusted functionality for Conditional Access App Control. Conditional Access App Control enables administrators to control user sessions by redirecting the user through a reverse proxy instead of directly to the app. From then on, user requests and responses go through Cloud App Security rather than directly to the app. This creates an additional layer that can be used to filter actions. In this blog post I’ll start with a short introduction about Conditional Access App Control, followed by the configuration steps and the end-user experience.

Note: Cloud App Security can be licensed as part of EMS E5 or as a standalone service.

Introduction

Now let’s start with a short introduction about Conditional Access App Control. Conditional Access App Control uses a reverse proxy architecture and is directly integrated with conditional access. Conditional access enables administrators to route users to Cloud App Security, where data can be protected. That can be achieved by applying Conditional Access App Control session controls. That created route enables user app access and sessions to be monitored and controlled in real time, based on access and session policies in Cloud App Security. Those policies can also be used to further refine filters and set actions to be taken on a user. In other words, Conditional Access App Control enables administrators to control user sessions by redirecting the user through a reverse proxy instead of directly to the app.

Configuration

Let’s continue by having a look at the configuration options, by looking at a specific scenario. That scenario is blocking downloads on unmanaged devices, for any supported cloud app. The following seven steps walk through that scenario. After the creation of the conditional access policy, it can be assigned to a user group like any other conditional access policy.

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;
3a

CAS-UsersGroups-IncludeOn the New blade, 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 Exclude to open the Exclude tab;

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

3b

CAS-UsersGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators.

4

CAS-CloudApps-IncludeOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select All cloud apps and click Done to return to the New blade;

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

5a

CAS-DeviceState-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, on the Include tab, select All device state and and click Exclude to open the Exclude tab;;

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

5b

CAS-DeviceState-ExcludeOn the Exclude tab, select Device Hybrid Azure AD joined, select Device marked as compliant and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude managed and compliant devices.

6

CAS-Session-CAACOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use Conditional Access App Control, select Block downloads (preview) and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block downloads for the assigned users, from the assigned cloud apps, on unmanaged devices. The latest options within this configuration are the built-in options Monitor only and Block downloads, which are both still in preview and Use custom policy…. The latter option requires a custom policy within Cloud App Security. The other options two basically provide preconfigured options, of which Block downloads provides the behavior that I need for this scenario.

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

Note: Conditional Access App Control supports any SAML or Open ID Connect app that is configured with single sign-on in Azure AD, including these featured apps.

End-user experience

Now let’s end this blog post by having a look at the end-user experience. Below are example for the behavior with SharePoint Online and Exchange Online. I deliberately choose those apps, to show the difference in end-user experience compared to using app enforced restrictions (which I mentioned in the beginning of this post). The big difference is that app enforced restrictions are handled by the app, while this configuration is handled by Cloud App Security.

Below on the left is an example of the end-user accessing SharePoint Online on an unmanaged device. The end-user receives a clear message that the access is monitored. Below on the right is an example of the end-user trying to download a file from SharePoint Online, while being directed via Cloud App Security. The end-user receives a clear message that the download is blocked.

CAS-Example-SPO01 CAS-Example-SPO02

Below are similar examples for Exchange Online. On the left the message that the end-user receives when access Exchange Online on an unmanaged device and on the right the message that the end-user receives when trying to download an email attachment.

CAS-Example-EXO01 CAS-Example-EXO02

More information

For more information regarding Cloud App Security and conditional access, please refer to the following articles:

Configure storage sense via Windows 10 MDM

This blog post uses the Storage node of the Policy CSP, to configure Storage Sense on Windows 10 devices. Most of the policies in that area are added in Windows 10, version 1903, which is currently still in preview.

This week a short blog post about a few newly introduced policy settings in Windows 10, version 1903, which is currently still in preview. Those settings are related to Storage Sense and those settings are made available via a newly introduced ADMX-file. That ADMX-file is StorageSense.admx. Storage Sense can automatically clean some of the user’s files to free up disk space. In this post I’ll briefly go through the available settings, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the available settings. The Storage area is not a new node within the Policy CSP, but starting with Windows 10, version 1903, it does contain multiple new policy settings. These policy settings are ADMX-backed policy settings, which are part of the new StorageSense.admx. Below is an overview of the available policy settings. Keep in mind that the complete node of these policy settings, starts with ./Device/Vendor/MSFT/Policy/Config/Storage/.

Policy Description

AllowStorageSenseGlobal

Values: 0 (Disabled) or 1 (Enabled)

This setting can be used to enable or disable Storage Sense and to make sure that the user cannot override that.

AllowStorageSenseTemporaryFilesCleanup

Values: 0 (Disabled) or 1 (Enabled)

This setting can be used to configure that when Storage Sense runs, it can delete the temporary files that are not in use.

ConfigStorageSenseCloudContentDehydrationThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can dehydrate cloud-backed content that hasn’t been opened in a certain amount of days.

ConfigStorageSenseDownloadsCleanupThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can delete files in the Downloads folder if they have been there for over a certain amount of days.

ConfigStorageSenseGlobalCadence

Values: 1 (Daily), 7 (Weekly), 30 (Monthly) or 0 (During low free disk space)

This setting can be used to configure Storage Sense to automatically clean some of the files to free up disk space.

ConfigStorageSenseRecycleBinCleanupThreshold

Values: 0-365 (Days)

This setting can be used to configure that when Storage Sense runs, it can delete files in the Recycle Bin if they have been there for over a certain amount of days.

Note: Even though these policy settings are ADMX-backed policy settings, I noticed that it wasn’t required to use specific configuration values. I could use simple integer values.

Configuration

Now let’s continue by having a look at the configuration options for Storage Sense. In other words, create a device configuration profile with the previously mentioned custom policy settings. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or device group.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Devices configuration – Profiles blade;
2 On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

MSIntune-DC-SS-01On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSIntune-DC-SS-02On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • OMA-URI: Specify a the required policy setting;
  • Data type: Select Integer;
  • Value: Specify the required value.

Note: Simply repeat this step for every policy setting that should be configured.

MSIntune-DC-SS-03

Note: At some point in time this configuration will probably become available in the Azure portal without the requirement of creating a custom OMA-URI.

End-user experience

Let’s end this post by looking at the end-user experience. Below is an example of a Windows 10 device running the latest available Windows Insider Preview build. In that example it’s clearly shown that Storage Sense is enabled and managed by the organization.

StorageSenseEnabled01

More details about the Storage Sense configuration can be found when clicking on Configure Storage Sens or run it now. These configuration options are shown below, including the configuration that I’ve applied, which can’t be adjusted.

StorageSenseEnabled02

More information

For more information about the available storage sense settings in the Policy CSP, please refer to the documentation about Policy CSP – Storage.