Another new discovery method: Meet the Azure Active Directory Group Discovery!

This week is back to the world of Configuration Manager. With the release of Configuration Manager, version 1906, a lot of new features are introduced. Even a few very nice pre-release features. One of these pre-release features is the subject of this post, the Azure Active Directory Group Discovery. The Azure Active Directory Group Discovery can be used to discover user groups and members of those groups from Azure AD. In case there are users found in Azure AD user groups that haven’t been previously discovered, those users will be added as user resources in Configuration Manager. A user group resource record is created when the group is a security group. In this post I’ll briefly show the prerequisites, followed by the configuration steps. I’ll end this post by showing the administrator experience.

Prerequisites

Let’s start with the prerequisites that should be in place to configure the Azure Active Directory Group Discovery. The following 2 prerequisites should be configured.

1 Enable pre-release feature: The pre-release feature must be enabled. That can be achieved by simply doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Updates and Servicing > Features. Select Azure Active Directory user group discovery and click Turn on in the Home tab;
CM-AADUGD-Prerelease
2 Enable cloud management: The cloud management Azure service must be added. That can be achieved by doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services. Click Configure Azure Services in the Home tab and follow the documented instructions here;

Configuration

When the prerequisites are in place it’s time to look at the actual configuration steps. The following 7 steps walk through the required configuration steps for enabling Azure Active Directory Group Discovery.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 Select the Cloud Management Azure service and click Properties in the Home tab, to open the Cloud Management Properties dialog box;
CM-AADUGD-Properties
3

CM-AADUGD-CMPropertiesOn the Cloud Management Properties dialog box, select the Discovery tab, select Enable Azure Active Directory Group Discovery and click Settings to open the Azure AD Group Discovery Settings dialog box.

Note: The Settings button will be disabled when Enable Azure Active Directory Group Discovery is not selected.

4

CM-AADUGD-AADGDSOn the Azure AD Group Discovery Settings dialog box, select the Discovery Scopes tab and click Add to open the Select Azure Active Directory Objects dialog box.

Note: Once an Azure AD group is added, it will be shown in the overview of this dialog box.

5

CM-AADUGD-SAADOOn the Select Azure Active Directory Objects dialog box, (optionally add a name in the Name starts with text box) click Search to find the specific Azure AD group(s), select the Azure AD group and click OK.

Important: The search results will show cloud only Azure AD groups for both users and devices. Also, credentials will be requested when searching for Azure AD groups for the first time.

Note: Repeat this step for all applicable Azure AD groups.

6

CM-AADUGD-CMPropertiesPSBack on the Azure AD Group Discovery Settings dialog box, select the Poling Schedule tab. Use this tab to make adjustments to the discovery schedule.

Note: At this moment delta discovery is disabled.

7 Back on the Cloud Management Properties dialog box, click OK.

Note: Keep in mind that this is currently still a preview features.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 Discovery method: One of the most interesting items is the new Azure Active Directory Group Discovery itself. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, and selecting the Azure Active Directory Group Discovery Agent Type, provides the option Run Full Discovery Now.
CM-AADUGD-Overview
2 Log file: One of the most important items is the log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery and about the full discoveries of the Azure Active Directory Group Discovery (as shown below). The nice part is that the log file also provides information about the Microsoft Graph requests that it uses for the different discoveries.
CM-AADUGD-Log
3 CM-AADUGD-GroupPropCloud-only user groups: The most useful item is the availability of the cloud-only user groups in the on-premises environment. These user groups can be recognized by only having the Agent Name of SMS_AZUREAD_USER_GROUP_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only user groups in the Configuration Manager environment, and the availability of the new attributes for existing user groups, enables a whole lot of new scenarios. Most of these scenarios are related to co-managing Windows 10 devices with Configuration Manager and Microsoft Intune.
4 Group properties: The overall most interesting, most important and most useful item is the information in the database. The main user group tables and views now contain additional fields for cloud-related information. Some nice information can be found below, were I used a simple query to get some basic information about user groups. That information shows a few important differences with normal user groups. The group contains Azure AD information.
CM-AADUGD-SQL

More information

For more information about the Azure Active Directory Group Discovery, please refer to the Configure Azure Active Directory user group discovery section in the documentation about configuring discovery methods for Configuration Manager

Android Enterprise fully managed devices and the Google Play store

