Disclaimer: This blog is not intended to be advice on how to manage your environment. As the name suggests, these accounts are based on experiences I’ve had in my own lab. Always approach information you find outside (or inside for that matter) official documentation with skepticism and follow the golden rule: Never test in production.
The word “mistake” is a fairly subjective term in IT. According to the internet (because who uses a dictionary anymore) a mistake is an action or judgment that is misguided or wrong. Let me be clear; when it comes to endpoint management there are no such things as “mistakes” as long as the result is reliable and supportable. After all, we are Administrators: an infallible breed of problem solvers who spin magical threads to weave into the tapestry of our environment to make it work… most of the time.
In reality, we often find ourselves (in the interest of time) throwing something together to get the job done with little thought given to how we will interact with a profile in the future or who else may need to look at it. The following “mistakes” are more suggestions on how to avoid a headache than anything and there may be perfectly valid reasons for ignoring them. Only you can decide what is the best fit for your organization. With that said, there are a number of things that I often find in existing customer environments that ultimately end up being redone. Let’s dive in.
- Using Categories to determine Ownership or Device Type
Device Categories are chosen during enrollment to tailor profiles and deployments to a specific need that only the enrolling user can determine. On the face of it, it’s a logical tool to use in determining ownership of an existing device outside of any corporate enrollment method. After all, who better than the user to tell us if a phone belongs to them? Well, as it turns out: we are. The primary issue with Device Categories is not only user error, but the fact that it doesn’t actually identify the device as company or personally owned.
To leverage Intune to its full potential and gain the appropriate insights into company-owned devices during manual user enrollment; we need to change the deviceOwnership attribute either by hand (after enrollment) or by adding the Serial Number or IMEI to the Corporate Device Identifiers list before enrollment. Not only will this make dynamic device groups more accurate, but it is a critical distinction when managing devices in locations where user privacy is protected by law.
For many admins, this can be a daunting task if a database of company assets is incomplete or inaccurate, but keep in mind that all devices are assumed to be personal unless they are either enrolled via a corporate enrollment method (ABM/ASM, Autopilot, GPO, or Co-Management) or included in the Corporate Identifiers List before manual enrollment. The initial leg work will be worth the effort down the road if all future company-owned devices are deployed using these methods and can be identified correctly without relying on the user to make the correct selection.
On occasion (far less frequently) I also see organizations using device categories to identify the OS type which is flatly unnecessary and overly complicated as this information is automatically collected during enrollment. Just avoid doing this altogether and you will be fine. Once everything is in order, we can kick back and let our dynamic device rules do all the work. Take a break. You’ve earned it.
- Setting Detection Rules to “File/Folder Exists”
Anytime you’re working with Win32 apps it can be tempting to throw in the main executable path and call it a day. This is the quickest and dirtiest way to get an application to report success after deployment, but is it the best option? Not likely. If you’re new to application packaging it’s not always clear which option we should use for a given application or where to get the info you need. Without going too deep in the theory of packaging (something I’m sure I’ll discuss in a post of its own) let’s look at some of the simplest options.
MSI Product Code: If you are packaging an MSI as a Win32 app, Intune should be able to extract this automatically and fill the field appropriately. Otherwise, you can pull a list of installed product codes from your test machine using PowerShell:get-wmiobject Win32_Product | Format-Table IdentifyingNumber, Name
File Date Modified: Sometimes all you want to do is force deployments to run even if it already exists on the target. I find throwing in yesterday’s date with this method useful for packaging scripts with logs or non-application payloads.
File String Version: This frankly should be the most common method to use. It’s independent of the registry (which let’s face it, doesn’t always get cleaned up during upgrades/removals) and it’s easy to identify in the target file’s properties dialog. - Using giant “umbrella” configuration/compliance profiles
“Umbrella” profiles as I call them are singular configurations that include everything there is to configure under a given profile type and are often generically named “Device Restrictions”, “Administrative Templates”, or “Endpoint Security”. There are a few configurations that require being grouped to avoid conflict, but otherwise having large profiles driving multiple options can be cumbersome to navigate and maintain when a different group requires a minor variation. They also increase the risk of unintentionally changing an unrelated setting without realizing it as it becomes very easy to lose track of what a policy is meant to include.
As a personal rule, unless a conflict dictates otherwise, I try to keep my configuration and compliance policies consistent with their intended outcome. One profile to drive OneDrive options; one to enable defender and real-time protection; one to kick off BitLocker; and so on. In more complex deployments, this also allows us to specify individual policies for different user sets without the need to replicate other more standardized options. Similarly, I can now “pair” compliance profiles with their executing configuration by name and know exactly which setting I’m expecting to apply. - Using generic profile/group names
As I mentioned in suggestion #3 without some unique profile names you will quickly find yourself drowning in policies that all look the same if you have a large or varied userbase. Both profile and group names can be surprisingly detailed if you stick to a few simple naming conventions. Use them to your advantage and make identifying their function and target group visible from both the UI and reporting without having to dive into deeper menus for the same information.
For example: If I want to create different device PIN configurations for users in Outside Sales and IT; I could start both profiles with their intended purpose (Device PIN) then identify the applicable department.
- Trying to replicate or satisfy old, unnecessary policies
The secret to successful and reliable remote device management is simplicity. Far too often do I encounter organizations that try to shoe-horn old methodologies (which made sense in a closed, on-prem environment) into the world of cloud-based identity and device management. Maybe you’ve always required personal iOS/Android device enrollment before because your old MDM needed it to manage company data, but with Intune, we can drive App Data Protection, App-level PINs, and jailbreak detection policies by simply signing into the Office apps from the App/Play Store. Maybe you used to require field reps who haven’t set foot in an office for 5 years to be Domain Joined with a VPN, but now all their work lives in OneDrive and Sharepoint and we can simply use Azure AD Join to streamline the deployment process and allow them to work 100% in the cloud.
You’d be surprised how many steps and Help Desk interactions we can eliminate by simply asking the question “why” something is still being done that way. You may find that the pushback from above is too great or there’s a legacy application that you can’t get rid of, but if it checks all the boxes to reduce operations cost while simultaneously enabling productivity it can’t hurt to ask. - Forgetting to set enrollment restrictions
This one is more of a reminder than anything, but you’d be surprised how many customers I’ve worked with forget to look at Enrollment Restrictions to prevent unwanted or accidental enrollments. The option isn’t obvious unless you’re looking for it and it’s amazing how fast users find themselves unwittingly enrolling themselves without being prompted to do so by IT. Discuss with your team and have a definitive answer whether Intune licensed users will be allowed to enroll devices on their own or if only corporate-owned devices will be managed.
The image below is a screenshot of the prompt users are presented whenever they add their work or school account to Windows or Office 365. The checkbox is ticked by default and any Intune licensed user who is not paying attention will end up enrolled without Enrollment Restrictions in place to block them.
- Using Assigned groups beyond the initial pilot/testing phase
This one is a two-parter. The first being to clean up after yourself. Nothing is worse than beating your head against a problem caused by an orphaned testing group assignment you’ve forgotten about.
The second is in support of our #1 objective when leveraging an MDM: Reduce or eliminate manual work. Whether it’s licensing, assigning policies, or pushing out applications: we want to be able to touch it once and walk away. Dynamic Device/User groups are our best friends and as long as we can identify groups by some attribute in Azure/AD you’ll never have to manually add users to an assignment again… That is until you discover Joe in Accounts Receivable is the only person in the company that needs Adobe Acrobat Pro and gosh darn it, I’m not risking getting pulled into an impromptu meeting on my way to his desk to install it for him… In all seriousness you’ll never be able to avoid them entirely, especially when it comes to expensive, low quantity software; but always be on the lookout for standardized deployments based on job title or department whenever possible. - Assigning deployments and profiles to devices groups when users will do
Those of us coming from an SCCM background (or a non-hybrid joined CMG environment) know it’s often easier just to target groups of devices rather than try to identify each user’s primary device to avoid overlap when signing into shared workstations. When it comes to Azure it’s all about identity, identity, identity. We care more about who the user is, what they need to do their job, and what requirements stand in the way of their appropriate level of access no matter what device they are using.
In Intune, only the Primary User of a device will receive user-targeted profiles which is determined at the time of Enrollment. Shared workstations are identified by their lack of a primary user at all in which case device group assignments are the only way to go. Shared devices aside, unless you have a deployment that has to occur during the Device Setup phase of Autopilot before the user logs in, User groups are almost always the preferred way to go. - Using a single, flat Windows Update Ring
Out of everything on this list, this is the only one I will insist is a true mistake and should be avoided at all times. I have gone in circles more times than I can count with customers who insist on updating everyone in one go simply because they’ve “never had a problem before” and “want to be up to date as soon as possible”. While the latter is commendable, the former is the first ingredient in the recipe for disaster. Even if Windows update were flawless 99.99% of the time, are we really going to risk the downtime and potential support hours to resolve it when it’s not? The solution is a simple matter of process and costs no more than the time it takes you to plan for it. I’ll even give you a fairly aggressive example to get started:
Ring 0 – You and your team are here. deferral 0, deadline 2.
Ring 1 – Test users who are involved in support. deferral 4, deadline 2
Ring 2 – Volunteer test users from a wide range of roles in the organization. deferral 8, deadline 2
Ring 3 – Low revenue impacting departments like HR or IT. deferral 12, deadline 3
Ring 4 – Low revenue impacting sites. deferral 17, deadline 3
Ring 5 – High Profile departments and users (like C-Suite or Sales), deferral 22, deadline
Ring 6 – All Users/All Devices, deferral 27, deadline 3
These preliminary rings are my starting template. Make adjustments where appropriate, but the key is to start small and with minimal risk and work your way out. Make sure you give each wave at least a day or two after the deadline to report any problems before the next one begins and you should be able to start rolling out to very large groups of users within two weeks of an updates release while still being able to hit the brakes if something comes up. Don’t forget to exclude previously assigned users/devices from subsequent rings to avoid conflict. - Making multiple changes in rapid succession
Making changes in Azure is an exercise in patience. It’s no secret that we have to wait for new configurations to process in the back end before they can be pulled down by an endpoint, but it is especially true if you realize you made a mistake and go back to fix it. I’ve lost count of how many times I’ve found myself banging my head against my desk struggling to get something to work that should; only to go to lunch and come back to find it works. Find something else to work on for a bit or let it settle overnight and come back to it in the morning. If the solution to a problem isn’t clear, it’s both a practical and mentally healthy thing to try and works more often than not.
Do you have any tips on things you wish you knew the first time working with Intune? Are there any other common mistakes you see working with your customers? Let me know in the comments so I can avoid them too.