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.

Block access to all cloud apps for unsupported platforms

This week something different compared to the last couple of weeks. This week is all about conditional access, but not about particular new functionality. This week I want to show a relatively simple method to make conditional access policies as secure and complete as possible. By using device platforms as an example, I want to show how to make sure that only device platforms supported by the IT organization can access company data. And really only those device platforms. In this post I’ll provide a short introduction of this method, followed by the related configurations. I’ll end this post by showing the end-user experience.

Introduction

Let’s start with a short introduction about this method to make sure that only specific device platforms, supported by the IT organization, can access company resources (with company resources I’m referring to all the cloud apps, used by the organization, that are integrated with Azure AD). When creating conditional access policies, it’s possible to apply the conditional access policies only to specific device platforms. However, that will make sure that the conditional access policies are not applicable to any other device platform. That might create a backdoor in the conditional access setup. To prevent this type of backdoors, it’s the best to use at least two conditional access policies:

  1. Block access: The block access conditional access policy is used to block access for all device platforms with the exclusion of specific device platforms supported by the IT organization;
  2. Grant access: The grant access conditional access policy is used to grant access for the device platforms, excluded from the block access policy, supported by the IT organization. This can also be multiple conditional policies, when it’s required to differentiate between device platforms.

Note: Similar constructions can be created for basically any configuration within a conditional access policy that can differentiate between include and exclude configurations.

Configuration

Now let’s continue by looking at the actual configuration. The configuration contains at least two conditional access policies, which are explained below.

Block configuration

The first and main configuration is the block access configuration. This conditional access policy will be used to make sure that device platforms, that are unsupported by the IT organization, are not allowed to access company resources. Simply follow the seven steps below.

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

CAB-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

CAB-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. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

CAB-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, 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

CAB-DevicePlatforms-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, on the Include tab, select All platforms (including unsupported) and click Exclude to open the Exclude blade;

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

5b

CAB-DevicePlatforms-ExcludeOn the Exclude tab, select Android, iOS and Windows and click Done to return to the Conditions blade. On the Conditions bade, click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude specific device platforms that are supported by the IT organization and that will be covered with different conditional access policies. Keep in mind that every device platform that is excluded from this conditional access policy should be part of a separate conditional access policy (include).

6

CAB-Grant-BlockOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block access for all device platforms that are not supported by the IT organization and that are not part of a separate conditional access policy (include).

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

Allow configuration

The second configuration is the allow access configuration. This conditional access policy (or conditional access policies) will be used to make sure that the device platforms, excluded from the block configuration and that are supported by the IT organization, are allowed access to company resources when those devices meet specific requirements. To configure a conditional access policy like this simply follow the seven steps below.

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

On 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. Keep in mind that this can also be any user group that should be assigned, as long as in the end picture every user, using an excluded platform, is part of a conditional access policy. Also, when using Azure AD Sync it might be useful to exclude the service account, to enable the Azure AD synchronization.

3b

On 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. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

On 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. Keep in mind that this can also be any specific cloud app that should be assigned, as long as in the end picture every cloud app, that can be accessed by an excluded platform, is part of a conditional access policy. Also, when assigning all cloud apps it might be useful to exclude the Microsoft Intune Enrollment app, to enable enrollment for the devices.

5

On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, on the Include tab, select Select device platform and select Android, iOS and Windows and click Done to return to the Conditions blade. On the Conditions bade, click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all the earlier excluded device platforms. Keep in mind that this can also be any specific device platform, as long as in the end picture every device platform, that was initially excluded, is part of a conditional access policy.

6

On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access, select Require device to be marked as compliant and select Require Hybrid Azure AD joined device, select Require one of the selected controls 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 different device platforms, as long as the device meets the selected requirements. Keep in mind that this can be any of the available requirements.

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

Note: This configuration is not showing any screenshots as the screenshots are similar to the screenshots used within the block configuration.