This week another post about an Android Enterprise configuration. Last week was related to company owned single-use (COSU) devices (also known as dedicated devices), while this week is related to company owned business only (COBO) devices (also known as fully managed devices). More specifically, about adding a personal touch to fully managed devices. Microsoft Intune doesn’t know the company owned personally enabled (COPE) devices, yet, but there is a feature within the fully managed devices configuration that can at least enable some more personal options to the user. That can be achieved with a simple configuration to allow access to all apps in the Google Play store. I’ll start this post with the configuration steps (and a little introduction) and I’ll end this post by having a look at the end-user experience.

Configuration

Let’s start with a quick introduction about the setting that should be configured and the impact of that setting. The setting Allow access to all apps in Google Play store must be set to Allow. Once it’s set to Allow, users get access to all apps in Google Play store. Apps can be sort of blocked by the administrator by assigning an uninstall of the apps to the user (or device). That will simply remove the app (over-and-over) again. When it’s set to Not configured, users are forced to only access the apps the administrator makes available (or required) via the Google Play store.

The following 3 steps walk through the process of creating a device restrictions policy that enables access to the Google Play store for users.

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, click Create profile to open the Create profile blade;
3a

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

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner > Device restrictions
  • Settings: See step 3b
3b On the Device restrictions blade, select Applications to open the Applications blade; and click OK to return to the Add configuration policy blade;
3c On the Applications blade, select Allow with Allow access to all apps in Google Play store and click OK and OK to return to the Create profile blade;
AEFMD-Applications

Note: This profile can be assigned to user and device groups.

End-user experience

Now let’s end this post by having a look at the end-user experience. Depending on the exact configuration the end-user can end up with one of the three scenarios as shown below.

  1. Below on the left is showing the Google Play store for the work account only, without access to all apps in the Google Play store.
  2. Below in the middle is showing the Google Play store for the work account only, with access to all apps in the Google Play store. Even though my store is in Dutch, the number of items in the menu, and the apps shown in the background, show the difference.
  3. Below on the right is showing the Google Play store for the work account when also a personal account is added (see the purple circle with a “P”). It provides the same options as shown in the middle, but also enables the user to switch between accounts.
Screenshot_20190729-172606_Google Play Store Screenshot_20190729-181300_Google Play Store Screenshot_20190724-210437_Google Play Store

The combination for the user to add a personal account to the device and being able to install apps via the Google Play store, will at least give the user some options to personalize the device.

More information

For more information about the device configuration options for Android Enterprise fully managed devices, please refer to the Device owner section in the documentation about Android Enterprise device settings to allow or restrict features using Intune.

Create a custom multi-app kiosk mode

This week is all about creating a custom multi-app kiosk mode for Android Enterprise dedicated devices. The Android Enterprise dedicated device settings also contains multi-app kiosk settings, but in some scenarios those settings can still be a little bit limiting. To create a multi-app kiosk mode, Microsoft Intune relies on the Managed Home Screen app. The fun part is that the Managed Home Screen app already contains a few more settings that are currently only available via app configuration policies. In this post I’ll start with a quick overview of the app configuration options that exist nowadays, followed by showing an app configuration example for the Managed Home Screen app to add a non-Managed Google Play Store app. Technically speaking I’ll add a single app, using the multi-app configuration option. Really adding multiple apps is more of the same. I’ll end this post by showing the end-user experience.

It’s important to keep in mind that the preferred and advised method to configure multi-app kiosk mode settings is still by using the dedicated device settings.

App configuration options

Let’s start this post by having a look at the app configuration options that are available nowadays. In the early days it was still required to manually configure configuration keys and values. These days Intune can prepopulate configuration keys that are available within the Android apps. Below is a quick overview of the 2 app configuration options that are available :

Configuration designer: The Configuration designer can be used to configure simple settings via the UI. It will automatically populate the available configuration keys within the app and allows the administrator to configure the simple configuration values. As long as the value type is not BundleArray
MSH-ConfigurationDesigner
JSON data: The JSON data can be used to configure all settings via a JSON template. The template will automatically populate the available configuration keys within the app and allows the administrator to configure all the configuration values.

MHS-JSONEditor

Configure the Managed Home Screen app

Now the app configuration options are clear. Let’s have a look at the app configuration of the Managed Home Screen app. As an example I want to use a setting that is only configurable via JSON data, as the value type is a BundleArray. That setting is to add (custom non-Managed Google Play Store) apps to the Managed Home Screen app. The following 3 steps walk through the process of creating an app configuration policy that enables the built-in Settings app to the multi-app kiosk mode.

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

MHS-AddConfigPolicyOn the Add configuration policy blade, provide the following information and click Add;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Device enrollment type: Select Managed devices
  • Platform: Select Android
  • Associated app: See step 3b
  • Configuration settings: See step 3c
  • Permissions: See step 3d

