Top 10 Intune mistakes and how to fix them

Mistakes are part of the learning process. It’s all about how we learn from them rather than making them in the first place. This article will examine the most common Intune mistakes I encounter, why they may cause you problems, and how to solve them. None of these are environment destroying, but they may cause you headaches and potentially may be sitting there, generating problems you’re struggling to work out.

1. Mixing User and Device Assignment

This is a particularly major one which is mentioned in the Microsoft documentation, but it’s well worth shouting about.

Intune and Azure AD group memberships are run at different times during the deployment process. If you have an application deployed to a user group but with an exclusion on the device group, there’s a good chance it will run the membership on the Included group first and deploy the policy/app before querying the Exclusion membership. As an excluded group isn’t the same as an uninstall group, detecting the members after the installation won’t fix it, you have closed the stable door after the horse has gone.

If you have a reason to mix assignments, you need to look at filtering. You can deploy to a User Group (or All Users) and then apply a filter to exclude devices from the group. This filtering is run as the Group membership is queried, so will be detected appropriately.

2. Deploying MSI Line of Business Apps

MSI Line of Business apps were never particularly great, even when first introduced. Since then, Win32 applications have had more features added, we have supersedence, custom detection, custom requirements, pre-requisites and much more. None of these features has been added to MSI LoB, which should be enough of a reason not to use it.

This is not the main issue, however. MSI LoB applications and Win32 applications use different install technologies on the device. MSI goes straight to msiexec, whilst a Win32 will use whatever you’re using for the install source. This can cause a clash where both apps have deployed simultaneously, and then both hit msiexec.exe. If you’ve ever tried installing two MSI files at the same time, you’ll notice that the machine will pop up with the second one saying an installation is already in progress and to retry.

Most of your Intune apps are running in the system context without user interaction, so they hang at this point. If this happens during Autopilot, they’ll wait for a response until it eventually hits the time-out and your deployment fails completely.

If you use MSI Line of Business apps, please wrap them into Win32. Even if things work nicely now, it’s not worth the risk!

It’s also worth noting the same can happen with poorly packaged applications. If a user input box appears, the installation will stall and fail.

If you’re not confident packaging these applications, consider using an application packaging provider.

3. Not monitoring Apple certificates

This is one I’ve seen before, and it’s something you’ll only ever do once!!

Apple Business Manager (or Apple Education) uses certificates in Intune for MDM Push, Enrolment and Apple VPP (Volume Purchase Program).

The MDM Push Certificate connects your devices to the Intune MDM Service. If this one expires, you can sometimes contact Apple directly if it’s within 30 days to renew it. If they can’t, or 30 days have passed, your only option is to wipe and re-enrol all your devices. Yes, it’s a full wipe, data destruction, everything.

The Enrolment Token is used to enrol your devices initially. If this one expires, you must create a new enrolment profile and transfer your devices to it. It isn’t quite as bad as a wipe, but it can result in the devices looking less healthy within the Intune portal itself.

The Apple VPP certificate is used to deploy applications to devices. If that one expires, users won’t be able to download and install any new applications until it’s renewed. Not a massive issue and easy to replace, but you could waste time troubleshooting an app install issue and not consider this as the issue.

There are numerous ways to alert on your certificates. You could set a calendar reminder, use the notifications from Intune/Apple or use Azure Automation to bug you regularly until you renew it.

4. Adding too many applications into Autopilot ESP

Intune and Autopilot are NOT SCCM or MDT. Task Sequences are a thing of the past. Do all your users critically need that application that’s only used by Finance once a year?

The Autopilot Enrolment Status Page should only contain applications crucial to the security of your machines (third-party AV etc.) or which your users won’t be able to operate without – M365 apps, any absolutely critical line-of-business apps. You want the Autopilot experience to be pleasant and painless for end-users. If they can access a new machine within 30 minutes, I’m sure they don’t mind waiting an extra few minutes for some infrequently used applications to arrive if they can be checking emails or browsing the internet in the meantime.

If you tell them they can’t use the machine at all for 90 minutes until ALL apps are installed, they’ll be less than pleased and also a lot less productive. Many apps these days are cloud-based SaaS, and realistically most users will be quite happy with the Office suite and internet access initially.

5. Using Autopilot with Hybrid Azure AD Join

Intune/Autopilot/Azure AD is a journey. Getting to the final destination is quick and easy for those with a small device estate and a simple environment, but for those with a massive, complex estate, it’s not always that easy.

This is where Hybrid-joined devices come into play. You can join your domain-joined devices to Azure AD and Intune to get all of the lovely goodies Intune and Cloud Management can offer you without the headache of rebuilding thousands of devices. As a device fails or is replaced, it can be moved to the cloud-only modern world.

This DOES NOT mean you should use Autopilot with a Hybrid join! Autopilot is the final step in the journey to be used when rebuilding older devices or provisioning new devices. At this point, you want to move your users to Azure AD and full modern management. You don’t want to deal with the numerous headaches of provisioning an Autopilot machine but still having to sort a domain join.

Cloud Trust, Hello for Business and SSO will make the AAD-only experience seamless for accessing on-prem resources, so please, when provisioning and re-provisioning, ditch the hybrid join. It has had its time, and it isn’t the early 2000s anymore.

6. Not using Compliance policies correctly

Intune compliance policies are incredibly powerful tools and work across platforms. On Windows especially, you can now create custom compliance policies to interrogate literally anything on the machine.

