Before we begin:
First of, this will be a series of posts, with the intended goal being to help you, help yourself, when it comes to managing parts of your IT environment.
This goes whether your environment is a small, medium or large. The principles will be the same, the only difference will be the scale of things. In essence, this series will show you some examples of ways you can use things like standardized naming conventions and various groups to organize and manage parts in IT, whether you are on-prem or cloud based.
When it comes to managing anything within IT, it will always be a good thing to keep things organized, in one way or another. You should also make sure that the way you organize things, is made understandable for others as well (maybe you share the responsibility of management with a group, or may do so in the future).
Make it a habit to creating an organizational model that others can jump in or out of over time, that is logical and understandable by others than yourself. Document the logic/model that is defined, and make sure not to deviate from the actual definition as time goes by.
If you have all the responisibility as a single individual, you should still organize as if your share the responsibility with others. This will help you, others and your organization in the long run, to keep things manageable, handle governance, security and documentation, limit mistakes and keeping things efficient as a whole. It may also help you when it comes to automation of various workflows, processes, functions etc.
This first post will revolve around how you can implement a naming convention to keep things manageable and understandable in the long run. I will use examples based on the naming convention that I myself have ended up using over the years, with explanations on how it’s built up, and why. You choose your own design, so this is just to give some ideas to work with.
Naming conventions for groups
We will begin with how you can name various groups in a way that will make it rather easy to understand the function and purpose for the group with a quick glance. Beeing able to do this will make it easier and quicker to work with on a day-to-day basis. After all, we can use groups to give access to pretty much everything these days both in and out of cloud. Beeing able to use groups when assigning permissions to things like printers, file shares, applications, licenses, mdm policies, electronic locks etc, you name it, is a huge time saver – with the benefit of making the manageability across employee roles, functions and a team’s needed resources in an organization. It also helps with the governance side of things.
Whether we are talking about on-prem AD based groups or groups inside services like Microsoft 365 and Azure, the idea will be the same. And in most cases, in both worlds, you will leverage various security groups.
We use the groups to give access to some kind of resource that is needed for a group of users, devices, organizational teams or functions. It is therefore good to name this group in a similar fashion, so it’s easy to add and remove access to the resource on a day-to-day basis on a group based level, rather than on an individual level.
Before you start defining your naming convention, there are some things to get in place first, this revolves especially for non-english based countries, that are not using the english alphabet charactes or have special characters. I’m from Norway, and we have the letters Æ Ø Å that are non-english. This also includes ” ” (whitespace) in some instances.
By experience, we know that the vast majority of IT systems are backed by the english alphabet, meaning those special letters, should you choose to use them, will bite you in the ass at some point in time in the future. So, plan around this, and define how you replace these letters in your naming convention with letters from the english alphabet instead.
On my end for this, the character replacement is like this (standard Norwegian replacement).
“Æ” > “ae”
“Ø” > “o”
“Å” > “aa”
White space replacement for user attributes: ” ” > “.”
White space replacement for groups, resources etc: ” ” > “-”
For group names I use the following naming logic when creating the groups:
Azure AD and On-prem AD:
Group of users with same role: sec-users-“role” i.e: sec-users-sales
Group of users in a location: sec-users-“role”-“location” i.e: sec-users-sales-oslo
Distribution group: dis-users-“recipients” i.e dis-users-sales
Mail enabled security group: sec-dis-users-“recipients” i.e sec-dis-users-sales
Citrix/RDS published application: sec-app-“application-name” i.e: sec-app-microsoft-word
MDM/InTune deployed application: sec-mdm-app-“application-name” i.e: sec-mdm-app-adobe-reader
File share access: sec-file-“fileshare” i.e: sec-file-sales
Printer access: sec-print-“location”-“printer-name” i.e sec-print-oslo-printer-2floor
365 license assignment: sec-lic-“license-type” i.e: sec-lic-m365-e5″
365 dynamic security group: sec-dyn-“users/device”-“targeted members” i.e: sec-dyn-users-sales
365 dynamic distribution lists: ddl-“targeted members” i.e: ddl-sales-team
The logic behind this is rather simple.
sec tells me it is a security group
dis tells me it is a distribution group
sec-dis tells me it is a mail-enabled security group
sec-app tells me it is a security group controlling access to an application
sec-users tells me it is a security group targeting a group of users
sec-dyn-users tells me it is a security group of the type dynamic, targeting user objects
sec-dyn-device tells me it is a security group of the type dynamic, targeting device objects
sec-mdm-app tells me it is a security group used with mdm/InTune to deploy an application
sec-app/file/lic/print tells me the security group gives access to an app, a fileshare, a license/subscription or a printer
ddl tells me it is a dynamic distribution list
In a scenario where a sync from on-prem AD is not involved, I use the same naming convention as above, but I will include aad- before the rest. This is because it’s useful to quickly identify that the group does not come from on-prem. You also never know whether a sync to a traditional AD may show up in the future – better safe than sorry.
I use all non-capitalized letters as a default, as some systems are case sensitive, so defaulting to using non-capitalization removes the problem regardless.
Whitespace is replaced with “-” since whitespace can, in some scenarios create issues.
Some people prefer an underscore “_” instead, you choose yours. The benefit of “-” is that you can then double-tap a word between-two-words, and it will select only that word and not include the “-“.
With an underscore “_” it will, in some cases, select the word and the “_” on both sides, I just find that annoying, so it saves me abit of time when doing a lot of copy+paste+edit.
Some example scenarios:
1: On prem AD, traditional/hybird domain join with 365.
(Prereq: local AD groups synced to 365)
The sales team in Oslo need access to “application 1” (rds/Citrix publised app)
The need to use “printer 2” on the second floor in Oslo.
They also need access to the file-share “sales” and a “Microsoft 365 E5” license.
Group based approach:
You create the following groups
*sec-users-sales-oslo
*sec-app-application-1
*sec-print-oslo-printer2-2floor
*sec-file-sales
*sec-lic-m365-e5
Assignments etc:
You publish “application 1” to the group “sec-app-application-1”.
You add “sec-users-sales-oslo” as a member of the group.
You deploy access to printer 2 via GPO to the group “sec-print-oslo-printer2-2floor”
You add “sec-users-sales-oslo” as a member of the group.
You give the security group “sec-file-sales” access to the file share “sales”
You deploy the drive mapping via GPO with item-level targeting to the “sec-file-sales” group.
You add “sec-users-sales-oslo” as a member of the group.
You assign Microsoft 365 E5 licenses to the group “sec-lic-m365-e5” in the Azure portal.
You get the required number of licenses, so they are available for assignment.
You add the users in the Oslo sales team as a member of the group “sec-lic-m365-e5”.
Sadly, group nesting in AAD is somewhat limited, so you cannot assign licenses to a group that has the licenses assigned, meaning, the users need to be assigned directly to the group that has the license assigned
More details on limitations can be seen on Microsoft documentation here
Last, you add the users of the Oslo sales team to the group “sec-users-sales-oslo”.
Result:
The users then get all the required resources made available, all by adding them to 2 groups.
Super easy to maintain for new users, as well as removing access to old users.
If you later need to check the resources made available to the Oslo sales team, you just check the 2 groups.
2: Pure Azure AD (AAD) joined devices, with cloud based print via Printix
(Prereq: Intune setup, Printix setup with groups synced from AAD to Printix)
The organization has removed all on-premise infrastructure, and taken the move to pure cloud.
Microsoft 365 services are available, InTune has been set up, and the old on-prem print server have been migrated to the Printix service.
The Oslo team is the first to be set up.
Printer queues for the printers named “printer1” and “printer2” in Oslo exists in Printix after migration.
The organization has decided that:
*Management should be kept to a minimum
*Automation should be made where possible
*Sending e-mail to a whole department, across office locations, should be made easy.
The sales team need:
*M365 E3 licenses
*Office 365 package automatically deployed
*Printers should be given to users based on the users location
Group based approach:
You create the following groups;
*aad-sec-dyn-users-sales
Dynamic query: (user.department -eq “Sales”)
*aad-sec-dyn-users-sales-oslo
Dynamic query: (user.department -eq “Sales”) and (user.physicalDeliveryOfficeName -eq “Oslo”)
*aad-sec-lic-m365-e3
*aad-sec-mdm-app-office365
*A dynamic distribution list named “ddl-sales-team” with the email “salesteam@company.com”
https://admin.exchange.microsoft.com/#/addgroupwizard
Set type to dynamic distribution, and set membership rule to departments = Sales in the GUI.
Assignments etc:
You make sure the users in the sales team in the organization has the department field set to Sales and Office set to Oslo in Azure Active Directory.
You assign Microsoft 365 E3 licenses to the group “aad-sec-lic-m365-e3” in the Azure portal.
You get the required number of licenses, so they are available for assignment
You add the users of the Oslo sales team as a member of the group “aad-sec-lic-m365-e3”
Sadly, group nesting in AAD is somewhat limited, so you cannot assign licenses to a group that has the licenses assigned, meaning, the users need to be assigned directly to the group that has the license assigned
More details on limitations can be seen on Microsoft documentation here
You add the users of the Oslo sales team as a member of the group “aad-sec-mdm-app-office365”
Sadly, group nesting in AAD is somewhat limited, so you cannot assign an app to a group that has the app assigned, meaning, the users need to be assigned directly to the group that has the app assigned
More details on limitations can be seen on Microsoft documentation here
Sidenote: Regardless of the fact that this limitation is stated officially, while writing this, I did at test on deploying firefox, to a group, added another group as a member, and then myself inside the neste group. Firefox got deployed on my device with no issue. But let’s keep to the official limitation 🙂
In Printix, you assign the printer queues for printer1 and printer2 in Oslo to the group “aad-sec-dyn-users-sales-oslo” for automatic deployment.
You deploy the Printix client app via InTune to the group “aad-sec-dyn-users-sales-oslo”
You deploy the InTune built in “Microsoft 365 Apps for Windows 10” app to the group “aad-sec-mdm-app-office365”
You can deviate here since the nesting limitations makes this abit redundant, since we already have a group called aad-sec-lic-m365-e3, with users as members due to the limitation.
The deviation may be justified, and saves you some administration in this case.
Result:
The users will get the correct license for M365, and the office package gets installed on their Azure AD joined device.
Printix agent and printer queues for their location gets installed automatically.
The members of the two dynamic groups for the local and org-wide sales team gets updated automatically (pr 24h).
Sending email to everyone in the org-wide sales team is done by sending an email to the dynamic list with salesteam address.
The running management of this is absolutely minimal and hazzle free.
Ending words
It is obvious to see that having a set naming convention to define how you name things, will in the end help you to keep the management side of things minimalistic. You get a kind of “red line” running through things.
This again means you get more time to use on other tasks. It also makes governance and problem solving related to resource permissions a lot less time consuming. Keeping documentation up to date, is also less of a hazzle when you don’t need to document x times variations on the same stuff, but rather have a set template to work from.
I hope you found some inspiration and ideas on how you can organize and design your own naming convention by reading this. What works for me may not work for others, in the end, it’s all about giving some ideas and. Thougts on how this can be used efficiently to your benefit.
PS:
* Dynamic groups is a 365/AAD feature, if you need this on prem, you will have to create some scripted action to update onprem security groups on intervall.
* Caveat around Dynamic Distribution List in 365, is that there is no native way to check who is a member, this can be usefull to verify memberships etc.
If you need to check this, you can do this with the following script on my GitHub found here
Consultant manager & SME @ iteam, localized in Kristiansund, Norway.
Focused on EUC, security, mobility, virtualization, management and a modern workplace. Highly specialized around RDS/Citrix/EUC/Mobility.
