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:

Join us at Experts Live Netherlands in Den Bosch

EXPERTSLIVE.6015_email-signature_spreker_ENG_200x200A bit less than a week from now, June 6, Experts Live Netherlands will be in Den Bosch. Experts Live Netherlands is one of the biggest Microsoft community events, with over 1200 visitors. I’m proud to be part of the speaker lineup again. Together with my finest colleague, Arjan Vroege, I will deliver a session about moving to a modern managed workplace at your own pace! And we hope to see you there!

About our session

During our session we will discus (and show) how to migrate to a modern managed workplace at your own pace. As many organizations want to make the switch to a modern managed workplace, but are currently unable to make the complete switch. Often this is related to missing specific management features, like limited control over updates and missing rich app deployment features. The good news is that it’s not required to directly make the complete switch. This can be achieved in steps, by using Configuration Manager and Microsoft Intune. In this session we will present and show you how to use these tools in combination with Windows 10 to make a smooth transition.