Note: The main focus of this post is the configuration around the configuration settings (step 3c). That doesn’t mean that the permission configuration (step 3d) can’t be really useful when the app needs specific permissions. As it’s not the key part of this post, I won’t go into to much details for now.

3b

On the Associated app blade, select Managed Home Screen and click OK to return to the Add configuration policy blade;

Note: When the Managed Home Screen app is not available make sure that that the app is approved and synchronized with Intune.

3c

On the Configuration settings blade, select Enter JSON data with Configuration settings format. Now either click Download JSON template, for offline editing, or use the JSON editor to directly configured the required configuration keys. Before clicking on OK to return to the Add configuration policy blade, go through the following 3 steps (see also the screenshot below):

  1. Navigate to the applications configuration key to add the required apps for the custom multi-app kiosk mode. In my example, I add the Settings app (com.android.settings) to my multi-app kiosk mode. The valueString should be the app package name. To add another app simply copy the complete managedProperty and adjust the valueString.
  2. To be able to save the configuration, make sure to change all the values that need to be configured and still state something like STRING_VALUE. When a setting is not needed it can also be removed.
  3. The red areas on the scrollbar show the locations of values that must be adjusted or removed before the configuration can be saved.

Note: Make sure that the settings in the app configuration policy don’t overlap with settings in the dedicated device configuration.

MHS-JSONEditor-Config
3d On the Permissions blade, click Add to open the Add permissions blade. The Add permissions blade can be used select permissions that should be overridden. Select the required permissions and click OK to return to the Permissions blade and click OK to return to the Add configuration policy blade.

Note: At some point in time these configuration options will probably become available in the multi-app kiosk mode settings for dedicated devices.

End-user experience

Let’s end this post by having a look at the end-user experience. When the device is enrolled and the assigned apps are installed, the device will ask to select a home screen app (the message will actually show after the installation of the Managed Home Screen app). After selecting the Managed Home Screen app, the home screen will show as configured in the app configuration policy.

As shown on the right, I only get the Settings app (Instellingen is the Dutch version of Settings) as app on my home screen. That’s exactly what I wanted. Also, I configured a blue theme and I removed nearly all the other options from the end-user.

Note: The experience might be different from the configuration via the dedicated device settings. The main difference might be that in some cases the end-user might receive a message to configure a home screen app. So make sure to carefully test the end-user experience, to see if it matches the expectations.

Screenshot_20190721-195426

More information

For more information about configuring the Managed Home Screen app, please refer to the documentation about Configure the Microsoft Managed Home Screen app for Android Enterprise .

Configure time zones via Windows 10 MDM

This week a blog post about a nice newly introduced policy setting in Windows 10, version 1903. That setting is available in the TimeLanguageSettings area, and can be used to set the time zone of the device. The TimeLanguageSettings area already existed before Windows 10, version 1903, but previously only contained a single setting for Windows 10 Mobile. Now it also contains a very useful setting related to non-Mobile versions of Windows 10. That setting will give some more control on the default time zone configuration of a device. In this post I’ll briefly go through the setting, followed by the configuration and the end-user experience.

Settings

Let’s start by having a look at the setting. The TimeLanguageSettings area is not a new node within the Policy CSP, but starting with Windows 10, version 1903, it does contain a nice new policy setting.  Below is an overview of that policy setting. Keep in mind that the complete node of this policy setting starts with ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/.

Policy Description

ConfigureTimeZone

Value: <time zone ID>

This policy can be used to specify the time zone that should be applied to the device.

Note: The time zone ID can be retrieved by using tzutil.exe. Simply use tzutil.exe /g on a device that already has the correct time zone configured.

Configuration

Now let’s continue by having a look at the configuration steps for the time zone. In other words, create a device configuration profile with the previously mentioned custom policy setting. I will use my own time zone as an example. The following three steps walk through the creation of that device configuration profile. After that simply assign the created profile to a user or device group.

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

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

  • Name: Time zone configuration
  • Description: (Optional)  
  • Platform: Select Windows 10 and later
  • Profile type: Select Custom
  • Settings: See step 3b
3b

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

  • Name: Set time zone
  • Description: (Optional)
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/TimeLanguageSettings/ConfigureTimeZone
  • Data type: Select String;
  • Value: W. Europe Standard Time

TZC-AddRow

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

End-user experience

