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.

Part 2 will be focusing on my naming conventions of everything configured in MEM/Intune.

Azure AD Groups

In every project that I do (that won’t be plugged in in an existing setup with already used naming conventions – because then I will follow the existing naming conventions) I will propose to use my naming conventions.

Some examples:

GRP_MEM_WIN_DD_ALL_Production_Devices

GRP_MEM_WIN_SD_Bitlocker_Exclusion

GRP_MEM_APPS_DU_M365_Apps_for_Enterprise

GRP_MEM_APPS_SU_AutoCAD_2022

GRP_AAD_SITE_DU_BE2

GRP_AAD_CNTRY_SU_BE

As you can clearly see in the examples, there is some structure in it. This gives as an advantage that I can find back groups 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.

Now lets go over some main elements I use:

The first parameter in the naming convention: GRP_

You can clearly see that all my Azure AD Groups start with GRP_.

I don’t think this will need a lot of explanation. We are talking about groups here, so I wanna see immediately at the name of an object, that this object is a group.

GRP_ is only a suggestion, feel free of course to make your own.

The second parameter in the naming convention: MEM_ or AAD_

The second part in my group is either MEM_ or AAD_.

If you see MEM_ in my group, we are always talking about groups that will be used for assignment in MEM (Microsoft Endpoint Manager) / Microsoft Intune. This can be either user or device assignment, but we’ll tackle this topic later in this blog post.

This will be used in assignments of configuration profiles, applications, Windows Update rings, compliance policies. Everything configured in MEM/Intune will be assigned to such a group, with a few exceptions (f.e. applications in user assignment will be assigned to AAD_ groups, because we will populate them as much as we can dynamically based on AAD (Azure Active Directory) attributes of course.

So MEM_ will be used for all assignments in MEM (at device level!).

AAD_ will be used for populating user groups (either static or dynamic).

As you can see, the more parameters we add, the more we bring structure in your MEM/Intune projects.

The third parameter in the naming convention: WIN_, APPS_, SITE_, CNTRY_, …

As you can see we are getting more and more options the further we go in our naming convention.

The four options that I will go over here are only suggestions, the options are limitless so you can of course create more parameters based on your needs of deploying.

WIN_ will speak for itself. This will be a group consisting of Windows devices. And pre-era Win11 I even used W10, but with W11 as the new ‘Windows’ kid on the block, I started making this uniform and just use WIN from now on.

APPS_ also speaks for itself a bit, we are deploying applications to these groups. Does this mean I deploy all my applications to APPS_ groups? Sorry to disappoint you, but no. The required baseline applications that are getting installed in device context (during Autopilot preferably) are assigned to the WIN_ groups with Windows devices in it.

SITE_: here we are talking about a Site or Division or Place (or whatever you wanna call it) of an organization. For smaller organizations this won’t be used. But organizations that have multiple offices in a country, or even are international, this will be used. We will for example put all users of that particular Site in that group, preferably dynamic of course).

CNTRY_: here we are talking about the different countries where an organization has branches or offices. Again for smaller organizations this will be of no use.

The fourth parameter in the naming convention: SD_, DD_, SU or DU

Only four options here. Easy Peasy! Why do I use these parameters then? Because I am lazy and I wanna see immediately by the group name if that group is:

  • Dynamic
  • Static
  • User group
  • Device group

So these are the four options we have:

SD_: Static Device Group. This group will have to be populated manually, and this group will only consist of device objects.

DD_: Dynamic Device Group. This group will be populated dynamically based on a query of device attributes in Azure AD. This group will of course only consist of device objects.

SU_: Static User Group. This group will have to be populated manually, and this group will only consist of user objects.

DU_: Dynamic User Group. This group will be populated dynamically based on a query of user attributes in Azure AD. This group will of course only consist of user objects.

The fifth parameter in the naming convention: can be anything

In the fifth parameter I will describe what will be put in that group. So the options here are limitless.

I will give a few examples to make myself clear:

  • _All_Production_Devices: this group will be populated and all production ring devices will be in it.
  • _Bitlocker_Exclusion: this group will be an exclusion group on the baseline Bitlocker policy (for example for excluding certain users for the removable drive encryption option).
  • _M365_Apps_for_Enterprise: this will be a dynamic populated group where we will query the user license and only deploy certain versions of the M365 Apps to the users who have that license active.
  • _AutoCAD_2022: manually populated group with all AutoCAD 2022 users in it.
  • _BE2: dynamically populated group with all users from a certain location in that country (queried from Azure AD – Azure AD administration has to be in order of course for this to work).
  • _BE: all users from a certain country. Also dynamically populated from Azure AD of course.

So this is how we bring structure in your MEM/Intune projects. Next week I will bring Part 2 live where we will discuss my naming conventions about everything configuration wise (configuration profiles – compliance policies – endpoint protection profiles – …

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