The Perfect Intune Policy Design
The first week’s “Friday mail sack” blog post on Primary User was pretty successful so I’m going to keep this thing going for now! This week’s question is from @Devmgmt365 on twitter. Remember, if you have a question that should be answered in blog format, please shoot me an email or tweet me!
Question: Hey Scott, Is there a best practice (or your personal recommendation) for designing configuration profiles in Intune? I’m curious if I should try to stick as many settings in a single profile or break them up? What’s more effective and efficient? Is there a risk having too many profiles targeted to a device or too many settings in a profile?
Answer: The short answer is “No”. As far as I’m aware there is no Microsoft ‘official’ best practice policy design, and no documented limits on number of policies or the size of those policies. The factors you should consider in the design are Ease of management and delegated administration. Here’s my rambling thoughts on the topic though…
Terminology
Before we get started, lets level-set on the terminology I’m using in this post —
Policy: This is the container object in Intune that collects one more policy settings. You can assign policy objects to groups of users or devices. These are interchangeably called ‘profiles’ in the console but I’m using ‘Policy’ as the broad term to describe include all the various payload types (Device Configuration created via Templates, Settings Catalog, Administrative templates or GPO Analytics, Security Baselines, and Updates). I’ll also call them “Policy objects” here to make it super clear I’m talking about the bucket.
Policy Setting: These are the individual configurations within an Intune Policy. They can’t be assigned to groups directly, you have to collect them in a Policy object first.
Now that we’ve got that out of the way, let's take a look at the three dimensions I think are important to have an “Effective and Efficient” Policy design:
- Performance
- Ease of management
- Delegated administration
Performance ⏩
Unlike Group Policy, which has some pretty complex performance recommendations on the size and contents of policy objects, there really isn’t any performance benefit either way with Intune MDM management. That’s because it works differently.
Group Policy has a client engine that chugs its way through a list of Policy object’s during logon and background refresh cycles, downloading the updated ones and arranging them all in a priority order and invoking the necessary Client Side Extensions (CSE’s) to do the work of applying settings. The combination of more policy objects to download and more CSE’s firing causes bigger performance hits for the device.
Intune, on the other hand does policy computation in the cloud before a device check’s in. It pulls together all the Policy objects, and Policy settings within them along with group targeting configuration to build a device’s Effective policy — a document of all the stuff that needs to apply at the next check-in time. Upon check-in, the MDM client asks Intune for the new policy document, does some version comparison, downloads the effective policy and then invokes Configuration Service Providers (CSP’s) to do the work of applying all the settings in the document.
Ease of Management ⚙️
We ruled out performance as a decision point, now let's look at designs that are easiest to look after.
To highlight pro’s and con’s I’ll use some examples configurations I’ve seen. The example configurations all achieve the same goal, which is to apply these settings on a group of devices:
- Setting 1: Value 1
- Setting 2: Value 2
- Setting 3: Value 1
- Setting 4: Value 1
- Setting 5: Value 1
Example A: Mega Policy Model
In this model, you create a mega-policy and cram all the desired policy settings into it. While it sounds nice and simple in theory, it usually isn't possible or practical to do in reality. And yes, the introduction of the Intune “Settings catalog” policy type now gives you an empty policy bucket to fill with the desired settings, however it’s very likely that you’ll need to push configurations that don’t exist within the catalog — for example Update settings, Certificates or Wi-fi profiles.
Example B: Functional Policy Model
In this model, you create multiple buckets (aka policies) of settings, grouped by function and assign those to a group. The Intune Policy type model and UX will highly influence what settings are in your buckets because certain settings can only be set within certain profile types. For example, Wi-Fi, VPN, Certificates and email policy objects are all examples of functional policies — they are made up of individual settings that must be configured together in the same profile to define the desired configuration and apply properly.
Example C: One setting per policy Model
This is the “Buffet-style” model, where you create lots and lots of Policy objects that contain exactly one policy setting and configured value. This model is pretty extreme, but I have seen it done in order to achieve ultimate targeting flexibility. Choosing a model like this means that you’ll end up with 100’s to 1000’s of policy objects which could become a management nightmare without your own UX-layer on top of Graph API or at least using the Policy Sets feature to help ease repetitive task of assigning that many workloads to the same group.
When I say this model gives ultimate targeting flexibility, I’m talking about exclusion management. Since each Policy object contains just one setting, you can manage exceptions at the settings-level.
Delegated Administration 🔐
Although this post does not focus on Intune Role Based Administration and Control (RBAC), it is worth mentioning because it can significantly impact your Policy design. Even more so if you manage a huge or highly distributed environment with the complexity of multiple teams working on separate projects or sub-organizations within the same Intune tenant.
Below are three delegated admin policy design patterns I’ve seen for those larger, multi-level organizations that have tiered admin models featuring:
- Central Admins — who manage the entire tenant, and
- Project Admins — who manage a smaller project or sub-organization within the Intune tenant
Here are the three example models I have in mind:
Example A: Full delegation model
In the Full delegation model, smaller subsets of administrators (Project Admins) are allowed to create their own Policy objects and assign them to the groups that they manage. If set it up correctly with Scope Tags, Project Admins won’t be able to see or interact with each other’s Policy objects in the portal. While the diagram above shows just one policy for each project group, the reality is that Project Admins are free to create as many Policy objects as they like using one of the “Mega”, “Functional” or “Single-setting” policy options described earlier.
Example B: Partial delegation model
In this model, both Central Admins and Project Admins create and assign Policy to the same groups. Central Admins create “Standard” or “Common” policy objects that are generally applicable to all projects while Project Admins create project-specific Policy objects, while being careful to not create setting conflicts.
The main benefit to this model is Policy object re-usability and reducing the number of duplicate policy objects within the same tenant. Consider, for example a large organization that has 1000 “projects”within it, each of those Project Admins go and create their own version of Policy but using exactly the same security guidance. You’d end up with a very high degree of identical Policy objects which would at some point become a scale issue in a huge tenant.
Example C: Centrally managed with no delegation
The last example is where Central Admins take on the responsibility of all Policy management and don’t give Project Admins access at all. Project Admins are still trusted with other Intune tasks such as Remote help (through device actions).
In this model, Central admins create Policy objects which they re-use across each of the projects.
In Summary..
There is no performance reason that should influence your Policy size design decisions. The major factors I’d consider are:
- Ease of management, and
- Delegated administration
Since most of the Intune policy creation experiences force you down the “Functional” Policy path anyway (eg: Wi-fi, VPN, Email, Endpoint Security, Compliance, Firewall, Updates etc), my recommendation is to continue that “Functional” Policy mindset in the Settings Catalog. This will give you a good balance between flexibility and simplicity, keeping the number of Policy objects down to a manageable amount and allowing you to make exceptions if you need them.
Lastly, the delegated administration model your organization chooses will be a major influence on the structure and contents of Policy objects. Your focus will be making sure the right administrators can see and make changes to the stuff within their scope and prevented from seeing and making changes to everyone else’s stuff.
I hope this post is helps answer your questions about Policy design. If you have some further experience and guidance here that should be included, please drop me a note and I’ll include it!
Happy Friday!