Let’s end this post by looking at the end-user experience. Below is an example of a Windows 10 device running version 1903. In that example it shows the configuration of the time zone that should be configured. In my testing the end-user would still be able to adjust the time zone afterwards.

TZC-EndUserExperience01

As the end-user was still able to adjust the configuration afterwards, I wanted to be sure that the configuration was actually applied. To do that I also looked at the MDM Diagnostics Report. That report, which is shown below, clearly shows that the policy setting is configured,

TZC-EndUserExperience02

Besides that report, the Event Viewer will also provide the information about the time zone change.

  • The Admin log in Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Proivder shows event id 814 with the message MDM PolicyManager: Set policy string, Policy: (ConfigureTimeZone), Area: (TimeLanguageSettings), EnrollmentID requesting merge: (A77EC83D-AFD9-4949-AE0C-69CD6784C83F), Current User: (Device), String: (W. Europe Standard Time), Enrollment Type: (0x6), Scope: (0x0).
  • The System log shows event id 22 with the message The time zone bias has changed to -120 from 420 followed by event id 1 with the message The system time has changed to ‎2019‎-‎07‎-‎11T06:26:15.574273500Z from ‎2019‎-‎07‎-‎11T06:26:15.574273500Z. Change Reason: System time adjusted to the new time zone.

More information

For more information about the available time zone settings in the Policy CSP, please refer to the documentation about Policy CSP – TimeLanguageSettings.

Quick tip: Assign scope tags to devices by using security groups

This week is also a relatively short blog post. However, this week is about a recently introduced feature in Microsoft Intune. That feature is the ability assign a scope tag to all devices in a specific security group. Like last week it’s a relatively simple feature, but also like last week that simple feature makes life a lot easier. A few months ago I did a post about adding scope tags to devices. In that time it was still a manual action per device, which could be automated via PowerShell. In this post I’ll show how that this configuration can now be achieved by using a security group and what the result of that configuration is.

Configuration

Now let’s start by having a look at the steps to configure the automatic assignment of scope tags to all devices in a specific security group. The following 5 simple steps walk through the configuration of that assignment.

1 Open the Azure portal and navigate to Microsoft Intune > Roles > Scope (Tags) to open the Intune roles – Scope (Tags) blade;
2

On the Intune roles – Scope (Tags) blade, select Create to open the Create Scope Tag blade;

Note: When existing Scope tags are available, simply select the existing Scope tag to open the Edit <ScopeTagName> blade. The step next step will be pretty similar.

3 On the Create Scope Tag blade, provide a valid Name for the scope tag and select Assign scope tag to all devices in selected groups to open the Select groups blade;
MSI-CreateScopeTag01
4 On the Select groups blade, select the required security group and click Select to return to the Create Scope Tag blade;
MSI-CreateScopeTag02
5 Back on the Create Scope Tag blade, click Create to create the Scope tag;

Result

Let’s end this post by having a quick look at the result of the mentioned configuration. Let’s do that by having a look at the Properties of a device. Initially the scope tag configuration had to be done manually in the Properties of a device (or by using a script). Now the scope tag configuration will automatically be populated based on the devices in the selected security groups in the scope tag configuration (see below). When the device will be removed from the security group, the scope will also be automatically removed.

MSI-ScopeTagResult

Note: At this moment the scope tags in the Properties of a device are not read-only. The administrator is still able to manually remove a scope tag. Even when that scope tag was added via a security group. It is strongly recommended not to do this, as, in my experience, it will break the automatic behavior for that scope tag. In the future this configuration will become read-only.

More information

For more information about using scope tags, refer to this article about using role-based access control (RBAC) and scope tags for distributed IT.

Quick tip: Configure primary device via Software Center

This week a relatively short blog post about a recently introduced feature in Configuration Manager, version 1902. That feature is the option for the user to select a device as a primary device, by using Software Center. Previously the Application Catalog was still required to provide users with that specific option. That was also practically the only reason to still use the Application Catalog. From that perspective, this also provides a clear path for further simplifying the Configuration Manager hierarchy. In this post I’ll show how to enable the option for the user to configure a primary device via Software Center, followed by the end-user experience.

Configuration

Now let’s have a look at the configuration that enables the option for the user to configure a device as a primary device, by using Software Center. That configuration can be achieved by using Client Settings. The 3 steps below show how to enable this option for the users.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Client Settings;
2 Now either open/create a new Custom Client User Settings and select the Software Center section, or open open the Default Client Settings and select the User Device Affinity section;
3

SCPU-UserSettingsIn the User Device Affinity section, select Yes with Allow user to define their primary devices and click OK;

