Windows 10 enrollment methods

This week is all about Windows 10 enrollment methods. The different methods to enroll Windows 10 devices into Microsoft Intune. There are many different methods to enroll Windows 10 devices, which makes it easy to get lost. In this post I’ll provide an overview of these different enrollment methods, including the use case of the enrollment method and how to perform the enrollment. This post is definitely not a complete guide through the different enrollment methods. Its main purpose is to create awareness for the different enrollment methods and to describe the main characteristics of the enrollment methods.

The different enrollment methods

Now let’s discuss the different enrollment methods and their use cases. Before starting, it’s good to mention that I’m aware of the existence of the MDM only enrollment method. However, I don’t consider that as a valid option to enroll a device into Microsoft Intune, as that method doesn’t register the device in Azure AD. And that provides many challenges, for example with conditional access. When discussing the different enrollment methods, I’ll try to group those methods were possible and I’ll try to mention the differences.

Bring Your Own Device (BYOD)

Description: The Bring Your Own Device (BYOD) method enables the user to enroll a personal device into Microsoft Intune by using the Settings panel and adding a Work and School account. That action will trigger the flow to register the device in Azure AD and that will also automatically enroll the device into Microsoft Intune.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Keep in mind that within the auto-enrollment configuration, the administrator can also configure MAM enrollment. When the MDM and MAM enrollment is configured for a user, the MAM enrollment takes precedence for personal devices.

Example scenario: This can be useful for Bring Your Own Device (BYOD) scenarios. The device will be enrolled as a personal device.

Azure AD join (with auto enrollment)

Description: The Azure AD join method enables the user to enroll a corporate-owned device into Microsoft Intune, similar to enrolling a personal device – by using the Settings panel and adding a Work and School account – the user can also choose to join the device to Azure AD. That option will become available during the same configuration flow. The user has to specifically choose to join Azure AD during that flow (as shown in Figure 2). This same behavior can also be triggered during the Out-Of-the-Box-Experience (OOBE). That can be achieved by setting the device up for an organization. That will trigger the flow to Azure AD join the device.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1).

Example scenario: This can be useful for Choose Your Own Device (CYOD) scenarios. The device will be enrolled as a corporate-owned device.

Windows Autopilot

Description: The Windows Autopilot method enables users to easily enroll corporate-owned devices. Windows Autopilot can be used to automate the Azure AD Join and directly enroll corporate-owned devices into Microsoft Intune. This method simplifies the OOBE – as mentioned with the Azure AD join method – as it will automatically add the device to AD or Azure AD and directly enroll the device into Microsoft Intune.

Important requirements: This requires that the device should be added in Microsoft Intune as Windows Autopilot devices (as shown in Figure 5) and specific Windows Autopilot profiles should be created to control the behavior and the OOBE.

Example scenario: This is useful in scenarios when handing out devices to users without the need to build, maintain, and apply custom operating system images to the devices. The device will be enrolled as a corporate-owned device.

Device Enrollment Manager (DEM)

Description: The Device Enrollment Manager (DEM) method enables the administrator to enroll multiple corporate-owned devices. The DEM account is a special account with permissions to enroll and manage multiple (up to 1000) corporate-owned devices. That enables a bulk enrollment method for non-personal corporate-owned devices. The enrollment can be achieved by following any of the flows to configure an Azure AD join.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Besides that the Device Enrollment Manager (DEM) should be configured (as shown in Figure 3) and make sure to keep the maximum number of devices that the user account can add to Azure AD matches.

Example scenario: This can be useful in scenarios where the device is enrolled and prepared before handing it out to the user of the device. The device will be enrolled as a corporate-owned device.

Provisioning package

Description: The provisioning package method enables the administrator to bulk enroll corporate-owned devices. A provision package can be used to add devices in bulk to Azure AD and automatically enroll those devices into Microsoft Intune. That provisioning package can be created by using the Windows Configuration Designer (as shown in Figure 4) and can be applied to corporate-owned devices. Once the package is applied, it’s ready for Azure AD users to sign in.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Besides that make sure to keep the maximum number of devices that a user can add to Azure AD matches with the usage of the package.

Example scenario: This can be useful in scenarios where an authorized user joins large numbers of corporate-owned devices. The device will be enrolled as a corporate-owned device.

Co-management

Description: The co-management method enables administrators to automatically enroll corporate-owned devices. Co-management enables organizations to automatically enroll devices into Microsoft Intune. This requires the device to be managed with Configuration Manager and the enablement of co-management. Within the co-management configuration, the automatic enrollment in Microsoft Intune can be configured (as shown in Figure 6).

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1) and that the device is registered or joined to Azure AD (can be achieved via Client Settings).

