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.

Intune role-based administration control and devices

This week a little bit about role-based administration control (RBAC) in combination with devices, in Microsoft Intune. I specifically want to look at that combination, as the RBAC-model in Microsoft Intune differs in that area from how the RBAC-model works in Configuration Manager. Within Configuration Manager a delegated administrator would be a combination between a security role (that defines the permissions and a security scope (that defines the objects). In that case the security scope is a combination between tagged objects and users and devices in specified collections. Specifically that last section, regarding the collections, is were the RBAC-model differentiates from Microsoft Intune. In this post I want to provide a short introduction to the different pieces of RBAC in Microsoft Intune, followed by how those pieces together impact the devices within Microsoft Intune.

Introduction

Now let’s start by having a look at RBAC in Microsoft Intune. RBAC helps administrators to control who can perform various Intune tasks within the organization, and who those tasks apply to. Administrators can either use the built-in roles that cover some common Intune scenarios, or create their own roles. Below is an overview of the different components of an Intune role. The permissions and the assignment.

MSIntune-RBAC

A summary of the overview would be that an Intune role is defined by:

  • Permissions: The permissions of the Intune role;
  • Assignments: The assignment of the Intune role is the combination of the members, the scope and the scope tags. Those components are used for the following:
    • Members: The user groups that are granted the permissions of the Intune role;
    • Scope: The user or device groups that the members can manage;
    • Scope tag:
      The objects that the members can see.

Bringing the pieces together

Previously an often heard comment was that an administrator could delegate permissions to a delegated administrator, but the delegated administrator would still see all the device objects. That has changed with the introduction (and recent modifications) of Scope tags! This is also the point were the RBAC-model differs from that of Configuration Manager. Main reason, within Microsoft Intune it’s required to specifically tag the objects that the delegated administrators can see. Including the devices. That means, using a Scope to determine which users and/or devices the delegated administrator can manage and using Scope tags to determine which devices the delegated administrator can see.

The Scope tag configuration is a little bit hidden and unknown on devices. The configuration can be found by going to the Properties of a device, as shown below.

DevicePropertiesTag

As the configuration of a Scope tag is currently done per device, it might be smart to look at automating that process. To help with that automation, Microsoft recently provided a PowerShell example for assigning a Scope tag to a device.

More information

For more information regarding to RBAC in Microsoft Intune, please refer to the following articles:

Remotely selective wipe WIP without enrollment devices

This week week a relatively short blog post about the ability to remotely selective wipe Windows Information Protection Without Enrollment (WIP-WE) devices. Almost two years ago I already wrote about app protection for Windows 10 (back than referred to as MAM-WE). That was the first piece of the without-enrollment-puzzle for Windows 10 devices. The second piece of that puzzle is just recently introduced, and is the subject of this post, which is the ability to remotely selective wipe those WIP-WE devices. In my opinion the third and yet still missing piece of that puzzle would be conditional access (require a managed app). Hopefully we can complete that puzzle soon. In this post I’ll show the remote action to selectively wipe a WIP-WE device, followed by pieces of the end-user experience.

Remote action

WIP-WE allows organizations to protect their corporate data on Windows 10 devices without the need for full MDM enrollment. Once documents are protected with a WIP-WE policy, the protected data can be remotely selectively wiped by a Microsoft Intune administrator. The following steps walk through the process of sending a remote wipe request to a Windows 10 device, to make sure that all protected corporate data will become unusable.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > App selective wipe to open the Client apps – App selective wipe blade;
2 On the Client apps – App selective wipe blade, click Create wipe request to open the Create wipe request blade;
3a

WIPWE-RequestOn Create wipe request blade, provide the following information and click Create:

  • User: See step 3b for more details;
  • Device: See step 3c for more details;
3b

WIPWE-UserOn the User blade, search for the specific user and click Select:

Note: This can be any user available in Azure AD.

3c

WIPWE-DeviceOn the Select Device blade, select the specific device(s) and click Select:

Note: This will only show the available devices for the selected user.

WIPWE-Success

Note: The permissions required to perform this wipe action, are Managed apps > Wipe.

End-user experience

Now let’s have a look at the end-user experience. I won’t go in to details about the min-enrollment that should be performed, as I’ve shown that before. What I do want to show is the name of the management account, below on the left, as that name is also displayed in the unenrollment message. Below on the right is the message that the end-user will receive once the remotely selective wipe is triggered. It will clearly show that the workplace account is removed. Personally I think that this message could use some adjustments to better explain the impact.

WIPWE-Enrolled WIPWE-Message

The unenrollment directly impacts the end-user experience. It doesn’t remove the locally saved corporate data, but it does revoke the encryption keys. That effectively removes the access to the locally saved corporate data. Below on the right is a locally saved corporate document, while the user is still enrolled. Below on the right is that locally saved corporate document, after being remotely selective wiped. Imagine how powerful this will become once we can require a managed device, or a managed app, in conditional access, for Windows 10 devices.

WIPWE-Encrypted WIPWE-EncryptedRevoked

Note: Make sure that the advanced setting Revoke encryption keys on unenroll is set to On. That’s the only way to actually revoke the access to the encrypted files.

More information

Fore more information regarding WIP, the current limitations of WIP and the creation of WIP-WE policies, please refer to the following articles:

Easily managing Managed Google Play apps directly in Microsoft Intune

This week is all about the simplified experience for managing Managed Google Play apps directly in Microsoft Intune. The Managed Google Play store is used to deploy apps to devices managed via Android Enterprise. Before it was required to separately navigate to the Manage Google Play store to approve apps and after approval it was required to synchronize the approved apps with Microsoft Intune. Now the approval (and deletion) of Managed Google Play apps can be achieved by using Microsoft Intune only. Besides the better user experience, the fact that Google announced the deprecation of the device admin management API, means that it’s really time to look at the Managed Google Play store and apps and Android Enterprise in general.

In this post I will not look at Android Enterprise and the different deployment models. that might be something for another post, but I will look specifically at managing Managed Google Play apps. I’ll do that by quickly showing how to connect Microsoft Intune with Managed Google Play, followed by the steps and experience for adding and deleting Managed Google Play apps in Microsoft Intune.

Connect Microsoft Intune and Managed Google Play

The first configuration that should be in place, before any configuration related to Android Enterprise can be performed, is the connection between Microsoft Intune and Managed Google Play. The following three steps walk through connecting Microsoft Intune and Managed Google Play to enable managing Android Enterprise devices and deploying Managed Google Play apps. As this is not the main subject of this post, the steps describe the main actions.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Android enrollment to open the Device enrollment – Android enrollment blade;
2 On the Device enrollment – Android enrollment blade, click Managed Google Play to open the Managed Google Play blade;
3

On the Managed Google Play blade, complete the following two steps:

  1. Select I agree with I grant Microsoft permission to send both user and device information to Google
  2. Click Launch Google to connect now and walk through the Google Play steps

Note: Connecting Microsoft Intune and Managed Google Play is required for managing Managed Google Play apps by using Microsoft Intune.

Add a Managed Google Play app

Once the connection between Microsoft Intune and Managed Google Play is configured, Microsoft Intune can be used for managing Managed Google Play apps. Even without the need to authenticate with every action regarding managing Managed Google Play apps. The following three steps walk through the process of adding a Managed Google Play app by using Microsoft Intune. I’m using the NBA app as an example and after adding the app, it can be assigned to a user and/or device group like any other app.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3a

MGP-AddApp01On the Add app blade, provide the following information and click Sync;

  • App type: Managed Google Play;
  • Managed Google Play: See step 3b – 3f;
3b On the Search managed Google Play blade, search for the required app;
MGP-AddApp02
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MGP-AddApp03
3d

MGP-AddApp04On the dialog box with app permissions, click Approve to continue to the selection about handling new app permissions;

Important: Keep in mind that this will accept these permissions on behalf of the organization.

3e

MGP-AddApp05On the dialog box about handling new app permissions, select Keep approved when app requests new permissions and click Save to return to the Search managed Google Play blade;

Important: Keep in mind that this decision might impact the future app permissions and/or the future user experience.

3f On the Search managed Google Play blade, click OK;
MGP-AddApp06

Note: These steps will approve the app in the Managed Google Play store and sync the approved app in to Microsoft Intune.

Delete a Managed Google Play app

Similar to adding Managed Google Play apps, these apps can now also be deleted by using Microsoft Intune. The following three steps walk through the process of deleting a Managed Google Play app by using Microsoft Intune. I’m using the NBA app as an example again.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, search for the required app, select the three dots and click Delete to open an Are you sure? dialog box;
MGP-DeleteApp01
3 On the Are you sure? dialog box, click Yes;
MGP-DeleteApp02

Note: These steps will programmatically un-approve the app in the Managed Google Play store and sync the result to Microsoft Intune.

More information

For more information regarding managing Managed Google Play apps via Microsoft Intune, please refer to this article about Adding Managed Google Play apps to Android enterprise devices with Intune.