Note: When using the Default Client Settings this setting is available in the separate section of User Settings. When using Custom Client User Settings this setting is the only available setting. Also, when using Custom Client User Settings, make sure to deploy the Client Settings to a user collection.

Note: Theoretically, when Automatically configure user device affinity from usage data is set to No, the administrator must still approve the affinity request. However, my experience is that the primary user configuration is immediately processed.

End-user experience

Let’s end this post by having a quick look at the end-user experience. When the user now opens Software Center and navigates to the Options section, the user will find a new checkbox named I regularly use this computer to do my work. When that checkbox is selected, the user will be marked as the primary user of that specific device.

SCPU-UserExperience

More information

For more information about lettings users create their own device affinity, refer to this article about User device affinity (section Let users create their own device affinities).

Microsoft MVP 2019-2020

Yeah! A few hours ago I received that great email that I’m awarded with the 2019-2020 Microsoft MVP Award for my contributions in the Enterprise Mobility technical communities! That’s number 5!

MVP2019-2020

To me this is always worth a small post on my blog. Not just because I’m very honored, very proud and very exited of receiving my fifth award in a row, but maybe even more because I just need to let everyone know that it’s made possible by my great family. Without their support, my blog wouldn’t exist! Without their support I wouldn’t be able to contribute the way I am! Like every year, a really big thank you to my awesome wife and our super kids for giving met time to do my “thing”.

Me and my family are ready for another community driven year!

Windows Autopilot white glove service

This week is about Windows Autopilot. More specifically, the Windows Autopilot white glove service. The Windows Autopilot white glove service will enable organizations to pre-provision Windows 10 devices to make sure that end-users get their device faster to a fully provisioned state. In this post I’ll start with a short introduction about the Windows Autopilot white glove service, followed by the steps to enable the white glove service in Windows Autopilot. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Windows Autopilot white glove service (also known as Windows Autopilot for white glove deployment). This process is designed to get the user faster up-and-running. That is achieved by splitting the provisioning process (as shown below). The starting point of the Windows Autopilot for white glove deployment is the same as any other Windows Autopilot deployment, it starts with a device that is provided by the OEM (imaged and accommodated with drivers). The second step is what makes this the Windows Autopilot for white glove deployment, it enables an organization to pre-provision device apps, device settings, device policies and user apps (of the assigned user) on the device. This can be achieved by an OEM, partner or the IT organization itself. That also enables the faster user experience, as, once the user logs on, only user settings and user policies are still required.

WhiteGlove-Process

Before looking at the configuration, let’s go through a few important requirements and limitations of the Windows Autopilot for white glove deployment:

  • The device must run Windows 10, version 1903 or later;
  • Only user-driven scenarios, supporting both, Azure AD join and hybrid Azure AD join;
  • Must be a physical devices that support TPM 2.0 and device attestation (virtual machines are not supported);
  • The device must have a ethernet connectivity (Wi-Fi connectivity is not supported).

Configuration

Let’s continue by looking at the actual configuration. As the configuration of a Windows Autopilot deployment profile now contains a new look-and-feel, I thought it would be good to show screenshots of that new experience. The following 4 steps walk through the creation of a Windows Autopilot deployment profile that allows white glove.

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

On the Create profile blade, on the Basics section, provide the following information and click Next;

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

WA-WG-CreateProfile-Basics

4b

On the Create profile blade, on the Out-of-box experience (OOBE) section, provide the following information and click Next.

  • Deployment mode: Select User-Driven, as that deployment mode provides the functionality that is
    needed for this post;

  • Join to Azure AD as: Select Azure AD joined to join the device to Azure AD during the Windows Autopilot user-driven experience;
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot user-driven experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot user-driven experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot user-driven experience;
  • User account type: Select Administrator to only make any user on the device an administrative user;
  • Allow White Glove OOBE: Select Yes, as that enables the functionality that is needed for this post;
  • Apply computer name template: Create a computer name, according to the configured template, for devices at initial startup;
WA-WG-CreateProfile-OOBE
4c On the Create profile blade, on the Scope tags section, click Next;
WA-WG-CreateProfile-Scope
4d On the Create profile blade, on the Assignments section, add an assignment and click Next;
WA-WG-CreateProfile-Assignment
4e On the Create profile blade, on the Review + create section, click Create;
WA-WG-CreateProfile-Review

Administrator experience