Example scenario: This is useful in scenarios when the flexibility is still required to use the technology solution that works best for the organization. The device will be enrolled as a corporate-owned device.

Group Policy

Description: The Group Policy method enables administrators to automatically enroll corporate-owned devices. Group Policy enables organizations to automatically enroll devices into Microsoft Intune. The automatic enrollment is triggered by the Group Policy (as shown in Figure 7). That means that the device is always hybrid Azure AD joined.

Important requirements: This requires the device to registered in Azure AD.

Example scenario: This is useful in scenarios when mass-enrolling domain-joined devices.The device will be enrolled as a corporate-owned device.

An overview of the enrollment methods

Let’s end this post by providing short overview of the different enrollment methods and their most important characteristics that are mentioned in throughout this post. Those characteristics are the ownership registration of the device, the user affinity with the device and the user interaction with the device during the enrollment.

Enrollment methodOwnershipUser affinityUser interaction
Bring Your Own DevicePersonalYesYes
Azure AD joinCorporateYesYes
Windows AutopilotCorporateYesYes
Device Enrollment ManagerCorporateNoNo
Provisioning packageCorporateNoNo
Co-managementCorporateYesNo
Group PolicyCorporateYesNo

A couple of remarks with this table are that 1) Windows Autopilot contains multiple scenarios, including scenarios without user interaction and that 2) methods without user affinity provide challenges with conditional access.

More information

For more information about configuring Windows 10 enrollment methods, refer to the following docs:

Controlling Windows 10 feature updates

This week is all about controlling Windows 10 feature updates. A couple of months ago a new policy type was introduced to control Windows 10 feature updates. And even more recent, support for Windows Autopilot devices was added to that policy type. That latest addition was the trigger for this blog post. In this post I’ll start with a short introduction about the different options for controlling Windows 10 feature updates, followed by more details about the Windows 10 feature updates policy. I’ll end this post by looking at the configuration options.

Introducing the control options for Windows 10 feature updates

Now let’s with an introduction about the options to control Windows 10 feature updates by using Microsoft Intune. I’m deliberately naming it controlling – and not managing – as it’s more controlling the (pace of the) installation of Windows 10 feature updates. I see managing more as being in full control of the Windows 10 (feature) updates on a device. Via Microsoft Intune it’s possible to utilize Windows Update for Business to simplify the Windows 10 update management experience in general. Utilizing Windows Update for Business is focused more on controlling the Windows 10 updates cycle, instead of approving individual updates for (specific) devices. Controlling the Windows version and controlling the installation of the quality and security updates.

It’s also good to keep in mind that Microsoft Intune only stores the policy assignments and not the updates themselves. Windows 10 devices will access Windows Update directly for the updates itself. Within Microsoft Intune the following policy types are provided to control updates:

  • Windows 10 update rings: The Windows 10 update rings policy is a collection of settings that configures setting to control when Windows 10 updates get installed. This policy type already exists for a while and enables administrators to create update rings that specify how and when Windows 10 devices should be updated with feature and quality updates. As long as the latest update is installed, the Windows 10 devices are up to date.
  • Windows 10 feature updates: (Currently public preview) The Windows 10 feature updates policy brings devices to the specified Windows version and freezes the feature set on those devices until the administrator chooses to update them to a later Windows version. While the feature version remains static, devices can continue to install quality and security updates that are available for their feature version.

As the Windows 10 feature updates policy is a new feature, the remainder of this post will focus on that feature.

Introducing the Window 10 feature updates policy

A Windows 10 feature updates policy is a pretty simplistic policy – from a configuration perspective – to control the Windows 10 feature updates on a device. When a device receives a Windows 10 feature updates policy, the device will update to the Windows version that is configured in the policy. When a device is already running a later Windows version then the Windows version that is configured in the policy, that device remains on its current Windows version. The device will not downgrade to a previous Windows version.

During the period that the Windows 10 feature updates policy is assigned to the device, the device will basically freeze on the configured Windows version (unless – as previously mentioned – the device is already running a later Windows version). That also provides the administrator more flexibility for controlling the Windows version of the device. With a Windows 10 update rings policy the administrator was limited in controlling the timeframe that a device could stay on a specific Windows version. The administrator could defer the period when the device would install a new feature update with 365 days and then pause the update assignment for another 35 days, but that was it. The Windows 10 feature updates policy actually freezes the device to the configured Windows version until the administrator modifies or removes the assigned policy.

