In my work as a modern workplace consultant, I see a lot of Microsoft Endpoint Manager/Intune environments. Many of these environments have been build based on trial and therefore it lacks structure and overview. Most of the environments have been built from scratch, adding and removing functionality until a point was reached where the solution was taken into production.

A solution that works, doesn’t necessarily have to be a solution which is consistent and therefore easily manageable.

Some of the situation I encountered:

• No structure
  • Sometimes Applications are assigned to user groups, sometimes to all devices and sometimes to a device group without any logical reasoning behind it
  • Configuration profiles assigned to device groups, user groups, all devices, all users without any logical reasoning behind it
  • Not all devices have the same settings applied for unspecific reasons
• Conflicting and errors for settings applied
  • When investigating devices have errors or receive conflicting settings
• Enrollment fails for unspecified reasons in some circumstances
  • When device limit for “accounts used to test” are reached
  • When a group membership necessary for the solution to work is forgotten to be added

Based on my experience so far, we can solve many issues by introducing consistency. But consistency comes with a price, you’ll have to make some choices and probably lose some flexibility.

In this article I’m going to share a (for me) most common scenario, implementing an MEM/Intune managed Windows 10 device deployed using Autopilot. There are many more scenario’s which are supported by MEM/Intune, and if implemented with the same consistency they will have the same properties.

Disclaimer: This post reflects the status of MEM/Intune and Azure AD as of November 29, 2020. Functionality may change, even right after this post has been published.

Goals for success and designing for Operations

I consider an MEM/Intune solution successful when:

• The requirements of the customer are met
• Device configuration is consistent and error free
• People administering the solution after being handed over know what to do and have a stable environment
• There is a process in place, to introduce changes in a controlled way into the environment.

Note from the field: Modern Workplaces are not the same devices like we used to know. When implementing Modern Workplaces people have to unlearn and let go of some of the principles they have been using for many years. Many concepts require a new view on how to manage (Windows 10) devices, and those are things that you cannot explain in a short note, or during an afternoon. It takes time, and as a Consultant you need to accompany IT Administrators while they relearn this new way of managing devices, you can do this be challenging every decision being made, especially decisions which are backported from their old environment.

Green field versus existing environments

When building new MEM/Intune environments, you have a luxury – you can start implementing your “template” environment and work from there. The challenge is most often in restructuring existing environments to a structured design keeping the impact for the already installed machines to a minimum.

Assigning to users or devices?

In November last year, I wrote the article: “Intune: Choosing whether to assign to User or Device Groups“, the article explained the case where Microsoft adopted the documentation and give some examples on when to assign to either user or device groups. While the documentation added makes sense, in practical you can really struggle to determine the best setup. Which setup you use doesn’t really matter, as long as it’s consistent and logical.

How I do it, the case for assigning to user groups.

Based on my experience so far, I try to assign to user groups as much as possible. I only see a case for assigning to device based groups in special scenario’s where a user doesn’t log on to the device, like for example the KIOSK scenario. For the rest I can say that assigning to user groups works the best for me.

I’ve also experienced some issues with assignment to Dynamic Device groups, where the group membership update mechanism is not really consistent and sometimes devices don’t end up in the device group while you need them for your settings, another reason for me to use user groups as much as possible.

This does have some disadvantages though, when assigning to a user, you can for example not let that user test on a device with new settings for example. This is because it’s not supported to exclude a device group when you assigned settings to a user group, as detailed in the Microsoft documentation here: Exclude groups from a profile assignment

I also had several issues with the System account, which will actual cause some device configuration profiles to give an error since they cannot be applied to the system account successfully. Some examples are setting a wallpaper, or configuring OneDrive settings. Personally I don’t like to see errors, even though they can be ignored as per Microsoft recommendation.

For reference I created an overview of all the settings which can be assigned. You can download the spreadsheet from my Github page.

The following abbreviations are being used:

• UG = User Group
• DG=Device Group
• AU = All Users
• AD = All Devices
• AUD = All Users and Devices

Some of the settings in the table require some extra explanation:

Applications are something special, since they support three methods (Required, Available for enrolled devices and Uninstall). For each of the methods you can define groups to include, or groups to exclude. Even though it’s possible to make assign Available for enrolled devices to a Device Group, it’s only supported when targeting Android Enterprise fully managed devices (COBO) and Android enterprise corporate owned (COPE) devices.

Compliance policies can be set to Device groups, but this has caused some issues for me, some examples below:

• https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/35775991-intune-duplicate-compliance-policies
• https://techcommunity.microsoft.com/t5/microsoft-intune/device-compliance/m-p/296721

This is the reason, why I always assign my Compliance policies to users, even though this can cause some issues while testing, for example if you want to test something on a device not compliant (like a VM or quick test) you might have issues with Conditional Access if the compliance status is used to determine if access to Office 365 is granted. For this reason I use test accounts.

The other thing I find interesting by making a table you actually see the discrepancies popping up, which are also not documented. Why for example would you only be able to assign a Security baseline to a User/Device Group only while other settings support All Users/All Devices or even All Users and Devices?

Setting up the environment

There are many settings to found in several locations which eventually determine the way Autopilot works, but also how the device behaves (based on the settings and applications it received).

Licensing

My starting point is always the user, in this case an account in Azure AD. That users must be licensed in order to use the functionality provided by the Windows 10 Modern Workplace which is managed by MEM/Intune. In most cases this license is based on Microsoft 365, but it can also be a combination of any of the sublicenses of course.

