While the Hybrid Azure AD Join over VPN process probably gets people more excited, another change went live in Intune at the same time: The ability to target enrollment status page (ESP) profiles to groups of devices. Prior to this change, you could target groups containing users, and you could use the default ESP profile to target “All users and devices” as a fallback, but there was no way to target device groups. That was rather awkward with self-deploying mode and the white glove technician process, which don’t have a user, so for those scenarios you had no choice but to use the default ESP profile. There was also an “interesting” scenario where the blocking app list would not work during device ESP with a non-default (user-targeted) ESP profile, so ESP would end up tracking all apps.
If you target device groups instead of user groups, all of these issues go away (although you still do need to be careful with Hybrid Azure AD Join due to the shift from the Azure AD device object to the Hybrid Azure AD device object, as I discuss here and here). You can use a device-targeted ESP profile with self-deploying mode, white glove, and any other scenario, and you can use it in co-management scenarios where you want to turn off ESP for co-managed devices (once you build a group containing those devices).
Since this is just a “behind-the-scenes” behavioral change in the targeting mechanism for ESP profiles, you’ll notice no changes in the Intune portal, just a change in the result. You should understand the overall behavior though:
- Intune will go through all the non-default ESP profiles in priority order, attempting to find one assigned to a group that the current device is a member of.
- If no device assignment was found, Intune will go through all the non-default ESP profiles in priority order again, attempting to find one assigned to a group that the current user is a member of.
- If there was no device or user assignment found, Intune will use the default ESP profile (if enabled).
If you are using Windows Autopilot for existing devices, you would still need to use the default ESP profile, but all other scenarios will work fine with device targeting (and in some cases, better).
(See my previous blog on ESP to explain why the image above is impossible – it was manually assembled using Paint – and what each of the steps means.)
Categories: Windows Autopilot
A great step forward!! I have just tried this out and It will make our deployments so much easier targeting the devices rather than the users.
I look forward to trying White Glove tomorrow and hopefully this resolves one of the issues we have with that approach!!
A very welcome change indeed! And thank you for the clarity on behavior. Quick question is let’s say you have a Device-based ESP that is used to capture all devices (outside from the default ESP). If you want a User-based ESP to fire for certain users, can you exclude devices that the user is part of (exclude the user group in the Device-based ESP) so that the User-based ESP can run? Based on the behavior described, it will ignore the rest once it finds one. OR is the ESP evaluation done once at the device setup and once at the user setup?
Generally, it’s only done once (at enrollment time), and there’s no support for exclusions today.
So is it then by how you order it in priority which one it uses first? Just trying to understand what happens if you have them overlapping what considerations need to be made. My assumption is that if you have a device assigned to one ESP and a user assigned to another, the device ESP takes precedence regardless where it is in the priority. I’ll do some testing now 😉
this is a great change!
We are currently deploying devices using a device facing ESP to track Win32 apps.
This is working very well except one challenge: A required reboot during device setup phase is not happening.
Application A has a dependent application B. Application B needs a mandatory reboot after successful installation in order for app A to install. We have tried exit codes (1641) and also tried to script a reboot during installation of app B but the device is not rebooting. We are just getting an error in Intune saying app B needs a mandatory reboot.
Do you have any suggestions on this issue?
Thanks a lot.
We’ve been looking into that, it doesn’t look like Intune Management Extensions is handling that well today.
Are there any known issues with ESP tracking with the latest Windows 10 (2004) build?
We’ve enabled the ESP for all users. When a second user (shared device) is logging on to the device the VPN Profile is not tracked and applied. We don’t have this issue for the first user.
Is the VPN profile targeted to users? There is a known issue with VPN profiles on Windows 10 2004, working to get the word out to potentially affected Intune customers while a fix is being worked on for Windows.
We’ve tried both. Target the profile to “All Device” and “All Users”. The result is the same. The VPN Profile is only available for the first user after login. All other users don’t receive the VPN profile. The ESP is shown for a second when a second user logins in. It seems the VPN profile deployment is only tacked for the first user on the device.