This blog post will describe how to bring structure in your MEM/Intune projects.

For me personally, this is the basis where we all start. Implementing this at the very start is very important, because once your are ongoing and in project mode, and you have already set up x% of the environment, it will be a lot of work putting this in place afterwards.

This is something you can discuss with your clients and plug in in their environment (based on any governance, if there is already some in place). If there is no governance in place yet. You can propose how you do it, and explain why this is so important.

Where do I use this governance/structure/naming conventions in MEM/Intune?

  1. Azure AD Groups
  2. Configuration Profiles
  3. Endpoint Protection
  4. Compliance Policies
  5. Windows Updates
  6. Scripts
  7. Pro-Active Remediations
  8. Applications

As you can see, I will use this through my whole MEM/Intune environment. And all will be structured with the same naming conventions so I can easily find things back without having to open multiple profiles.

I will split this blog post in two parts, and Part 1 will focus on the Azure AD Groups. You can read part 1 here.

Part 2 will be focusing on my naming conventions of everything configured in MEM/Intune. Let’s get on with it!

Configuration Profiles / Endpoint Security / …

In every project that I do I will propose something similar like this as naming convention for everything that is configured in MEM/Intune:

Some examples:

BE – WIN – M365 Apps – Default Edge Homepage (CAN)

BE – WIN – M365 Apps – Default Edge Homepage (DEV)

BE – WIN – M365 Apps – Default Edge Homepage (PRD)

GBL – W10 – Security Baseline – Browser (PRD)

GBL – W10 – Compliance – Default Compliance Policy – Immediate (ALL)

GBL – W10 – Disk Encryption – Default Bitlocker with TPM (PRD)

GBL – W10 – Disk Encryption – Default Bitlocker with TPM (PRD)

As you can clearly see in the examples, there is some structure in it. This gives as an advantage that I can find back configuration profiles easily. Try to take that structure with you to all your projects. Especially for new (Greenfield) environments this is a serious added value.

It will not only make your life easier over time, but you can also start to automate this to deploy this easily to other tenants.

I use this in MEM/Intune for:

  • Configuration Profiles
  • Endpoint Security
  • Compliance Policies
  • Scripts
  • Windows Update Rings

Anything configured in MEM/Intune, except the Apps (we’ll touch that later on).

Now lets go over some main elements I use:

{Ownership} – {Platform} – {TYPE} – {USE} – {RING}

This is the structure how I build up my profiles. Let’s go over everything in detail:

{Ownership}

This is especially handy for organizations in multiple country’s or with multiple branches in a country (or multiple country’s).

We can immediately see where this profile gets deployed too:

  • GBL – : gets deployed tenant wide, across all branches and country’s
  • BE – : gets deployed to all Belgium branches
  • FR – : gets deployed to all French branches
  • BE1 – : only gets deployed to Branch BE1 in belgium

Take care that these are only examples, make a structure that fits the needs of the organization. I like to use the official country codes to make it clear & easy.

{Platform}

Of course I also wanna see immediately which platform we are configuring with that specific profile:

  • WIN : Windows 10/11
  • iOS : iOS
  • Android: Android

{TYPE}

What type of profile is this?

Some examples:

  • Browser
  • OS
  • Security Baseline
  • M365 Apps
  • Drive Mapping
  • Firewall
  • Bitlocker
  • ASR

The options are limitless here. Make sure you immediately know by the look on it, that you know what you are configuring in your profile.

{USE}

Here we will go in detail what we configured of the {TYPE}

I will give a few examples to make myself clear with type next to it:

  • M365 Apps – Productivity Baseline
  • OS – Default Config
  • Security Baseline – M365 Apps Security
  • Security Baseline – OS Hardening
  • Bitlocker – Default Bitlocker with TPM

{RING}

You will also clearly see in my examples on top, that I have the same profiles multiple times. That’s because when adjusting a configuration profile, I don’t want to impact production.

So I’ll always have at least 2 (or preferred 3) profiles:

  • PRD
  • CAN
  • (DEV) – optional

These will also be aligned with our Windows Update Rings, but that’s a blog post for later.

Applications: {appName} – {Version}

For applications I like to keep it more simple. We could do a lot here and also use the ownership tag to see where this application is getting deployed too. But keeping in mind that we also offer applications through the Company Portal, I want my application names short & easy.

{appName} – : Name of the application

{Version} – : Version of the application.

With those two parameters, I know enough.

So stay tuned for more!

Happy testing.

Tim

PS. Keep in mind that my old site will stay online, I’m still contemplating about migrating my old content here, but I’d rather leave the legacy content on my old site. Opinions welcome! Https://www.cloud-boy.be