End-user experience

Now let’s end this post by looking at the end-user experience. To make it a bit confusing, I’ll use a Windows 10 device to show the experience of a blocked user. Assuming Windows was not excluded by the block configuration, the end-user will receive a message similar to the message shown below. It doesn’t provide the end-user with the option to register the device, as the device is simply blocked.

CAB-Windows10

A good place to look for the end-result, from an administrator perspective, is to look at the sign-in information in the Azure portal (Azure Active Directory > Sign-ins). That will provide a failure message with a clear reason “Access has been blocked due to conditional access policies”.

CAB-Windows10-AAD

More information

For more information regarding conditional access, please refer to the following articles:

Configuring shared multi-user devices

This week is all about a recently introduced profile in Microsoft Intune to configure shared PC mode on a Windows 10 device. That profile is named Shared multi-user device profile. Something similar has been available already for a while via Intune for Education. The main use case for this profile are school devices that are shared between multiple students. In this post I’ll provide a brief introduction regarding shared PC mode, followed by the configuration (and the configuration options) of the Shared multi-user device profile. I’ll end this post by looking at the end-user experience.

Introduction

Let’s start with a short introduction about shared PC mode and immediately address the main use case. Shared PC mode s designed to be management- and maintenance-free with high reliability. A good example of devices that benefit from shared PC mode are school devices. These devices are typically shared between many students. By using the Shared multi-user device profile, the Intune administrator can turn on the shared PC mode feature to allow one user at a time. In that case, students can’t switch between different signed-in accounts on the shared device. When the student signs out, the administrator can also choose to remove all user-specific settings.

End-users can sign in to these shared devices with a guest account. After users sign-in, the credentials are cached. As they use the shared device, end-users only get access to features that are allowed by the administrator. For example, the administrator can choose when the shared device goes in to sleep mode, the administrator can choose if users can see and save files locally, the administrator can enable or disable power management settings, and much more. Administrators also control if the guest account is deleted when the user signs-off, or if inactive accounts are deleted when a threshold is reached.

Configuration

Now that it’s known what the main use case is of the the Shared multi-user device profile, let’s have a look at the configuration of the Shared multi-user device profile. The following four steps walk through the creation of the Shared multi-user device profile, including a short explanation with the different configuration options. After the creation of the profile, it can be assigned to a user and/or device group (just like any other profile).

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a SMUD-CreateProfileOn the Create profile blade, provide the following information and click Settings to open the Shared multi-user blade;

  • Name: Provide a valid name for the profile;
  • Description: (Optional) Provide a description for the profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Shared multi-user device;
  • Settings: See step 3b;
3b On the Shared multi-user device blade, provide the following configuration and click OK to return to the Create profile blade (see screenshot below);

  • Share PC mode: Select Enable to turn on shared PC mode. In shared PC mode, only one user can sign in to the device at a time. Another user can’t sign in until the first user signs out;
  • Guest account: Select Guest to create a guest account locally on the device that will be shown on the sign-in screen. These guest accounts don’t require any user credentials or authentication. Each time this account is used, a new local account is created;
  • Account management: Select Enable to turn on automatic deletion of accounts created by guests. These accounts will be deleted based on the account deletion configuration;
  • Account deletion: Select Immediately after log-out to make sure that created guests accounts are deleted immediately after log-out;
  • Local Storage: Select Disabled to prevent users from saving and viewing files on the hard drive of the device;
  • Power Policies: Select Disabled to prevent users from turning off hibernation, overriding all sleep actions, and changing the power settings;
  • Sleep time out (in seconds): Enter 60 (or any other value between 0 and 100) as the number of inactive seconds before the device goes into sleep mode;
  • Sign-in when PC wakes: Select Disabled to make sure that users don’t have to enter their username and password (they can use the guest account);
  • Maintenance start time (in minutes from midnight): Can be used to enter the time in minutes (0-1440) when automatic maintenance tasks, such as Windows Update, run.
  • Education policies: Select Enabled to use the recommended settings for devices used in schools, which are more restrictive. These settings are documented here;