The mistake I often see is that no one does anything with this data. A non-compliant device should not be allowed anywhere near your environment. It is a recipe for disaster. If you have a policy saying that your Windows devices must be clear of viruses and a device is flagged as non-compliant, the last thing you want is to let it connect to your other services.

If you log into your Intune environment now and there are more than a handful of non-compliant devices, you have a problem!

Your compliance rules should be linked to a Conditional Access policy. If a device is non-compliant, block access to everything. Yes, it will add some overhead to your support team, but 30 minutes fixing an issue now is better than finding a virus or a ransomware attack which can take weeks to resolve, not to mention the cost implications.

Whilst on the subject, if you have this setting configured to Compliant, please change it immediately:

If a device doesn’t have ANY compliance policies assigned, that should be assumed as risky and infected. In this case, devices are guilty until proven innocent.

7. Giving Users Admin rights

One of my particular annoyances. Users DO NOT NEED ADMIN RIGHTS. Just because a C-Level executive claims to need to install a printer at home doesn’t mean you should give them the keys to the kingdom. Next thing you know, the device is in for repair, and the children have installed Minecraft, Roblox, 3 torrent packages and 17 internet toolbars.

Not only that, Intune policies are ultimately just registry keys. Give a user admin access, and they can simply delete all of the policies you have so carefully added. Maybe they have even decrypted the OS drive.

Claiming they only had access for a short time isn’t the answer either. It only takes a minute to destroy a machine. Or they could simply add an admin account you aren’t aware of.

Even your IT staff shouldn’t have admin access on their primary account. A second account should be used for elevation for an extra layer of protection.
With the new additions in Intune of Endpoint Privilege Management and LAPS for Azure AD devices, there’s no excuse. Yes, they’ll complain when you remove the permissions, but troubleshooting an issue is much easier when you know what you’re dealing with.

8. Not updating policies

Intune is constantly evolving. Every month comes with a new update, some more considerable than others.

If you deployed your environment more than 2-3 years ago, ask yourself this – when was the last time you reviewed what you deployed and updated it? I imagine when you moved to Intune, you reviewed your on-prem GPOs before migrating them. Those had a habit of being added to but never cleaned up, and you’d still find Windows XP-specific policies simply slowing down login on a modern device.

When you deploy those workarounds for something not currently supported natively in Intune, keep an eye on them and update them when applicable. We all deployed PowerShell scripts or Custom OMA-URI policies to set registry keys because the support wasn’t there yet. When Settings Catalog came along and introduced many new settings, did you check how many of those you could subsequently remove from your workarounds?

If a new staff member joined your team and looked at your environment, how many times would you say, “Ah yes, I need to update that”?

Now’s the time to do so. Review your environment, and look at the policies which aren’t as well set up as you’d like. Migrate to Settings Catalog. You can always create a new tenant with a 30-day trial license, copy all of your policies across and then test in there initially.

9. Leaving Enrolment Restrictions unconfigured

I hold my hands up here. I’ve done this one before. You create your new environment, set your Azure AD MDM scopes to All, enrol your corporate devices and then give yourself a pat on the back for a job well done.

The next thing you know, you’re browsing through your devices and notice some which don’t match the naming convention. That’s odd. How did they get in there, and why are they showing as personally owned? Then you realise you forgot about the enrolment restrictions within Intune, and users have ticked the box when logging into Teams on their home device. Now you’re getting complaints about applications being installed onto personal devices, “I didn’t give you permission to change my own device”, “are you monitoring me at home now as well”? Yes, it’s the users’ fault for clicking the button, but now they’re passing the blame on to you.

Mopping up isn’t as easy as it sounds, either. You can’t just add the users to the uninstall groups, or it’ll remove them from their corporate device as well. You need to create a filter to grab just personal devices and then push the uninstall from there. But wait, they’ve also encrypted with BitLocker and received your corporate policies. Now you have a choice, create extensive documentation, get them to bring devices in for you to sort, or tell them they’ll need to wipe their personal machines.

To avoid all of these headaches, make sure you review the Enrolment Restrictions within Intune and set them according to your environment. If you go down the route of blocking unsupported OS versions, keep on top of it. When a new version is released, ensure you update the setting accordingly or within a year or two, it won’t be worth having.

10. Ignoring Azure AD

Whilst Intune is part of the M365 suite, it’s intrinsically linked to Azure and Azure AD, and you need to make sure you have a good understanding, particularly of Azure AD.

All of your Users, Groups, Conditional Access policies, whilst they can be accessed directly within Intune, are part of Azure AD. You need to understand how they work, what they do and how to configure, manage and support them.

A working knowledge of Azure Infrastructure will be useful, especially when dealing with Azure Virtual Desktop.

To go a step further, learning about Azure Storage Accounts, Logic Apps, Automation Accounts, and DevOps will help immensely when looking towards automating some of your more repetitive tasks.

There are courses and certifications which can help, particularly the AZ-104 Azure Administrator and AZ-140 for Azure Virtual Desktop.

It’s also worth ensuring you’re familiar with the Microsoft 365 Admin Centre and, if you’re using Defender for Endpoint, the Security Centre too.

For those of you who’ve previously worked in Desktop Support, this should be all too familiar, be an expert in your particular field, but you need to have a good working knowledge of everything that’s happening around it to do your job properly.