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

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:

Conditional access and Outlook on the web for Exchange Online

This week a blog post about conditional access. More specifically, about conditional access and enforced restrictions with Outlook on the web for Exchange Online. This can be used to provide users with access to Outlook on the web, but still protect company data. That can be achieved by configuring a limited experience for users with regards to attachments. The enforced restrictions can enable a read only option for attachments in the browser and can completely block attachments in the browser. In this post I’ll walk through the required configurations, with the focus on conditional access, and I’ll show the end-user experience.

Configuration

Let’s start with looking at the configuration. The main focus in the configuration is conditional access, but as that configuration has no use without configuring the Outlook on the web mailbox policies, I’ll also provide the main configuration options from an Exchange Online perspective.

Exchange Online configuration

The most important and only configuration, from an Exchange Online perspective, is to configure the Outlook on the web mailbox policy. That configuration must be done by using PowerShell. When there is an Outlook on the web mailbox policy, the required cmdlet is Set-OwaMailboxPolicy. That cmdlet contains the parameter ConditionalAccessPolicy. That parameter can be used to specify the Outlook on the web mailbox policy for limited access and can have the following values:

  • Off: This value means that no conditional access policy is applied to Outlook on the web;
  • ReadOnly: This value means that users can’t download attachments to their local computer, and can’t enable offline mode on non-compliant computers;
  • ReadOnlyPlusAttachmentsBlocked: This value means that all restrictions from ReadOnly apply, but that users can’t view attachments in the browser.

Note: In the end-user experience section, I’ll show the experience for both values.

Conditional access configuration

Once the conditional access policy configuration is in place for the Outlook on the web mailbox policy, it’s time to look at the actual conditional access configuration in Azure AD. The following eight steps walk through the steps to create a conditional access policy that will require multi-factor authentication and enforce a restriction on Outlook on the web, for devices that are not hybrid Azure AD joined and that are not compliant.

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

OOTW-UsersGroupsOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;

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

4

OOTW-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Office 365 Exchange Online and click Done;

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

5a

OOTW-DevicePlatformsOn 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, select All platforms (including unsupported) and click Done to return to the Conditions blade;

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

5b

OOTW-ClientAppsBack on the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Browser and click Done to return to the Conditions blade;

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

5c

OOTW-DeviceStateBack 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, select Device Hybrid Azure AD joined and Device marked as compliant on the Exclude tab and click Done and Done;

Explanation: This configuration will make sure that this conditional access policy is applicable to unmanged devices, by excluding hybrid Azure AD joined and compliant devices (which are both considered managed).

6

OOTW-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select;

Explanation: This configuration will make sure that this conditional access policy will require multi-factor authentication .

7

OOTW-SessionOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use app enforced restrictions and click Select;

Explanation: This configuration will make sure that this conditional access policy will enforce the configured restrictions in Outlook on the web for Exchange Online..

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

End-user experience

Let’s end this post by looking at the end-user experience, for both configurable values for the Outlook on the web mailbox policy for limited access. When using an unmanaged device the user must user multi-factor authentication, which will be followed by the experiences showed below.

The first value is the ReadOnly value, which forces read only restrictions to any email attachment. Besides that it also prevents users from saving the attachments locally, as it only allows the user to save the attachments to OneDrive. Below is an example of that behavior. It also shows on top of the mail that the user is notified about the limited experience.

OutlookOTW-ReadOnly

The second value is the ReadOnlyPlusAttachmentsBlocked value, which forces email attachments to be blocked from being opened via Outlook on the web. Basically it prevents any interaction with the attachment. Below is an example of that behavior. It also shows on top of the mail that the user is notified about the limited experience.

OutlookOTW-ReadOnlyPlusAttachmentsBlocked

Note: This behavior does require disciplined users, as these type of limitations in the user experience might trigger users to forward messages to another account.

More information

For more information about conditional access in combination with Outlook on the web for Exchange Online, please refer to the following articles:

Quick tip: Intune Diagnostics for App Protection Policies via about:intunehelp