SMUD-ShareMultiUserDevice.
4 Back on the Create profile blade, click Create.

Note: Besides configuring Windows Update, it is not recommended to set additional policies on devices configured with shared PC mode. The shared PC mode is optimized to be fast and reliable over time with minimal to no manual maintenance required.

End-user experience

Let’s end this post by looking at the end-user experience after assigning the Shared multi-user device profile. The first thing the end-user will notice is that it can click on the guest user account icon and simply click sign-in. No password will be required.

SMUD-Example01

Once logged on to the device, there are many places to look for a limited experience and specific configurations. I choose to show an important configuration related to the guest account and and few configurations related to available options to the end-user. Below on the right is an example of the guest accounts that are created. Every time the user logs off, the account will be disabled and a new account will be created. Below on the left and on the bottom are two examples related to permissions. It shows that the guest user can’t access the local C-drive and the Control Panel. It also confirms a statement at the beginning of this post; the main use case is schools. It clearly shows in the messages.

SMUD-Example02

More information

For more information regarding Windows 10 shared multi-user devices and configuring those devices in Microsoft Intune, please refer to the following articles:

Simply enabling Windows Sandbox

This blog post uses Containers-DisposableClientVM, to enable the Windows Sandbox feature on Windows 10 devices. This is available in Windows 10 Insider build 18305 or later.

This week is all about enabling a recently introduced Windows Feature. That Windows Feature is Windows Sandbox. Windows Sandbox is a lightweight desktop environment that is specifically created for safely running applications in isolation. It provides an isolated, temporary, desktop environment where users can run untrusted software without the fear of lasting impact to their device. Any software installed in Windows Sandbox stays in the sandbox and cannot affect the host. The installed software is permanently deleted, once Windows Sandbox is closed. Windows Sandbox is part of Windows 10 (Pro and Enterprise) Insider build 18305 or later. In this post I’ll show how to use Microsoft Intune to enable Windows Sandbox, followed by the end result.

Script

Let’s start  by looking at the PowerShell script that can be used to enable the Windows Sandbox feature. The following PowerShell script can be used to basically enable any Windows Feature, but will be used in this post to specifically install the Windows Sandbox feature.

Note: When using a virtual machine, nested virtualization must be enabled for that virtual machine. That can be achieved by using the following PowerShell cmdlet on the host machine: Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true.

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;
2 On the Device configuration – PowerShell scripts blade, click Add script to open the Script Settings blade;
3a EWS-AddPowerShellScriptOn the Add PowerShell script blade, provide the following information and click Settings to open the Script Settings blade;

  • 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 (ASCII) or 100 KB (Unicode).

3b EWS-ScriptSettingsOn the Script Settings blade, provide the following configuration and click OK to return to the PowerShell script blade;

  • Run the script using the logged on credentials: No;
  • Enforce script signature check: No;
4 Back on the Add PowerShell script blade, click Create.

End result

Now let’s end this post by looking at the results. To verify a success, simply start Windows Sandbox. That Windows Feature should be available now. To verify a success from a Microsoft Intune perspective, either check the status of the PowerShell script in the Azure portal , or look at the AgentExecutor.log and IntuneManagementExtension.log on the device.

EWS-Example

Note: By using PowerShell, at this moment, Windows Sandbox can also be enabled on not supported devices (devices without virtualization capabilities), .

More information

For more information regarding Windows Sandbox and PowerShell scripts in Microsoft Intune, please refer to the following articles:

Easily controlling the Office update channel by using administrative templates