The assigned Windows 10 feature updates policy only controls the feature updates on the device. That means that while the installed Windows version is frozen, the device can still receive and install quality and security updates for their installed Windows version. These updates will apply for the duration of support for the installed Windows version.

Limitations for the Windows 10 feature updates policy

Before looking at the current prerequisites and the configuration steps of a Windows 10 feature updates policy, it’s good to be familiar with the current limitations of this policy type.

  • When deploying a Windows 10 feature update policy to a device that also receives a Windows 10 update rings policy, the following configurations should be in place within the configured update ring:
    • The Feature update deferral period (days) setting must be set to 0.
    • The feature updates of the Windows 10 update rings policy must be running.
  • Windows 10 feature update policy cannot be applied during the Windows Autopilot process, instead the policy will apply at the first Windows Update scan after a device has finished provisioning (which is typically a day).

Also, keep in mind that this is still preview functionality. It might behave different than expected in some scenarios. At the time of writing this post I’ve seen scenarios in which this policy type might not work correctly when skipping a Windows version.

Prerequisites for the Windows 10 feature updates policy

When starting with the implementation of a Windows 10 feature updates policy, the following prerequisites must be met – at this moment – by the assigned devices to guarantee the described behavior.

  • The device must be running Windows 10 version 1703 or later
  • The device must be enrolled in Microsoft Intune and should be Azure AD joined or Azure AD registered.
  • The device must have telemetry turned on, with a minimum setting of Basic.

Configuring the Windows 10 feature updates policy

The configuration of the Windows 10 feature updates feature is actually pretty straight forward and doesn’t require a lot of configuring. The following 5 steps walk through the configuration of the Windows 10 feature updates feature and all the available configuration options.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices Windows > Windows 10 feature updates to open the Windows – Windows 10 feature updates blade
  2. On the Windows – Windows 10 feature updates blade, click Create profile to open the Create feature update deployment wizard
  3. On the Deployment settings page, provide the following information and click Next
  • Name: Provide a valid name for the Windows 10 feature updates deployment
  • Description: (Optional) Provide a description for the Windows 10 feature updates deployment
  • Feature update to deploy: Select the Windows 10 version that should stick on the devices (current options are Windows 10 1803, Windows 10 1809, Windows 10 1903 and Windows 10 1909)
  1. On the Assignments page, click Select groups to include to assign the Windows 10 feature update deployment to a group of devices and click Next
  2. On the Review + create page, review the configuration of the Windows 10 feature update deployment and click Create

Administrator experience

Now let’s end this post by having a quick look at the administrator experience. Once the policy is assigned to the device, the device will check-in and install the Windows feature update according to the configured policy. The eventual result can be verified by navigating to Devices Windows > Windows 10 feature updates > [CreatedWindows10FeatureUpdatesPolicy] > End user update status. That report provides an overview of the assigned devices and their (feature) update status (as shown below).

More information

For more information about configuring updates in Microsoft Intune, refer to the documentation about Manage Windows 10 software updates in Intune.

Block Android device enrollment for specific device manufacturer

This week is all about restricting the enrollment of Android devices. More specifically, about a very recently introduced feature which is the ability to block Android device enrollment based on the manufacturer of the device. That enables the organization to prevent Android devices of specific manufacturers from enrolling in Microsoft Intune. That can be useful when the organization has a specific policy for allowed device manufacturers. In this post I’ll walk through the configuration steps, followed with the end-user experience.

Starting with this post, I’ll provide both the configuration steps via the Microsoft Endpoint Manager admin center portal and the configuration location in the Graph API (including the related JSON-snippet) as part of the configuration steps.

Configuration steps

Now let’s start by having a look at the configuration steps. These configurations can be achieved by either creating custom device type restrictions or by editting the existing default device type restriction. In the following example I’ll walk through these steps by adjusting the default device type restrictions. The following steps show how to add a device manufacturer to a list of blocked manufacturers.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Enroll devices > Enrollment restrictions to open the Enroll devices – Enrollment restrictions blade
  2. On the Enroll devices – Enrollment restrictions blade, select the Default device type restriction and navigate to Properties to open the All Users – Properties blade
  3. On the All Users – Properties blade, navigate to the Platform settings section and click Edit to open the Platform settings page on the Edit restriction blade
  4. On the Platform settings page, provide the manufacturers to block in the Device manufacturer field (see example below) and click Review + save to continue to the Review + save page

Note: Use a comma-separated list when adding multiple manufacturers.

  1. On the Review + save page, click Save

For automation purposes, it might be better to know how to automate the device type restriction configuration. That can be achieved by using the deviceEnrollmentConfigurations object in the Graph API.