This week a relatively short blog post about a feature that already exists for a long time, but that is not that known. That feature is the Intune Diagnostics for App Protection Policies (APP). The Intune Diagnostics can be really useful with troubleshooting APP. Especially when looking at APP for apps on unmanaged devices.  The Intune Diagnostics provides information about the device, provides the ability to collect logs and provides the ability to look at the applied APP for the different apps. The Intune Diagnostics can be accessed on iOS devices, by using the Intune Managed Browser or by using Microsoft Edge. In this post I’ll only look at the experience when with the Intune Diagnostics.

The experience

Let’s start at the beginning, which is to get to the Intune Diagnostics. This can be achieved by opening the Intune Managed Browser or Microsoft Edge and simply type about:intunehelp as the address. That will open the Intune Diagnostics page, as shown below. The Intune Diagnostics page contains two sections, 1) the Collect Intune Diagnostics section and 2) the Shared Device Information section. The first section can be used to collect logs of all Microsoft Intune managed apps and the second section provides information about the device and the managed apps.

IMG_0155

When clicking on the Get Started link in the Collect Intune Diagnostics section, it will open the Collect Intune Diagnostics page, as shown below. The Collect Intune Diagnostics page can be used to actually share the Microsoft Intune managed apps logs with an administrator (or with Microsoft), by simply clicking on the Share Logs link.

IMG_0156

When clicking View Intune App Status link in the Shared Device Information section, it will open the Intune App Status page, as shown below. The Intune App Status page can be used to actually look at the info about the installed managed apps. By selecting an app in the top of the page, it will show the currently applied policy (including information regarding the app version and the policy check-in). This can be really useful with for example verifying if the latest APP is applied.

IMG_0157

For simplifying the end-user experience, an app configuration policy can be used for the Intune Managed Browser and Microsoft Edge to add a bookmark. That can be achieved by using the following information:

  • key: com.microsoft.intune.mam.managedbrowser.bookmarks
  • value: Intune Diagnostic|about:intunehelp

More information

For more information about the Intune Diagnostics page, please refer to the following articles:

Hybrid Azure AD join with Windows Autopilot

This week is all about a very often requested feature, which is the ability to hybrid Azure AD join a device when using Windows Autopilot. The combination of the latest updates to Microsoft Intune with Windows 10, version 1809, provides just that! The ability to hybrid Azure AD join a device when using Windows Autopilot! In other words, the device will join the on-premises Active Directory and register in Azure Active Directory. In this blog post I’ll start with a short introduction about the hybrid Azure AD join with Windows Autopilot, followed by the most important configurations. I’ll end this post by looking at the experience.

Introduction

Let’s start with a little introduction about the hybrid Azure AD join through Windows Autopilot. A short summary would be that Intune uses an on-premises connector to create an offline domain join (ODJ) blob for the device that will be provided to the device during enrollment. Now lets go through the high-level Autopilot flow for this scenario and see how that fits.

  • The hardware ID of the device is registered with the Windows Autopilot service;
  • The device is sent to the employee and the employee unboxes the device and turns it on;
  • The device connects to the Windows Autopilot service;
  • The Windows Autopilot service delivers the Autopilot profile to the device;
  • The device performs a MDM-enrollment with Microsoft Intune;
  • Microsoft Intune will use the on-premises connector to generate a machine object in Active Directory, which will generate an ODJ blob;
  • The connector sends the ODJ blob to Microsoft Intune;
  • Microsoft Intune sends the ODJ blob to the device;
  • The MDM-enrollment is completed;
  • The user logs on to the device to complete the domain join;
  • The device receives any targeted group policies;

Configuration

Now let’s continue by looking at the configurations that are required to enable the hybrid Azure AD join scenario via Windows Autopilot. I’ll do that by going through the new Intune-related configurations. That means, I’ll show how to install the Intune connector, I’ll show how to configure the Autopilot deployment profile and I’ll show how to configure the domain join profile.

Requirements

