Personal Devices and the Intune Management Extension: A PSA
A while back Microsoft announced upcoming support for pushing PowerShell scripts to Azure AD registered devices in Intune. While the feature is still listed on their In Development page, it turns out that the feature is already rolling out in some tenants.
I decided to take a generic 1909 VM that I use to wrap applications. I opened the Settings applications and navigated to Accounts -> Access work or school -> clicked Connect and entered my credentials.
About one minute after I confirmed my account was added, I noticed that the Microsoft Intune Management Extension was added into my applications list.
After another two minutes had passed, I suddenly saw Adobe Acrobat DC installed as well - this was an offline installer I had wrapped into an intunewin package.
After another couple of minutes, I even received the Company Portal and another Store for Business application that was assigned to me (this wasn’t a surprise). I also realized that I had forgotten to assign an actual PowerShell script to myself - just for good measure, I uploaded a simple desktop url script, and the icon appeared after I forced a sync.
Hold on.
This is wonderful that this feature is available now, as I’ve seen a number of customers who had a mix of device types in Intune, and they were missing out on some management capabilities around these devices.
But here’s the potential problem.
Since Microsoft still doesn’t let you mix user inclusions with device exclusions, or vice versa, you can’t take a policy or an application and say, “assign to all users, but exclude personal devices” (this is the example that is still called out in their doc). That means if you have anything assigned to a user group, it can now potentially deploy to those personal devices, and there’s no way to exclude them from a user-based assignment.
Because of this, some folks may not want to allow personal devices to enroll into Intune. An administrator can block personal devices using the enrollment restrictions in Endpoint Manager. This however won’t remove any personal devices that are already enrolled, and some folks may have the need to support some personal devices in the environment.
Having said that, we may have to rework some assignments in the Endpoint Manager if we are concerned with personal devices receiving unwanted changes.
What do I do about Scripts?
If you have scripts that you do not want to apply to personal devices, then you will need to assign them to device-based groups.
More specifically, you will want a dynamic device group that is based off of the device’s group tag. You could potentially use other device properties to make a dynamic group, but group tags are great for laying out the overall personas when a device is enrolled through Autopilot. With group tags alone, you could assign all scripts, policies, and applications to the dynamic groups, and each group will help separate devices based on the desired use case.
There are times where I need to assign a script to a user group instead of a device group - this is usually because I need the script to run after the Enrollment Status Page. To avoid pushing scripts to byo devices in this scenario, I could wrap my PowerShell script into an intunewin package, assign the package to one of the dynamic device groups, and make sure it is NOT configured to install during the Enrollment Status Page (make sure you specify other applications instead for the ESP lock).
What do I do about Applications?
Definitely assign the win32 applications to the same dynamic device groups. Again, Store for Business apps have always been able to push to personal devices - if you are just realizing now that you need to avoid this, you can assign them to device groups as well (although the deployment time tends to slow down for these apps with the added calculations in MEM). If you don’t care about store apps installing on personal devices, or if you don’t have/allow any personal devices at all, then you should opt for a user-based assignment for store apps.
Anything else?
Double check your policy assignments as well, though technically these have always been able to push to personal device like the store apps. I would say in general, it may be a good practice going forward to plan your group tags and dynamic device groups. The group tag property alone will help separate and manage all personas for corporate (Autopilot) devices, and it may ease the burden of managing multiple, complex user groups.
Hope that helps anyone that was caught off guard by the recent changes. Till next time.