https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations

However, keep in mind that the required properties are currently only available in the BETA version of the API. Below is an example snippet of a JSON that contains the Android Enterprise configuration with the blocked manufactures configuration, similar to the configuration via the UI.

"androidForWorkRestriction": {
    "platformBlocked": false,
    "personalDeviceEnrollmentBlocked": false,
    "osMinimumVersion": null,
    "osMaximumVersion": null,
    "blockedManufacturers": [
        "Samsung"
    ]
}

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the behavior on a personally-owned Android device that should enroll by using Android Enterprise work profiles to manage corporate data and apps. By default, enrollment of this type of personally-owned devices is enabled. That can be limited by using the enrollment restrictions, as shown in this post, or by simply blocking personally-owned devices.

In this scenario, I’m allowing the enrollment of personally-owned and company-owned Android devices, but I’m blocking any enrollment of Android devices from a specific device manufacturer.

When the end-user downloaded and installed the Company Portal app and started the enrollment process, at some point during the enrollment process the end-user will be blocked. While being blocked, the end-user will receive the message “Couldn’t add your device“. That message, of which an example is shown on the right, includes a clear explanation of why the device couldn’t be added. In my example the end-user is being told that the company needs the end-user to use an Android device manufacturer other then samsung.

Note: Keep in mind that the only reason that I’m using Samsung as an example in this post, is that I’ve got test Android devices of that device manufacturer. I don’t have any reasons that would actually require me to block the enrollment of Android devices from that device manufacturer.

More information

For more information about blocking Android device enrollment for specific device manufacturers, refer to the following docs:

Exclude specific groups of users or devices from an app assignment

This week another post about apps. This week it’s all about the ability to exclude a specific group of users or devices from an app assignment. That ability is not completely new, but it’s new enough to be still a little bit unfamiliar for many. It can be useful for assigning an app to a big group and still being able to exclude a small group. That can be users that should be treated a little different than the standard, like for example a test group, a demo group, or an executive group. In this post I want to have a look at those configuration options. Often I’ll also have a look at the end-user or administrative experience, but in this case there is nothing to show. It’s just an assignment configuration.

Configuration options

When working with apps the administrator has the option to assign the app to a specific group of users or devices. That can even be multiple groups. Now the administrator also has the option to exclude a specific group of users or devices. That exclusion will take precedence over an inclusion. At least for the following same group type configurations:

  • Include user groups and exclude user groups when assigning an app
  • Include device groups and exclude device group when assigning an app

An example of this would be for an administrator to assign an app to the users of the All users group and to exclude the users of the All demo users group. In that example all users except for the users of the demo users group, would get the assignment of the app. Simply because both groups are user groups. That would enable the administrator to treat the demo users differently for demo purposes.

It’s good to keep in mind that Microsoft Intune doesn’t evaluate user-to-device group relationships. When the administrator would assign apps to mixed groups, the results may not be expected. That also means that the exclusions are a service-side evaluation and not a client-side evaluation. On the service the results of the included and excluded groups are “calculated” and the result is used as the target of the assignment.

An example of this would be for an administrator to assign an app to the users of the All users group and to exclude the devices of the All demo devices group. That creates a mixed group app assignment that would result in all users (of the All users group) getting the app assignment. In other words, the exclusion does not apply. That means that it’s not recommended to mixed group app assignments.

Configuration example

Now let’s have a look at a configuration example of assigning a Win32 app in Microsoft Intune. In the following example I’ve added an assignment of the Win32 app to the users of the All users group and I want to add an exclusion for the users of the All demo users group. The following steps show how to add that exclusion by editing an existing assignment.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps Windows > Windows apps to open the Windows – Windows apps blade
  2. On the Windows – Windows apps blade, select a Win32 app (or create a new one), click Properties and navigate to the Assignment section and click Edit to open the Edit application blade
  3. On the Edit application blade, on the Assignments page, click Add group, select the All demo users group and click Select
  1. By default, the newly added group will be added with the Included MODE. To adjust this, click on Included, of the newly added group entry, switch the Mode to Excluded and click OK
  1. Now the All users group should show as Included and the All demo users group should show as Excluded. Click on Review + save to navigate to the Review + save page
  1. On the Review + save page, verify the new configuration and click Save

Note: The Review + save page will, just like the Assignments section in the Properties of the app, show both groups like both groups are a required assignment.

More information

For more information about excluding specific users or groups from an app assignment, refer to the documentation about Include and exclude app assignments in Microsoft Intune and Intune Standalone – Win32 app management.