Let’s start this new year about a specific use case for the recently introduced feature to configure administrative template settings via Microsoft Intune. That specific use case is to easily control and configure the Office update channel by using the Administrative Templates profile type within Microsoft Intune. Before, this configuration would require ingesting a custom ADMX and creating custom OMA-URI settings, for configuring the Office channel, based on the information in the ingested custom ADMX. That’s not necessary anymore, as Microsoft Intune now provides a built-in list of available administrative template policy settings. In this post I’ll show the configuration steps, followed by the configuration results on a Windows 10 device.

Configuration

Before looking at the actual configuration steps, it might be good to first refresh memories by looking at the naming of the update channels in the different locations. The following table shows the naming of the different channels in Microsoft Intune (and the Office apps) and in the actual ADMX. Good news! This is actually the last time that it’s really required to look at this information. As this post will show, it wasn’t even necessary for the configuration in this post. It will be useful for verifying the results. Microsoft Intune will now provide an easy method for configuring many ADMX-backed settings, without going through the actual ADMX anymore.

Azure portal ADMX setting
Monthly Channel FirstReleaseCurrent
Monthly Channel (Targeted) Current
Semi-Annual Channel Deferred
Semi-Annual Channel (Targeted) FirstReleaseDeferred
Insider Fast InsiderFast

When this would be a configuration of an ADMX-backed settings, the information in the table above would be really relevant during the configuration. Since recently Microsoft Intune contains a new profile type, named Administrative Templates. These profiles take care of the heavy work. In case of Office settings, which will be used in this post, these profiles even take care of ingesting the correct ADMX-files. The following six steps walk through the creation of an Administrative Templates profile type that will be used to configure the Office update channel. After the creation of the policies it can be assigned to a user and/or device group.

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

OfficeUpdates-CreateProfileOn the Create profile blade, provide the following information and click Create to open the <Name> blade;

  • Name: Provide a unique name for the device configuration profile;
  • Description: (Optional) Provide a description for the device configuration profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Administrative Templates (Preview);
4 On the <Name> blade, select Settings to open the <Name> – Settings blade;
5 On the <Name> – Settings blade, type Updates in the Search to filter items… field to filter the available settings to only update related settings and select Update Channel (as shown below) to open the Update Channel blade.
OfficeUpdates-Settings
6

OfficeUpdates-UpdateChannelOn the Update Channel blade, select Enabled to enable the setting, select the required update channel with Channel Name and click OK.

Note: Keep in mind that enabling a setting and clicking OK will directly save the change to the created device configuration profile. This is a similar experience to how changes are managed when working with normal group policies.

Note: In my device configuration profile I’ve also configured Enable Automatic Updates and Hide option to enable or disable updates to make sure that Office automatically checks for updates without an option for the user to disable Office updates.

Result

Now it’s really interesting to look at the result of the created configuration. For that, let’s first have a look at the registry. Below on the left is an overview of the registry key of the policy manager that contains the created Office configuration. It clearly shows the settings that should be configured, including the update branch. The update branch contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is an overview of the registry key of the policy manager that contains the ingested Office ADMX.

OfficeUpdates-Registry01 OfficeUpdates-Registry02

Another interesting location is the standard location in the registry that contains policy settings. Below on the left is an overview of the configured update branch. The update branch also contains the ADMX-setting value of Current, which was shown in table above, and matches my configured value, in Microsoft Intune, of Monthly Channel. Below on the right is the actual configuration of an Office app shown. That clearly shows the Monthly Channel configuration.

OfficeUpdates-Registry03 OfficeUpdates-Outlook01

Windows Insider MVP 2019!

Yeah! I just received a great email stating that I’m awarded the Windows Insider MVP! What a great way to start the new year! An unexpected, but really great start of the new year! Just awesome! I feel really honored and privileged to be awarded my first Windows Insider MVP award and to already been holding the Microsoft MVP (Enterprise Mobility) award for four years! Just awesome!

WIMVP2019

Of course none of this would be possible without the support of my great family I love them and couldn’t do this without their support! Just awesome! Ready for another great year! 

Offline Windows Autopilot deployment profile

