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.

 

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.

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.

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

Supported options include or exclude groups from a profile assignment

Assignment inclusion/exclusion options

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.

Setting error SETTING PersonalizationDesktoplmageStatus STATE Error SOURCE PROFILES Source Profile WIO - Wallpaper ERROR CODE ox87d10000 ERROR DETAILS No error code x

Error assigning wallpaper to System account

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

Where Azure AD MEMDevices MEMApps MEMEndpoint Securi Functionality Allow MOM Enrollment Allow MAM Enrollment Options None/Some/All None/Some/All Users may join devices to Azure A None/Selected/All Device Type Restrictions Device Limit Restrictions Enrollment Status Page Deployment Profile Compliance Policy Scripts Configuration Profiles Feature Updates update Rings Policy sets 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 Default Default Default Option Some Some Selected Include groups Include groups Include groups Included groups Included groups Included groups Included groups Included groups Included groups Included groups Required (Incl/Excl) Included groups Included groups Included groups Included groups Included groups Included groups Included groups Included groups Included groups Assignment types UG/DG UG/DG UG/DG UG/DG UG/DG UG/DG UG/DG/AD UG/DG/AU UG/DG UG/DG/AU/AD/AUD UG/DG UG/DG/AU/AD/AUD UG/DG/AU/AD/AUD UG/DG/AU/AD UG/DG/Anonymous UG/DG/AU/AD/AUD UG/DG UG/DG/AU/AD/AUD UG/DG/AU/AD/AUD UG/DG/AU/AD/AUD UG/DG/AU/AD/AUD UG/DG/AU/AD/AUD UG/DG/AU/AD/AUD Option2 Excluded Groups Excluded Groups Excluded Groups Excluded Groups Excluded Groups Excluded Groups Assignment type UG/DG UG/DG UG/DG UG/DG UG/DG UG/DG Available for enrolled devices (Incl/Exc LIGÆG/AIJ uninstall (Incl/Excl) UG/DG/AU/AD Excluded Groups Excluded Groups Excluded Groups Excluded Groups Excluded Groups Excluded Groups Excluded Groups Excluded Groups UG/DG UG/DG UG/DG UG/DG UG/DG UG/DG UG/DG UG/DG

MEM/Intune assignment options

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:

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?

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.

Group based licensing

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).

O Important We don't currently support: Adding groups to a group synced with on-premises Active Directory. Adding Security groups to Microsoft 365 groups. Adding Microsoft 365 groups to Security groups or other Microsoft 365 groups. Assigning apps to nested groups. Applying licenses to nested groups. Adding distribution groups in nesting scenarios.

Not supported Azure AD group nesting scenarios

When multiple licenses are in place

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

All St—te 2nd Activity Audit logs •Z Bulk 'per—tic n re wlts Troublæhooting support Dastbcard > Insight24 3M. > Devices Devices I Device settings IEight24 3 V. - 1 member cted Save X Discard Got msyjcin devices to C) may register their with AD O o Lum more n this ætting works Require Multi-Fyctor- Auth to join number of per u Additional local administrators an all Azure AD joined devices AdditiorEI local Administr.tors on AD joined Enterprise State Roaming St—te Ræming settings

Device settings | users may join devices to Azure AD

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.

Configure MDM and MAM enrollment

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 limit restrictions Define haw many devices each user can enroll. Priority Default Name Device Limit Restriction All Users Device limit Assigned

Device limit restrictions

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.

Platform settings Edit Type Android Enterprise (work profile) Android device administrator i0S/iPados macOS Windows (MOM) Platform Allow Allow Allow Allow Allow Min N/A Max N/A Personally owned Allow Allow Allow Allow Allow Blocked manufacturers N/A N/A N/A

Default device type restrictions

Platform settings Edit Type Platform Min Max Personally owned Blocked manufacturers All device platforms are blocked. Allow platform enrollment to enable platform configuration.

Disable for all users

Platform settings Edit Type Android device administrator i0S/iPados macOS Windows (MOM) Platform Allow Allow Allow Allow Min N/A 10.0.18363 Max N/A Personally owned Block Block Block Block Blocked manufacturers N/A N/A N/A

Specify for licensed users only allow supported scenarios

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.

Enrollment Status Page Windows Enrollment Create The enrollment status page appears during initial device setup and during first user sign in. If enabled, users can see the configuration progress of assigned apps and profiles targeted to their device. Learn more x Priority Default Name Enrollment Status Page All users and all devices Assigned

Enrollment statup page settings

Deployment Profile

The deployment profile settings can also be found under the Windows Enrollment Settings in the Microsoft Endpoint Manager admin center. You can also assign the deployment profile to the license group. (even though it would be more logical to assign it to a group containing devices)

Windows Autopilot deployment profiles Windows enrollment Create profile v Windows Autopilot deployment profiles lets you customize the out-of-box experience for your devices. x Name Autopilot Profile Description Learn more Join Type Azure AD joined Assigned

Deployment profile settings

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

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).

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”

CAIJOI I-All: Block access for All users except licensed when Browser and Modern Auth Clients-vl .0 Users All Users Except AAD_AA_ConAcc-BreakgIass AAD AA CAUOI I-exclude License groups Assignments Cloud Apps All Access Controls Session Conditions Client Apps: Browser Mobile Apps and Desktop Clients Grant lock

CAU011-All: Block access for All users except licensed when Browser and Modern Auth Clients-v1.0

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.

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.

Al low MC" Enro LIG/ÜG LIG/ÜG P rcfi LIG/OG/AO LIG/ÜG LIG/ÜG Lj gro unique Wi Et AE [able for LIGDG LIG/OG Ri LIG/0G/Au/AOAuo MAM Enro LIG/ÜG Sta Page LIG/ÜG LIG/OG Cmfi g Z n P mfi IJG/OG/ALI/AO/ALIO LIG/OG/ALI/AO LIG/OG/ALI/AO LIG/OG LIG/OG join AzureA0 LIG/ÜG Limit LIG/ÜG LIG/OG Pd for Off Ap LIG/ÜG LIG/OG LIG/OG/ALI/AO/ALIO r ict LIG/OG LIG/0G/Au/AOAuo UG = User Group DG=Device Group AU = All Users AD = All Devices AUD = All Users and Devices LIG/CG LIG/CG/Au/A0/Auo x I ude

MEM/Intune deployment assignment design

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.

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

 

Previous articleAI Talks with Paul Peton – AutoML, A game changer!
Next articleTeams Real Simple with Pictures: New Calendar View in Lists Web App + Teams
avatar
I started my career in 1995 as a System Engineer in the broadcast industry, building and maintaining video editing suites and television studio's and later specializing in Telecine equipment. In 1998 I switched to a first line support function within the Information Technlogy on the dealing room of a large bank, working my way up to a 3rd line support engineer. From this position i started to work on projects, which eventually resulted in projects where I worked across the border. In this period I implemented and designed several deployment solutions for mass rollout of workstations, laptops and servers. Since 2009 I switched to a consultancy function mainly focusing on but not limited to System Center design and implementation projects, besides that I became a Microsoft Certified Trainer (MCT) and currently teach System Center Related Classes (SCCM, SCOM and SCSM). In Januari 2010 I received the Microsoft MVP award with the expertise Setup & Deployment which was extended in 2011 and 2012. In 2013 and 2014 I was awarded the VMware vExpert award. In october 2014 I received the Microsoft MVP award with the expertise System Center Cloud and Datacenter Management (SCCDM).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.