Now let’s end this post by having a look at the administrator experience. More specifically the experience of the IT person performing the Windows Autopilot white glove deployment. Below on the first row is are the screens that the administrator has to go through, after pressing the Windows key 5 times on the initial OOBE screen. First the administrator has to select the Windows Autopilot provisioning option and click Continue, followed by confirming the device information and clicking Provision. The QR-code contains the identifier of the device and can be used to make some configuration changes.

After starting the process, it will either fail or succeed. Like with everything else. The reason I specifically mention it, is because the result is clearly shown by the background color. Below on the second row, are screenshots of a failed and succeeded Windows Autopilot white glove deployment. To make creating screenshots easy, I simulated both scenarios on a VM (see the error on the red screenshot and the no found messages in the green screenshot). Simulated, because a VM is not supported and will not work. On a physical device those screenshots will also provide a QR-code. As shown below, after a failure the administrator can choose to Retry, Reset and View diagnostics and after a success the administrator can Reseal the device. Resealing the device will make sure that the end-user will receive the expected OOBE.

WA-WG-01 WA-WG-02
WA-WG-Error WA-WG-Success

More information

For more information about enrolling Windows devices by using the Windows Autopilot white glove service, please refer to the documentation named Windows Autopilot for white glove deployment.

Android Enterprise fully managed devices and conditional access

This week is all about Android Enterprise fully managed devices. More specifically, the recently introduced functionality to use Android Enterprise fully managed devices in combination with conditional access. To support this functionality Microsoft introduced a new app, named Microsoft Intune app, and a new profile type for device compliancy policies for the Android Enterprise platform. Together these 2 features enable Android Enterprise fully managed devices to be registered as compliant device and to successfully work with conditional access. In this post I’ll provide some information about the Microsoft Intune app and I’ll show how to configure that app, followed by some information about the compliance policy for device owner scenarios and how to configure that policy. I’ll end this post by showing the end-user experience.

Keep in mind that Android Enterprise fully managed devices is still preview functionality. There are still scenarios that will not fully work at this moment. One of those scenarios is related to app protection policies. I specifically mention that scenario, as it can conflict with the scenario in this post. Apps with app protection policies assigned, will still prompt for the Company Portal app.

Microsoft Intune app

The first part in using Android Enterprise fully managed devices in combination with conditional access is the Microsoft Intune app. The Microsoft Intune app is a new modern and light-weight app that will enable the Company Portal app experiences for end-users on fully managed devices. That includes managing compliance for their device. Keep in mind that the Microsoft Intune app is only for the fully managed device scenario. As Android Enterprise fully managed devices require the Managed Google Play Store, the following 4 steps walk through the process of adding the Microsoft Intune app by using the Managed Google Play Store. After that the Microsoft Intune app can be assigned as any other app.

Keep in mind that after the May 2019 service roll out of Microsoft Intune, the Microsoft Intune app will automatically be added to the Intune admin console after connecting the tenant to managed Google Play.

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 MIapp-AddAppOn 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 Microsoft Intune app;
MIapp-SearchApp
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MIapp-ApproveApp
3d

MIapp-ApproveAppDB01On 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

MIapp-ApproveAppDB02On 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;
MIapp-ApproveAppOK
4 Back on the Add app blade, click Sync;

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

Compliance policy for device owner

The second part in using Android Enterprise fully managed devices in combination with conditional access is the compliance policies. Since recently it’s possible to create compliance policies for fully managed devices. The list of available compliance settings is smaller than other platforms. The main reason for that is because those settings are only applicable to fully managed devices. And fully managed devices are, as the name already implies, fully managed. In other words, fully managed devices already follow strict configuration policies. The following 5 steps walk through the process of creating a device compliance policy for Android Enterprise fully managed devices. After configuring the device compliance policy assign it to a user group like any other device compliance policy.

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

AEfmd-CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Android Enterprise;
  • Profile type: Device owner
  • Settings: See step 3b and 3c;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

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

3b

AEfmd-DevicePropertiesOn the Device owner blade, select Device Properties to open the Device Properties blade. On the Device Properties blade, configure the required device properties and click OK to return to the Device owner blade;

3c AEfmd-SystemSecurityBack on the Device owner blade, select System Security to open the System Security blade. On the System Security blade, configure the required system security settings and click OK to return to the Device owner blade;
4 Back on the Device owner blade, click OK to return to the Create Policy;
5 Back on the Create Policy blade, click Create to create the policy.

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

End-user experience