This week is all about Windows Autopilot. More specifically, about offline Windows Autopilot deployment profiles. The use case for an offline Windows Autopilot deployment profile is simple, a migration from Windows 7 to Windows 10 for existing devices. It enables organizations to reimage devices for one last time and provide those devices with an offline Windows Autopilot deployment profile. That will make sure that those devices will contact the Windows Autopilot deployment service, without first being registered. In this post I’ll look at getting the offline Windows Autopilot deployment profile, followed by a look at the explanation of the attributes in the offline Windows Autopilot deployment profile. I’ll end this post by looking at the usage of the offline Windows Autopilot deployment profile and a method to group the devices that are deployed via an offline Windows Autopilot deployment profile.

How to get the offline deployment profile

Let’s start by having a look at how to get the offline Windows Autopilot deployment profile. The following five steps walk through the process of downloading the required PowerShell cmdlets, connecting to the correct services and saving the Windows Autopilot deployment profile as a JSON-file.

1 Open a Windows PowerShell command box, as an administrator, on an Internet connected device
2 Install the Azure AD module by using Install-Module AzureAD -Force
3 Install the Windows Autopilot module by using Install-Module WindowsAutopilotIntune -Force
4a Connect to the Intune service by using Connect-AutopilotIntune
4b Provide the user principle name of a user with enough administrative rights and provide the password in the Sign in to your account window
5

Export the Windows Autopilot deployment profile (Get-AutoPilotProfile), convert the deployment profile to JSON-fornat (ConvertTo-AutoPilotConfigurationJSON) and save the output as AutoPilotConfigurationFile.json (Out-File) by using Get-AutoPilotProfile | ConvertTo-AutoPilotConfigurationJSON | Out-File -FilePath $env:userprofile\desktop\AutoPilotConfigurationFile.json -Encoding ASCII

Note: When there are multiple deployment profiles configured in the tenant, there should be an additional filter being used to only export a specific deployment profile.

OWADP-JSON

Explanation of the attributes in the offline deployment profile

The JSON-file contains a few different attributes and it’s good to understand the usage of those attributes. The following table contains the different attributes and a short explanation.

Attribute Explanation
CloudAssignedTenantId This GUID is a required attribute and specifies the GUID of the Azure AD tenant that should be used.
CloudAssignedDeviceName This string is an optional attribute and specifies the naming pattern for devices that should be used.
CloudAssignedForcedEnrollment

This number is a required attribute and specifies if the device should require AAD Join and MDM enrollment. This can be one of the following values:

  • 0 = not required,
  • 1 = required.
Version This number is an optional attribute and specifies the version that identifies the format of the JSON file. For Windows 10, version 1809, the version must be 2049.
Comment_File This string is an optional attribute and specifies a comment that by default contains the name of the profile.
CloudAssignedAadServerData This encoded JSON string is a required attribute and specifies the branding configuration (this requires Azure AD branding to be enabled) that should be used.
CloudAssignedOobeConfig

This number is a required attribute and specifies a bitmap that shows which Autopilot settings should be configured. This can include the following values:

  • SkipCortanaOptIn = 1,
  • OobeUserNotLocalAdmin = 2,
  • SkipExpressSettings = 4,
  • SkipOemRegistration = 8,
  • SkipEula = 16
CloudAssignedDomainJoinMethod This number is a required attribute and specifies the domain join method that should be used. Both hybrid AAD join and AAD join should be set to 0.
ZtdCorrelationId This GUID is a required attribute and specifies a unique GUID that will be provided to Intune as part of the registration process. This GUID can be used to group the devices in a dynamic Azure AD security group.
CloudAssignedTenantDomain This string is a required attribute and specifies the name of the Azure AD tenant that should be used.

How to use the offline deployment profile