Before looking at the configurations, let’s start with a few important requirements and limitations:

  • The hybrid Azure AD join environment configurations must be in place;
  • The device must run Windows 10, version 1809 or later;
  • The device must have Internet access;
  • The device must have direct access to Active Directory;
  • Automatic enrollment must be configured (Azure AD > Mobility (MDM and MAM));
  • The server hosting the Intune connector must have delegated permissions to create computer accounts in the specified OU;
  • The server hosting the Intune connector must be Windows Server 2016, or later;
  • The server hosting the Intune connector must have Internet connectivity;

Intune connector

The first configuration that should be in place is the installation of the Intune connector. Multiple connectors can be installed to increase scale and availability (or even to support multiple Active Directory domains). The following nine steps walk through the steps to install the Intune connector.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Intune Connector for Active Directory (Preview) to open the Intune Connector for Active Directory (Preview) blade;
3 On the Intune Connector for Active Directory (Preview) blade, select Add connector to open the Add connector blade;
4 On the Add connector blade, click the Download the on-premises Intune Connector for Active Directory to download the connector for Active Directory (ODJConnectorBootstrapper.exe);
5 On the server that should be running the Intune connector for Active Directory, run ODJConnectorBootstrapper.exe;
6 On the Intune Connector for Active Directory Setup dialog box, select I agree to license terms and conditions and click Install;
7 On the Intune Connector for Active Directory Setup dialog box, after the installation completed, select Configure Now ;
8 On the Intune connector for Active Directory dialog box, select Sign In to sign in with a global administrator account to enroll the connector in the tenant and close the dialog box;
9 Back on the Intune Connector for Active Directory (Preview) blade, it should now show an entry for the added connector with the name of the server that is running the connector;
ICforAD

Note: At this moment, make sure that a language pack is installed and configured as described in the Intune Connector (preview) language requirements.

Autopilot deployment profile

The second configuration that should be in place is the Windows Autopilot deployment profile. The following four steps walk through the steps to create the deployment profile. That deployment profile can be assigned to an Azure AD group that contains the required Autopilot devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a WADP-HAADJOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;
  • Deployment mode: Select User-Driven, as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Select Hybrid Azure AD joined (Preview), as that will trigger the on-premises domain join with device registration in Azure AD;
  • Out-of-box experience (OOBE): See 4b

Note: The hybrid Azure AD join is only available for user driven deployments.

4b

On the Out-of-box experience (OOBE) blade, provide the following information and click Save.

  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot hybrid Azure AD join experience;

  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot hybrid Azure AD join experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot hybrid Azure AD join experience;
  • User account type: Select Standard to only make any user on the device a standard user;
  • Apply computer name template (Windows Insider Only): Not applicable, as the computer name standard is defined in the Domain Join profile (see next section);
WADP-HAADJ-OOBE

Domain Join profile

The third configuration that should be in place is the domain join profile. The following four steps walk through the steps to create the domain join profile. That domain join profile can be assigned to an Azure AD group that contains the required Autopilot devices.

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;
3a On the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the domain join profile;
  • Description: (Optional) Provide a description for the domain join profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Domain Join (Preview);
  • Settings: See 3b;
3b On the Domain Join (Preview) blade, provide the following information and click OK;

  • Computer name prefix: Provide a computer name prefix. The remaining characters of the 15 characters of a computer name will be random;
  • Domain name: Provide the domain name that the device will join;
  • Organizational unit: (Optional) Provide the OU that the computer account is created in;
WADP-HAADJ-DJP

Note: When no OU is specified, the well known computer object container is used.

End-user experience

Let’s end this post by looking at the end-user experience. The beginning of the out-of-box-experience (OOBE) is similar to any other Windows Autopilot deployment. The difference is happening in the background, as explained during the introduction, and can be noticed during the Network configuration. The configuration will take longer than with a Azure AD join. Another thing that an administrator might notice is that the device will be available within Intune before it’s available within the Active Directory. That makes perfect sense as the domain join profile must come via Microsoft Intune.

WADP-HAADJ-CORP

Note: From an administrator perspective the Event Viewer, on the server running the connector, will show Event ID 30140 in the log ODJ Connector Service from the source ODJ Connector Service Source, with a successful creation of the computer object.

More information

For more information regarding Windows Autopilot and hybrid Azure AD join, please refer to the following articles: