How to organize your Microsoft Intune deployments like a Rockstar – Part 2

Several years ago, I attended an online MC2MC session brought by former Microsoft Most Valuable Professional Tim Hermie. This session was about using a naming convention to easily and organizationally manage and configure your Microsoft Intune for larger companies (or even smaller ones). For me, the tips he shared formed a foundation for how I configure and manage Microsoft Intune environments for our customers today. Yes, even the smaller ones.😉

In this two-part blog post, I will show you how I bring structure into my Microsoft Intune projects by starting with a proper naming convention.

I think every Microsoft Intune should start with a good and solid naming convention! But why is this so important? Writing down a good naming convention has the following benefits:

• Consistency: Ensures uniformity across the project, making it easier to understand and maintain.
• Readability: Improves the clarity of the data, making it easier for others (and yourself) to read and comprehend.
• Maintainability: Simplifies updating and modifying the data, reducing the risk of errors.
• Collaboration: Facilitates teamwork by providing a common language and structure, making it easier for team members to work together.
• Scalability: Helps manage larger projects by providing a clear and organized structure, making it easier to scale up.
• Debugging: Aids identify and fix issues more efficiently by providing clear and descriptive names.

So now that we know the importance of naming conventions, where do I use them in my Microsoft Intune projects? Almost everywhere!

• Microsoft Entra ID Groups
• GroupTags for Devices in Windows Autopilot
• Compliance Policies
• Configuration Policies
• Endpoint Security Policies
• Windows Updates
• Applications
• …

Let’s become that Rockstar! 🤘🏻

The first part covered the naming convention for our Microsoft Entra ID groups and GroupTags in Windows Autopilot. In the second part, I will cover Compliance policies, Configuration/Endpoint Security policies, Windows Updates, Applications, etc…

Compliance/Configuration/Endpoint Security policies/etc…

For compliance, configuration and for endpoint security protection I basically use the same structure for my naming conventions. Here are some examples:

This is the way I like to structure my profiles in Microsoft Intune, especially when you are starting from a Greenfield (new) setup. It will make your life easier and it’s a great start to deploy it to other tenants and use it as your baseline.

During my Microsoft Intune projects, I use this structure for:

• Compliance policies
• Configuration/Endpoint Security Policies
• Remediation Scripts
• Platform Scripts
• Windows Update rings

But what do those parameters I use mean, let’s get through them.

Explaination

First let me remind you, that this is a way I like to work and these are only examples. Important is to make a structure that fits the needs of your organization.

(Ownership) – (Object) – (Platform) -(Type) – (Purpose) – (Ring)

Ownership

This section is convenient and can be used for several things. For larger organizations that also have branches abroad or organizations that have multiple branches across the country. But also in smaller organizations we can start using this, I am thinking of departments that use different configurations.

• GBL = global and is meant for the entire tenant across all branches, departments, etc..
• BE = is meant for deployment to all branches in Belgium
• IT = is meant for deployment to only the IT department

Object

This is simple and based to what type of Entra ID group the policy is assigned, User (USR) or Device (DVC).

Platform

I also always include the platform to which the policy applies. This gives me a better overview of the total overview of all policies.

• WIN = Windows
• AND = Android
• LNX = Linux
• IOS = iOS
• ….

Type

As it says itself, what type of profile is this? This gives you a view of what this policy has effect on, like Browser, OneDrive, OS, etc…

• Custom
• Browser
• OneDrive
• Operating System
• Account Protection
• Security Baseline
• …

Here you can use whatever type you like. Important is that you know (by the look of it) to what the configuration of this policy applies.

Purpose

In addition to the type, I will also add some details about what is configured, for example.:

• Onedrive – Know Folder Move
• OS – Device Restrictions

Ring (Optional)

In addition you can also add a (Ring) to your policies, so you can have the same policies multiple times. The reason here is that if I need to test some changes in certain policies, I never touch the ones in production to avoid a massive impact. Examples are:

• PRD = Production
• CAN = Canary or test
• DEV = Development (Optional)

Now sometimes I don’t use these, because I’ve noticed that some customers don’t like “unused” policies in their tenant. They more like to temporarily create a policy and do some testing, after testing is confirmed they adjust to the production policy and delete the temp one. That’s why this (Ring) section is also noted as Optional.

Conclusion

Using a consistent naming convention in Microsoft Intune enhances organization, simplifies device management, and improves overall efficiency. It ensures that devices are easily identifiable, reducing the risk of errors and streamlining administrative tasks. I hope this can be useful to you in case you need to have a head start on start using a proper naming convention. The most important thing is, that it must meet your own needs.

So this will cover my second and last part on How to organize your Microsoft Intune deployments like a Rockstar. Stay tuned for more and if you have any questions feel free to contact me! 😉