Make sure that you use the license group (which is an Azure AD security group) to provide the necessary licenses via this membership. You can configure this in Azure Active Directory. You can assign one or more product licenses to a group. Azure AD ensures that the licenses are assigned to all members of the group. Any new members who join the group are assigned the appropriate licenses. When they leave the group, those licenses are removed. See: What is group-based licensing in Azure Active Directory? for more information.

If you have more license variations all needing access to MEM/Intune Windows 10 enrollment, you could use group nesting to put users in their corresponding license group, add those groups to another Azure AD group which you use to configure the settings below. There is one remark though when doing this, assigning apps to nested groups is not supported (it works though, but keep this in mind).

Azure AD configuration settings

Within Azure AD we can configure several settings which make up for the experience.

Users may join devices to Azure AD

By default, all users are allowed to join devices to Azure AD, in my opinion if you want more control I would modify this setting to only allow users who are licensed to be able to join devices to Azure AD.

You can find these settings under Devices -> Device settings in the Azure AD portal

Enterprise State Roaming

By default Enterprise State Roaming is disabled, you can either enable it for All users or for a selection. You can enable the functionality for all users, but since only licensed users will start using it my advice is to use your license group again to give access.

Allow MDM and MAM enrollment

You can configure who is able to do an MDM and MAM enrollment by selecting Mobility (MDM and MAM) in the Azure AD management portal, selecting the Microsoft Intune application and configure the settings as detailed in the figure below.

Also here, make sure to only give the option to do MDM and MAM enrollment to your license group for consistency.

Microsoft Endpoint Manager configuration settings

Within Microsoft Endpoint Manager there are also different settings that you can set

Enrollment restrictions

The Enrollment restrictions are defined using device type restrictions and device limit restrictions. By default, all device types are enabled for enrollment for both Corporate as personally owned devices.

Device limit restrictions can be set between 1 and 15, my suggestion is to keep this the same as the “Maximum number of devices per user setting” in the Azure AD device configuration. Unfortunately you cannot set this to 0, this would have allowed us to create a new device limit restriction, set the value to 5 and assign it to our license group. You might one to do this even how, and set the limit for All users to 1

Device type restrictions by default allow all types of registrations, my advice is would be to disable all the scenario’s in the default settings applied to all users, and create a new device type restrictions where you define what you want to support and assign it to the license group.

Enrollment Status page

The enrollment status page (ESP) settings can be found under the Windows Enrollment Settings in the Microsoft Endpoint Manager admin center.

The default setting for the ESP is that it’s not configured for All users and all devices, which is nice. It’s now simple to create a new Enrollment Status page setting, and assign it to the license group.

Deployment Profile

The deployment profile settings can also be found under the Windows Enrollment Settings in the Microsoft Endpoint Manager admin center. You should assign these settings to a device group containing the devices which should receive the deployment profile. (Dynamic Device Group with Autopilot devices for example)

Policy sets

In October last year, I wrote an article about Policy sets: “What are Intune Policy Sets?” – even though I think that policy sets can become really handy especially for consistency, there are many caveats with the functionality it provides today. There my advice for now is not to use it, until Microsoft fixes some of the current limitations. See: Policy sets known issues

All the other settings

There are many other settings which can be applied, all support assigning to user groups so they can be assigned to our license group as well.

• Configuration profiles
• Compliance policies
• Scripts
• Feature updates
• Update rings
• Applications
• Policies for office apps
• S mode supplemental policies
• Security baselines
• Anti-Virus
• Disk Encryption
• Firewall
• Endpoint detection and response
• Attack surface reduction
• Account protection

Fixing conflicts and errors

After you have built your environment, spent some time to make sure that you don’t have conflicting settings in your configuration. Even though Microsoft has documented that what happens when conflicts occur, I personally like a situation where each setting is set once conform the defined standard.

The best is to start over with your new standard, you can do this by creating a new group for users and a group with all current users. Also create a new group for devices and a group with current devices. Use these groups to exclude as much as possible (so on the current settings exclude the new user/device group and vice-versa).

Azure AD conditional access

Last week I published a blog article titled: “Conditional Access demystified: My recommended default set of policies“. One of the mentioned policies was the CAU011-All: Block access for All users except licensed when Browser and Modern Auth Clients-v1.0 which actually blocks all users, except the “License Groups”

In my opinion this Conditional Access policy, while being very dangerous when implemented wrong can help to make the experience consistent. If you are not licensed, you don’t get functionality.

Conclusion

In the figure below I created an overview of the setup I’m using for my default Autopilot setup within MEM/Intune. As you can see most settings are applied to the license group. We have options to exclude certain setting for specific groups, allow us to test new settings on a subset of users (our test users). If you want to have a closer look, I also made the overview available as PDF for download on my GitHub page.

It could be though that I forgot some scenario’s which require you to use assignment towards Device Groups. If so, please leave a comment. I would be very curious to find out these use cases.

References

Exclude groups from a profile assignment – https://docs.microsoft.com/en-us/mem/intune/configuration/device-profile-assign#exclude-groups-from-a-profile-assignment

Microsoft Intune planning guide – https://docs.microsoft.com/en-us/mem/intune/fundamentals/intune-planning-guide

Common questions and answers with device policies and profiles in Microsoft Intune – https://docs.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot

How Application Context, Assignment and Exclusions Work in Intune – https://techcommunity.microsoft.com/t5/intune-customer-success/how-application-context-assignment-and-exclusions-work-in-intune/ba-p/1073357