Now let’s end this post by looking at the end-user experience. Below, from left to right, is an overview of the different steps in the Microsoft Intune app to get a device from a noncompliant state to a compliant state. When the user has a noncompliant device state, the user can start the process by clicking on “You need to update settings on this device”. That will bring the user to the screen to setup access to resources. On that screen the user can simply continue. The next screen will show the user the settings that need to be updated and by clicking on a setting the user will receive information to resolve the issue. Once all the issues are resolved, the device state will switch to compliant.

AEfmd-Experience01 AEfmd-Experience02 AEfmd-Experience03
AEfmd-Experience04 AEfmd-Experience05

Note: Keep in mind that this is still preview functionality. When using app protection policies, the protected apps will still prompt for the installation of the Intune Company Portal app.

More information

For more information regarding the Microsoft Intune app and Android Enterprise fully managed devices, please refer to the following articles:

Working with Win32 app dependencies

After a couple of weeks with distractions, this week I’m stepping away from conditional access. This week is all about Win32 app management capabilities. More specifically, about Win32 app dependencies. About half a year ago, when Win32 app management capabilities were introduced, I did my first post about those capabilities. That post is still being read really good, so I thought this would be a good time for a nice addition to that post. In this post I’ll start with a shorting introduction about Win32 app dependencies, followed by the configuration steps for Win32 apps and specifically for Win32 app dependencies. I’ll end this post by showing the experience for the end-user and the administrator.

Introduction

Let’s start with a short introduction about reason for using Win32 apps and more specifically about using the Win32 app dependencies. Slowly there are coming more and more reason to look at Win32 apps as a serious alternative to using single-file MSI via MDM. An important reason for that is that Windows 10, version 1709 and later, will download Win32 app content by using delivery optimization. Other reasons are the Win32 app configuration options for requirements and detection rules. That will make the Win32 app really flexible. To make the Win32 app even more flexible, and even more comparable to the ConfigMgr app model, it’s now also possible to configure dependencies between Win32 apps.

Scenario

Before looking at the actual configuration steps, let’s first describe the example scenario that I’ll use to show the Win32 app dependencies feature. As an example scenario, I’m using PolicyPak. I won’t go into details about the functionalities of PolicyPak, that information can be found here. The reason that I’m using it as an example scenario, is simply because the installation contains three steps: install the license file, install the client-side extension and install any setting file. All of these are available as MSI and the mentioned order (see also the picture below) provides the best result. In other words, ideal for showing the Win32 app dependencies feature.

PolicyPak-dependency-overview

Note: In my testing, PolicyPak will work just perfectly fine if you don’t take into account dependencies, but this is an ideal scenario to ensure that all policies delivered from PolicyPak always get applied the first time

Configuration

Now let’s start with the configuration steps. I’ll do that by first quickly showing the steps to wrap a Win32 app and the steps to configure a Win32 app. For more details about that, please refer to my previous post about Win32 apps. After that, I’ll show the detailed steps for configuring Win32 app dependencies.

Prepare Win32 app

The first step is to quickly go through the steps to prepare the Win32 apps by using the Microsoft Intune Win32 App Packaging Tool. Wrap the Win32 apps. The packaging tool wraps the application installation files into the .intunewin format. Also, the packaging tool detects the parameters required by Intune to determine the application installation state.  The following five steps walk through wrapping the different PolicyPak MSIs.

1 Download the Microsoft Intune Win32 App Packaging Tool. In my example to C:\Temp;
2 Create a folder per PolicyPak MSI. In my example C:\Temp\[PolicyPakMSI];
3 Open a Command Prompt as Administrator and navigate to the location of IntuneWinAppUtil.exe. In my example that means cd \Temp;
4 Run IntuneWinAppUtil.exe and provide the following information, when requested

  • Please specify the source folder: C:\Temp\[PolicyPakMSI];
  • Please specify the setup file: [PolicyPakMSI].msi;
  • Please specify the output folder: C:\Temp
5 Once the wrapping is done. The message Done!!! will be shown. In my example a file named [PolicyPakMSI].intunewin will be created in C:\Temp.

Note: The mentioned steps should be performed per PolicyPak MSI.

Configure Win32 app

The next step is to quickly look at the configuration steps, within Microsoft Intune, to configure the Win32 apps. The following 17 steps walk through all the steps to configure the Win32 apps, by using the .intunewin files.

1 Open the Azure portal and navigate to 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;
3 On the Add app blade, select Windows app (Win32) – preview to show the configuration options and select App package file to open the App package file blade.
4 On the App package file blade, select the created [PolicyPakMSI].intunewin as App package file and click OK to return to the Add app blade;
5 Back on the Add app blade, select App information to open the App information blade;
6 On the App information blade, provide at least the following information and click OK to return to the Add app blade;

  • Name: [PolicyPakMSI] is pre-provisioned as name of the app;
  • Description: Provide a description of the app;
  • Publisher: Provide the publisher of the app;