The offline Windows Autopilot deployment profile can be used on Windows 10, version 1809, or later. The only other requirements are that the file is named AutoPilotConfigurationFile.json and that the file is available in C:\Windows\Provisioning\Autopilot\. Below are a few example processes that can be used to prepare a device with an offline Windows Autopilot deployment profile.

1 Manual copy the file to the required location and SYSPREP the device,
2 Use a USB-stick to install Windows and in the same process copy the file to the required location and SYSPREP the device.
3 Use MDT to install Windows and in the same process copy the file to the required location and SYSPREP the device.
4 Use Configuration Manager to install Windows and in the same process copy the file to the required location and SYSPREP the device.
5 Use a third-party product to install Windows and in the same process copy the file to the required location and SYSPREP the device.

How to group devices based on the offline deployment profile

The last thing that is good to mention, is that it’s also possible to group devices based on the fact that it was deployment via an offline Windows Autopilot deployment profile. Devices that are enrolled by using an offline Windows Autopilot deployment profile, will have the Azure AD device attribute enrollmentProfileName set to “OfflineAutopilotprofile-<ZtdCorrelationId>”. The ZtdCorrelationId is available in the offline Windows Autopilot deployment profile as shown and mentioned above. That would make a dynamic query for an Azure AD device group like this: (device.enrollmentProfileName -eq “OfflineAutopilotprofile-7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC”).

More information

For more information regarding offline Windows Autopilot profiles, please refer this article about Windows Autopilot for existing devices.

Block access to a device until specific apps are installed

ESP-BlockApps-TweetThis week a short blog post about a recently introduced feature in the Enrollment Status Page (ESP). The ability block access to a device until specific apps are installed. I also tweeted about that feature recently and I thought it would be good to document the use case, the configurations and the end-user experience.

Introduction

Let’s start with a short introduction. The ESP is strongly recommended with Windows Autopilot. The idea of the ESP, is to block the device until the device is ready for usage by the user. This new feature enables an administrator to only block the device until the most important apps are installed for the user. That enables the user to be earlier productive. The administrator simply chooses which apps are tracked on the ESP and until those apps are installed, the user can’t use the device.

With the recent updates to Microsoft Intune, the ESP can track the following apps:

  • Licensed Microsoft Store for Business apps;
  • Line-of-business apps (APPX, MSIX, single-file MSI)
  • Office 365 ProPlus apps

Note; Keep in mind that there are difference between the user context and the system context. For the exact up-to-date details see the links in section More information.

Configuration

Now let’s continue by looking at the available configuration options. The following three steps walk through adjusting the default ESP. Those steps will show which configurations are required to get to the available configuration options for tracking specific apps. Similar steps are applicable when configuring custom ESPs.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 On the Enrollment Status Page (Preview) blade, select Default > Settings to open the All users and all devices – Settings blade;
3a On the All users and all devices – Settings blade, select Yes with Show app and profile installation progress and Yes with Block device use until all apps and profiles are installed to enable the Block device use until these required apps are installed if they are assigned to the user/device setting (see step 3b);
3b When the Block device use until these required apps are installed if they are assigned to the user/device setting is enabled, select Select apps to open the Select apps blade. On the Select apps blade, select the required apps and click Select to return to the All users and all devices – Settings blade and click Save;
ESP-BlockApps-Config

Note: Keep in mind that if the ESP is configured to track Office 365 ProPlus apps, other large apps, or just many apps, it might be required to also increase the timeout as documented in this Support Tip.

End-user experience

Now let’s end this post by looking at the end-user experience. The good thing is that the user will not notice any big differences. The user will still get the same screens and the same experiences. Only users that pay attention to details will notice the small differences. As shown below, the user will see a list of apps that is equal to the number of configured apps by the administrator. That list is most likely shorter then it was before. That’s also the reason why the user might notice that it’s possible to get productive sooner, as the device will be available for use sooner.

ESP-BlockApps-EUE

More information

For more information regarding blocking devices until certain apps are installed, please refer to the following articles: