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:

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:

Require an Internet connection during device setup

This week I’m going to look at a well hidden configuration option that is recently introduced and can be really useful in specific scenarios. That configuration option is to require an Internet connection during the device setup. Requiring an Internet connection during device setup can be useful when trying to prevent users from resetting the device (either accidently or on purpose) and configuring it without an Internet connection, as configuring a device without Internet connectivity would enable a user to configure the device with a local user and without enrollment. In this blog post, I’ll start with a short introduction about why this configuration option would be useful and what the options are with this configuration option. Followed by the configuration steps and the end-user experience.

Introduction

Configuring a device without Internet connectivity would enable a user to configure the device with a local user and without an enrollment to Microsoft Intune (and Azure AD). That’s often what organizations want to prevent, as it disconnects a device from the organization. Minor detail, this configuration option must be configured once. Of course it would be great if this configuration option could be a Windows default, or available via the Windows Autopilot configuration. However, to my understanding this is currently not possible due to legal requirements. At this moment it’s simply legally not allowed to require an Internet connection on a device during the initial setup. Having said that, as this setting is configured via the TenantLockdown CSP, I can imagine that, in a Windows Autopilot for existing devices scenario, this can be configured as a Windows default, via PowerShell, by using the WMI Bridge Provider.

Configuration

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

  • The device must run Windows 10, version 1809 or later;
  • The device must be configured once before the setting is applicable;

Now let’s continue by looking at the required configuration. The following four steps walk through the steps to get create a new device configuration profile and the specific configuration option. That device configuration profile can be assigned to an Azure AD 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;
3a On the Create profile blade, provide the following information and click Create;

  • 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 Device restrictions;
  • Settings: See 3b;
3b On the Device restrictions blade, select General to open the General blade. On the General blade, select Require with Require users to connect to network during device setup and click OK to return to the Device restrictions blade. On the Device restrictions blade, click OK;
OOBE-Configure-Network

Note: This setting must be configured before it’s applicable. In other words, it’s not applicable during the initial out-of-box experience.

End-user experience

Let’s end this post by looking at the end-user experience. Once the configuration is in place and a reset is performed on the device, there will be an additional check during the device setup. When the device is not connected to the Internet, the end-user will receive a message as shown below. It requires the user to connect to the Internet. The user will not be able to continue without that connection. Once the user is connected to the Internet, the page below will show a Next button that can be used to continue with the device setup.

OOBE-Connect-Network

More information

For more information regarding the device configuration options and the TenantLockdown CSP, please refer to the following articles:

Windows Autopilot self-deploying mode

This week a new blog post about Windows Autopilot. More specifically, Windows Autopilot self-deploying mode. Autopilot self-deploying mode is really useful for devices that are function specific, like for example kiosk devices. The biggest benefit is that a device with a wired network connection (with Internet) can be completely configured without any user interaction. Simply connect the device to the wired network and power it on! Real zero touch provisioning! In this post I’ll provide the configuration steps to create that experience, followed by some known errors and the end-user experience.

Configuration

Let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device can only be Azure AD joined (Active Directory join is not supported);
  • The device must be a physical device with TPM 2.0 (virtual machine is not supported);

Now let’s continue by looking at the available configuration options. In this case I’ll look at the different available configurations options and the related impact of those configuration options. The following four steps walk through the steps to get create a new Windows Autopilot self-deploying profile (including the available settings). That deployment profile can be assigned to an Azure AD group that contains 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

WA-SD-CreateProfileOn 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 Self-Deploying (preview), as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Azure AD joined is selected by default and grayed-out, as it’s the only configuration option supported for Windows Autopilot self-deploying devices;
  • Out-of-box experience (OOBE): See 4b.

Note: The Self-Deploying (preview) deployment mode, defines the available Azure AD settings and the available out-of-box experience (OOBE) settings.

4b

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

  • Language (Region): Select the Language that should be automatically configured during the Windows Autopilot self-deploying experience. This configuration will only be performed when the device is on a wired network connection (with Internet);
  • Automatically configure keyboard: Select Yes to automatically configure the keyboard based on the selected Language. This setting is only available when a Language is configured and this configuration will only be performed when the device is on a wired network connection (with Internet);
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot self-deploying experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot self-deploying experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot self-deploying experience;
  • User account type: Select Standard to only make any user on the device a standard user. With the exception of global administrators and company administrators;
  • Apply computer name template (Windows Insider Only): Create a computer name, according to the configured template, for devices at initial startup;
WA-SD-OOBE

Note: The Autopilot settings can only be downloaded when a network connection is in place. That’s the reason why a wired network connection should be in place. When a wired network connection is not available, it’s required to configure the region, the keyboard and a Wi-Fi.

Known errors

During the testing of Windows Autopilot self-deploying, I ran into multiple errors. More information about an error can always be found in the Event Viewer, at Application and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider > AutoPilot (thank you for the reminder Sandy!). The errors that I’ve seen on screen are documented and explained in the table below. If you’ve seen errors that are not on this list, let me know and I’ll add them.


Error Description
0x800705B4 This error means that the device is either a virtual machine, or does not have TPM 2.0, and is not capable of running Autopilot self-deploying.
0x801c03ea This error means that the device is TPM 2.0 capable, but that the TPM still needs to be upgraded from 1.2 to 2.0.
0xc1036501 This error means that the device cannot do an automatic MDM enrollment, because there are multiple MDM configurations in Azure AD.

End-user experience

As always, let’s end this post by having a look at the end-user experience. The end-user experience will provide a welcome message (see below) after receiving the Autopilot deployment profile and an automatic restart. An easy differentiation between the Autopilot user-driven experience and the Autopilot self-deploying experience, besides the interaction, is the logo that’s used. At this moment the Autopilot user-driven experience uses the square logo of the Azure AD company branding and the Autopilot self-deploying experience uses the banner logo of the Azure AD company branding.

20181104_165048

Note: From and administrator perspective, an Autopilot self-deploying device can be easily recognized by the Management name of the device. It contains a GUID instead of a username.

More information

For more information about enrolling Windows devices by using Windows Autopilot self-deploying mode, please refer to the documentation named Windows Autopilot Self-Deploying mode.

Join us at Experts Live Europe in Prague

b-B6v-rUA bit less than two weeks from now, October 25-26, Experts Live Europe will be in Prague. Together with my finest colleague, Arjan Vroege, I will deliver two sessions! And we hope to see you there!

Experts Live Europe is a Microsoft community conference with a focus on Microsoft cloud, datacenter and workplace management. During this conference, top experts from around the world present discussion panels, ask-the-experts sessions and breakout sessions and cover the latest products, technologies and solutions.

About our sessions

The maybe-not-that-sexy version of modern management – A true story –

In this session, we will take you into the real world of modern management. Modern management is a great buzzword and by now we all know the lovely story of modern management. We all know how it should work, but we often lack the real-world examples of organizations using modern management. During this session, we will show you how we internally deployed Windows 10 with Azure AD join and Intune management for over 10k devices. What choices did we make? Which challenges did we run into? Did we close all the gaps? We’ll try to answer these question. To conclude will also look at the available options right now and how they could have helped us. We will also have a couple of cool demos. To provide a sneak preview, here is a small list with subjects that will be part of our session: Win32 apps, MSIX and Windows AutoPilot.

Thursday Friday 2:40 PM – 3.40 PM

Create your ultimate hybrid workplace, what options do you have?

During this session we will take you into the world of the hybrid workplace. The modern workplace is a great story, for cloud only organizations, but the reality is often that there are a lot of components still on-premises. During this session we will touch the different delegate subjects from identity until apps and from management until connectivity. That means, a lot of ground to cover and a lot of choices to be made. Besides that we will have a couple of cool demos, here is a small list with a sneak preview of subjects that will be part of our session:  Pass-through authentication, Co-management, Win32 apps, MSIX and Azure AD Application Proxy.

Friday 8:00 AM – 9:00 AM

Make sure that you don’t miss these sessions!

Assign a user to a Windows AutoPilot device

This blog post uses capabilities that are added in Windows 10, version 1809, which is currently still in preview.

This week a short blog about another relatively new Windows AutoPilot feature. This week is all about assigning a specific user to a specific Windows AutoPilot device. That enables an administrator to directly assign a user to a Windows AutoPilot device. Assigning a user to a Windows AutoPilot device will make sure that the username will be pre-filled during Windows setup. It also lets the administrator set a custom greeting name, which will also be added during the Windows setup. In this post I’ll show the actual configuration steps, followed by the end-user experience.

Configuration

Before starting with the actual configuration steps, it’s important to name a few prerequisites.

  • Azure AD company branding is configured;
  • Device is running Windows 10, version 1809 or later;
  • User is Microsoft Intune licensed

When the prerequisites are in place, it’s time to start looking at the actual configuration. The following five steps walk through assigning a user to a Windows AutoPilot device.

1 Open the Azure portal and navigate to Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, click Devices to open the Windows AutoPilot devices blade;
3 On the Windows AutoPilot devices blade, select the specific device (make sure to check the box) and click Assign user to open the Select user blade;
AP-AssignUser
4 On the Select user blade, select the specific user and click Select, which will open the Properties blade of the device;
5