Note: The remaining information regarding the Information URL, the Privacy URL, the Developer, the Owner, the Notes and the Logo is optional.

7 Back on the Add app blade, select Program to open the Program blade;
8 On the Program blade, verify the Install command and the Uninstall command and click OK to return to the Add app blade;
9 Back on the Add app blade, select Requirements to open the Requirements blade;
10 On the Requirements blade, provide at least the following information and click OK to return to the Add app blade;

  • Operating system architecture: Select the applicable platforms;
  • Minimum operating system: Select a minimum operating system version;
11 Back on the Add app blade, select Detection rules to open the Detection rules blade;
12 On the Detection rules blade, select Manually configure detection rules and click Add to open the Detection rule blade.
13 On the Detection rule blade, select MSI as Rule type, verify the pre-provisioned MSI product code and click OK to return to the Detection rules blade;
14 Back on the Detection rules blade, click OK to return to the Add app blade;
15 Back on the Add app blade, select Return codes to open the Return codes blade;
16 On the Return codes blade, verify the preconfigured return codes and click OK to return to the Add app blade;
17 Back on the Add app blade, click Add to actually add app.

Note: The mentioned steps should be performed per PolicyPak .intunewin file.

Configure Win32 app dependency

Now the main configuration of this post, the configuration of the dependency between Win32 apps. The created Win32 apps need to be installed in the order as described (and shown) during the explanation of the scenario. The following six steps walk through the Win32 app dependency configuration. In my scenario, these steps need to be performed for he PolicyPak settings MSI, to create a dependency between the PolicyPak settings MSI and the PolicyPak client-side extensions MSI, and for the PolicyPak client-side extensions MSI, to create a dependency between the PolicyPak client-side extensions MSI and the PolicyPak license MSI. After configuring the Win32 app dependencues, make sure to assign the PolicyPak settings MSI to a user group.

1 Open the Azure portal and navigate to Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, select the just created [PolicyPakMSI] app to open the [PolicyPakMSI] app blade;
3 On the [PolicyPakMSI] app blade, select Dependencies to open the [PolicyPakMSI] app – Dependencies blade;
4 On the [PolicyPakMSI] app – Dependencies blade, click Add to open the Add dependency blade;
5 On the Add dependency blade, select the [PolicyPakMSI] app and click Select to return to the [PolicyPakMSI] app – Dependencies blade;
Win32App-AddDependency
6 Back on the [PolicyPakMSI] app – Dependencies blade, select Yes with AUTOMATICALLY INSTALL and click Save.
Win32App-AddDependency-Save

Note: Keep in mind that these steps need to be performed for both dependencies.

Experience

Now let’s end this post by looking at the end-user experience and the administrator experience.

End-user experience

The first experience to look at is the end-user experience. Below, from left to right, is the end-user experience. As I configured the dependencies to automatically install, the dependencies will install before the actual assigned PolicyPak settings MSI. First the end-user will receive the message that PolicyPak license MSI will install as a part of the PolicyPak settings MSI installation. After a successful installation, the end-user will receive the message that the PolicyPak client-side extensions MSI will install as part of the PolicyPak settings MSI installation. And once that installation is successful, the PolicyPak settings MSI will install.

PP-Example01 PP-Example02 PP-Example03

Administrator experience

Win32App-AdministratorExperienceThe second experience to look at is the administrator experience. That is not always the most exiting experience to look at, but in this case it does add something good and new to look at. For the administrator, Microsoft Intune provides the Dependency viewer. The Dependency viewer can be found by selecting an app and navigating to Monitor > Dependency viewer. The Dependency viewer shows the the dependencies of the selected app and the dependencies of the dependencies (all the way down). The Dependency viewer does not show the apps that depend on the app. So, to explain that with the example of this post, it would be like this:

  • PolicyPak settings MSI: The PolicyPak settings MSI would show that it has a dependency on the PolicyPak client-side extensions MSI and that the PolicyPak client-side extensions MSI has a dependency on the PolicyPak MDM license MSI (as shown on the right);
  • PolicyPak client-side extensions MSI: The PolicyPak client-side extensions MSI would show that it has a dependency on the PolicyPak MDM license MSI;
  • PolicyPak MDM license MSI: The PolicyPak MDM license MSI would show no dependencies.

More information

For more information regarding Win32 apps and Win32 app dependencies, please refer to the following article: