Here are 5 common recommendations based on misconfigurations I’ve came across in the field which will give your Intune tenant and devices a hard time to work smoothly. So better read this post that you not screw up your Intune tenant and maybe take advantage of the experiences others already gained.
Housekeeping
It’s important to know which devices are actually being used and usually a nice addition to understand compliance data. Stale device entries in may give you a wrong impression of your Intune tenant and it’s health. So enable the automatic device cleanup rule to remove the enrolled device from Intune. Additionally you may also remove the device entries stored in Azure Active Directory (I created a little on-demand script for this which can also run in azure automation).
Same applies to registered Autopilot devices. E.g. if you allow your employees to buy their old devices from the company if they get a new one make sure to remove the device from the Autopilot service. Otherwise you’ll see it again popping up in your tenant very soon. Thus it also prevents the device from being registered in another tenant as autopilot device.
If you deploy Line Of Business or Win32 apps with Intune, make sure that you do not accidentally downgrade apps with auto-update capabilities like web browsers. Enable the “Ignore app version” or configure your Win32 app detection rule that it’s not configured for a specific version.
Device compliance policies are great to monitor your devices compliance and for conditional access. It may seem obvious but this one is although missed often: If you require certain settings in compliance policies which your end devices will never fulfill because there’s no configuration which actually configures the setting it’s kind of a deadlock. So ensure that every setting you “expect” to be present on your end devices is also configured with an device configuration.
Example: If you require BitLocker to be enabled make sure that the BitLocker activation is configured in a device configuration policy.
Be aware that if you mix up assignments of device configurations with user- and device-groups you cannot make any excludes for another type. Consider this when you implement an assignment strategy. Also note that inclusion takes precedence over exclusion.
Same thing applies for creating multiple Windows Update rings. If multiple update rings are targeted to the same user or device it will result in a policy conflict. More information is available on Microsoft Docs.
Your end user have no understanding what actually happens when they sign-in with their Azure AD Account on their home PC?
This can easily lead to enrolled Intune devices which you probably won’t like to have in your tenant. So tell them that “Add this account to Windows” might not always be the best option or only allow corporate owned devices to enroll. Also notice that (almost all) Intune policies remain on a device even if it get’s unenrolled.
The enrollment for private owned Windows 10 devices can be blocked within the enrollment restrictions. Consider that only these documented scenarios on Microsoft Docs are accounted as non-personal owned. If you are focusing on Azure AD joined devices you will need to have the devices registered within the autopilot service in order that they are considered as corporate owned.
Have you experienced other hurdles? I’m curious to read it, so leave a comment below.