AP-UserFriiendlyNameOn Properties blade of the device, provide the User Friendly Name and click OK to return to the Windows AutoPilot devices blade.

Note: This will provide a message like in this case “Awesome dude has ben successfully assigned to 3008-9109-1000-6969-987…

End-user experience

Now let’s end this post by looking at the end-user experience when using a user-driven deployment. After configuring the location and the keyboard, the user will get a personal welcome message. The message includes the configured custom user friendly name and the username will be preconfigured (as shown below). The user only needs to provide a password and click Next.

AP-UserExperience

Note: This experience does not work when used in combination with ADFS.

More information

For more information about assigning a user to a Windows AutoPilot device, please refer to the documentation Enroll Windows devices by using the Windows AutoPilot | Assign a user to a specific Autopilot device.

Block access to company resources if certain apps are installed

This week is all about device compliance. More specifically, this week is all about the just introduced capability to block access to company resources if certain apps are installed. This enables organizations to truly blacklist specific apps that are not allowed when using devices to access company resources. In this case it’s not about the apps used for accessing the company resources, but it’s really about the apps installed on the device. In this post I’ll provide the configuration steps, by using OWA for iPad as an example, followed by the end-user experience.

Configuration

Before starting with the actual configuration, it’s important to get the bundle ID of the iOS app that cannot be installed. These steps are very clearly documented here. I will use OWA for iPad as an example, which has the following bundle ID: com.microsoft.exchange.ipad.

Now let’s continue by having a look at the configuration steps. The following five steps walk through the creation of a device compliance policy with at least the configuration of OWA for iPad as a restricted app. Within a device compliance policy a restricted app is what was earlier described, in this post, as blacklisted apps. After the creation of the device compliance policy, simply assign it to the applicable user group.

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

On the Create Policy blade, provide a Name, select iOS with Platform and select Settings to open the iOS compliance policy blade;

Note: This is currently an iOS only configuration. Android is expected a bit later.

4 On the iOS compliance policy blade, select System Security to open the System Security blade;
5

On the System Security blade, navigate to the Device Security section, provide the App name, the App Bundle ID and click Add, followed by and clicking OK, OK and Create.

Note: The provided App name will be mentioned in the potential non-compliance message to the end-user and the App Bundle ID is in this example the id of the OWA for iPad app.

MSI-RestrictApp

Note: To complete this 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 with the end-user experience. Let’s do that by looking at the end-user experience on an iOS device with OWA for iPad installed. On the left is the default message that is displayed to the end-user when trying to access company data on a non-compliant device. On the right is the message that the end-user will receive in the Company Portal app related to the compliance state of the device. In this case it will provide the end-user with a list of disallowed apps that should be uninstalled. The list shows the name of the app, as provided in the compliance policy.

IMG_0143 IMG_0144

More information

For more information about blocking access if certain apps are installed, refer to the documentation about adding a device compliance policy for iOS devices in Intune.

Remote Windows AutoPilot Reset

This blog post uses remote Windows AutoPilot Reset, to remotely trigger a device reset on Windows 10 devices. This capability is added in Windows 10, Insider Preview Build 17672 and later.

This week it’s all about (remote) Windows AutoPilot Reset. That might sounds like something really cool and really new, but it’s actually not that new. Remember my post about Windows Automatic Redeployment? Well, that functionality still exists, but with the addition to trigger the redeployment (read: reset) remotely via Microsoft Intune, this feature is rebranded to (remote) Windows AutoPilot Reset. That means that Windows Autopilot Reset removes personal files, apps, and settings, by resetting Windows 10 while still maintaining the Azure AD Join and the Microsoft Intune enrollment. In this post I’ll show the required configuration to enable Windows AutoPilot Reset, followed by the steps to trigger a remote Windows AutoPilot Reset. I’ll end this post by looking at the end-user experience.

Configure automatic redeployment

Before actually looking at the required configuration, it’s good to keep in mind that WinRE must be enabled on the device to use Windows AutoPilot Reset. Now let’s continue with the configuration to enable Windows AutoPilot Reset (previously know as Windows Automatic Redeployment). The previous time I configured it by using a custom OMA-URI, while the configuration already became available through the UI. So this time I’ll simply show the UI-setting. The following three steps walk through the creation of a new device configuration profile, including configuring the required setting. After that simply assign the created profile to a user or device group.

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

On the Create profile blade, provide the following information and click Create.

  • 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 Device restrictions;
  • Settings: See step 3b;
3b On the Device restrictions blade, select General, select Allow with Automatic Redeployment and click OK and OK;
Intune-Automatic-Redeployment

Note: Remember that it’s not a requirement to create this as a separate new profile. This setting can also be added to an existing device restrictions profile.

Trigger remote reset

