This is quite a technical post but something that has come up with customers and partners routinely. Hopefully this guide helps IT Administrators with this commonly asked question!
Problem: How to manage Windows 10 devices securely and easily with MEM (Microsoft Endpoint Manager) and AutoPilot by allowing any user in the organization (school / university) to trigger the device enrollment, but prevent personal / non-authorized / BYOD devices from being ‘accidentally’ enrolled
Requirements: M365 A3/A5 (E3/E5) or AADP1 + Intune; Windows 10 devices registered for AutoPilot
Device management has progressed significantly in recent years and Windows 10 is now best managed with a “modern management” approach through using an MDM (Mobile Device Management) app like Intune, part of the Microsoft Endpoint Manager (MEM) suite. Organizations are now able to easily manage both “corporate devices” (owned by the institute such as staff devices, computer suites etc) with a fully managed, high control model or “BYOD” (Bring Your Own Device) with perhaps a lower level of management and control, yet still enforce some security baselines.
From a Windows 10 perspective, solutions like AutoPilot unlock the possibility of shipping a device directly to the end user, without the IT team needing to touch the device to preconfigure it, allowing the end user to enroll the device and have Intune push out the necessary apps, settings and configurations. Recently, talking with some colleagues and customers, they wanted clear guidance on how to permit only corporate owned devices to enroll by Autopilot and totally block non-managed / personal Windows 10 devices from being able to accidentally enroll into Intune management.
Through the correct configuration of AzureAD and Intune, this end state is possible.
Granting End Users Automatic Enrollment Permissions
The first step is to allow the end users to automatically enroll their devices. Documentation for this is here and for a simple and seamless experience, AzureAD Premium is required (AADP1 or AADP2) as this will complete the enrollment into Intune:
Automatic enrollment lets users enroll their Windows 10 devices in Intune. To enroll, users add their work account to their personally owned devices or join corporate-owned devices to Azure Active Directory. In the background, the device registers and joins Azure Active Directory. Once registered, the device is managed with Intune.MSFT Documentation: https://docs.microsoft.com/en-us/mem/intune/enrollment/windows-enroll#enable-windows-10-automatic-enrollment
I definitely encourage you to read the documentation on this as it has a step by step guide, but if you want to shortcut to the direct link in your AzureAD Portal then here is the link. It looks like this:
Again, it’s worth reading the documentation around MDM and MAM and which takes priority in a BYOD situation, however in this example the org is trying to block BYOD devices entirely from accidental enrollment, whilst still allowing anyone inside the org to enroll a “corporate owned” device. To achieve this, you need to allow either “All” (as in the above screenshot) or “Some” (and define the users/groups who can do this) for MDM user scope.
This achieves the first half of the objective: allowing end users to manage the enrollment of devices, however as it stands it’s still too broad and open. With just the above settings, personal devices could be joined to AzureAD and enrolled into Intune for management, even when an organisation wants to explicitly block this.
To complete the objective, the second step of blocking personal devices must be configured.
Blocking Personal Devices From Enrollment
The documentation is pretty good in this space, and the starting point is here, but for the specific scenario we are resolving here (blocking personal Windows 10 enrollments) you can shortcut to the documentation here. The key point to pick up on here is what qualifies as a “corporate owned” device and this is actually determined primarily by the enrollment method. This is critical as it allows Intune to determine if the device is permitted to be enrolled and managed or not. From the documentation this means:
The following methods qualify as being authorized as a Windows corporate enrollment:
- The enrolling user is using a device enrollment manager account.
- The device enrolls through Windows Autopilot.
- The device is registered with Windows Autopilot but isn’t an MDM enrollment only option from Windows Settings.
- The device’s IMEI number is listed in Device enrollment > Corporate device identifiers.
- The device enrolls through a bulk provisioning package.
- The device enrolls through GPO, or automatic enrollment from Configuration Manager for co-management.
It’s worth noting here that there are two other methods of enrollment that qualify as “corporate enrollment” but because they do not provide the Intune Administrator per-device control, they remain blocked:
- Automatic MDM enrollment with Azure Active Directory join during Windows setup
- Automatic MDM enrollment with Azure Active Directory join from Windows Settings
The following “personal enrollment methods” will also be blocked:
- Automatic MDM enrollment with Add Work Account from Windows Settings*.
- MDM enrollment only option from Windows Settings.
So how is this configured? Jump into the Admin Centre for Microsoft Endpoint Manager and navigate to Devices > Enrollment restrictions > Create restriction > Device limit restriction; or simply click here for the shortcut! Ensure at this point you block “Personally Owned” enrollments for Windows 10:
Note in the example, that for contrast I’ve allowed the personal enrollment of iOS devices – this is pretty common in a BYOD mobile phone scenario where the phone may have to be registered with Intune to ensure basic security policies are applied e.g. a PIN is required if corporate email is going to be activated on the mobile phone.
With the above settings in place, personal Windows 10 devices will not be able to be enrolled into Intune, however corporate owned AutoPilot registered devices will be, allowing the end user (e.g. a teacher / admin staff) to be able to manage the enrollment and registration of a new device shipped to them independent of any support from the ICT team. Critically, however, they will not be permitted to intentionally or accidentally enroll a personal Windows 10 device.
If a user tries any of the following enrollment methods it will also fail (by design):
- A non-Autopilot registered device attempting to AAD join at device setup
- MDM only enrollment
- Add “work account” in Windows Settings
- Add “work account” in Windows Mail client or Office365 ProPlus (M365 Apps) e.g. Work
Education is one of the fastest industries to adopt modern management and the combination of AzureAD and Intune is a powerful set of tools allowing organisations granular control over which devices are permitted to be enrolled and managed. With BYOD a major force in education, schools and universities want choice about whether to manage BYOD. The example covered in this blog takes a minimalist approach to BYOD, allowing only for “corporate owned” (school owned) devices to be managed and ensure that end users (teachers, admin staff and students) can not accidentally enroll a personal Windows 10 device into Intune and unknowingly have policies and apps applied to their device.
Extra For Experts
It’s entirely possible that a school / university (organisation) may have not realised that these restrictions were available and had end users enrolling “corporate devices” (i.e. school owned) or personal devices into Intune through the variety of methods available, and are only now wanting to restrict access to enrollment of these devices.
If this is the case, then they will have numerous “corporate” devices enrolled into Intune but registered as “personal” devices. This can be rectified by:
- Manually changing the status of these devices in Intune – follow the guide here:
- More creatively, you could create a dynamic group that targets device owner type -eq “company” (note, it is “company” even though “corporate” is used and referenced elsewhere)
This would allow the Intune Administrator to tidy up incorrectly classified devices and manage them moving forward in a standardized way (hat tip to Stefan van der Busse for this suggestion around re-classifying devices incorrectly enrolled).
A further hat tip to Michael Hildebrand who also provided input and guidance here and is definitely worth following on LinkedIn!
If you have other ways of managing devices with Intune that you want to share, leave a note in the comments below!