Based on my previous post about Windows Automatic Redeployment, I showed how to trigger the reset locally from the device. Now let’s continue this post by looking at how to actually trigger the remote reset by using Microsoft Intune. The following three steps walk through the actions.

1 Open the Azure portal and navigate to Intune > Devices > All devices to open the Devices – All devices blade;
2 Intune-AutoPilot-ResetOn the Devices – All devices blade, select the target device and click More > AutoPilot Reset (preview);
3 On the AutoPilot Reset (preview) – [computer name] confirmation box, click Yes;
Intune-AutoPilot-Reset-Confirmation

Note: After confirming the action will show as Action automaticRedeployment with the Status Pending. Once the action is completed the status will change to Completed.

End-user experience

Let’s end this post by looking at the end-user experience. Once the remote Windows AutoPilot is triggered the end-user will receive a notification message, as shown below. That message will tell the end-user that the system needs to restart for automatic redeployment and that the restart is scheduled in 45 minutes.

Intune-AutoPilot-Reset-Experience

More information

For more information about remote Windows AutoPilot Reset, please refer to the documentation about Reset devices with AutoPilot Reset.

Automatically assign Windows AutoPilot deployment profile to Windows AutoPilot devices

This week another (short) blog post about Windows AutoPilot. More specifically, about automatically assigning a Windows AutoPilot deployment profile to Windows AutoPilot devices. That makes it a lot easier for administrators, as this prevents the administrators from potentially forgetting to assign the deployment profile to newly imported devices. Great improvement. Also, I have to say that this subject is documented pretty good, but it could be easier to find. This post is mainly for creating awareness regarding this subject. I’ll provide the options regarding to grouping Windows AutoPilot devices and I’ll show how those options can be used to create a dynamic group.

Options

Let’s start by having a look at the configuration options regarding the grouping of Windows AutoPilot devices. The imported Windows AutoPilot devices are pre-created in Azure AD and, during that creation process, a few values are automatically set for those devices. Below is an overview of those different values.

Value Devices Explanation
[ZTDId] All Windows AutoPilot devices A unique value assigned to all imported Windows AutoPilot devices
[OrderID]:{YourOrderId} All Windows AutoPilot devices with a specific order Id An optional Id that can be specified when importing Windows AutoPilot devices
[PurchaseOrderId]:{YourPurchaseOrderId} All Windows AutoPilot devices with a specific purchase order Id An Id that is set by the OEM when importing Windows AutoPilot devices

Those different values can be used to create dynamic device groups within Azure AD. Below is an overview of the required queries per grouping of Windows AutoPilot devices.

Devices Query
All Windows AutoPilot devices (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)
All Windows AutoPilot devices with a specific order Id (device.devicePhysicalIds -any _ -eq “[OrderID]:{YourOrderId}”)
All Windows AutoPilot devices with a specifc purchase order Id (device.devicePhysicalIds -any _ -eq “[PurchaseOrderId]:{YourPurchaseOrderId }”)

Note: These values can be seen by simply using Graph Explorer, querying https://graph.microsoft.com/v1.0/devices and looking for the physicalIds value.

Configuration

Let’s continue by having a look at how to use these different values and queries for actually grouping all Windows AutoPilot devices. The following 3 steps walk through the creation of a dynamic device group that can use the different queries mentioned earlier.

1 Open the Azure portal and navigate to Intune > Groups or navigate to Azure Active Directory > Groups to open the Groups – All groups blade;;
2 On the Groups – All groups blade, click New group to open the Group blade;
3a

AAD_DD_GroupOn the Group blade, provide the following information and click Create.

  • Group Type: Select Security;
  • Group name: Provide a valid name for the group;
  • Group description: (Optional) Provide a description for the group;
  • Membership type: Select Dynamic Device;
  • Dynamic device members: See step 3b;
3b

AAD_DD_RulesOn the Dynamic membership rules blade, select Advanced rule, provide one of the mentioned queries (depending on the type of AutoPilot devices selection) and click Add query;

Note: The example on the right is showing the query for all AutoPilot devices.

Once the dynamic device group is created it can used for assigning Windows AutoPilot deployment profiles. That enables the administrator to automatically assign a Windows AutoPilot deployment profile to all Windows AutoPilot devices.

Result

Let’s end this post by having a look at the results. Below, on the left, is a quick overview, via Microsoft Graph, about the device information of CLDCLN879139238. That shows the name of the device and the value related to all imported Windows AutoPilot devices. Below on the right is an overview of that same device, showing it as a member of the earlier created dynamic device group.

AAD_DD_Example2 AAD_DD_Example1

More information

For more information regarding the latest Windows AutoPilot features and the configuration steps, please refer to the following articles: