Naming Intune policies sounds simple.
Yet it's one of the first things I notice when reviewing an existing tenant. Everyone agrees that naming matters, but few environments remain consistent after a few years.
The reason isn't that administrators don't care. It's that many naming conventions try to solve every problem at once.
A policy name ends up looking like this:
CONTOSO - Intune - P - Dev - Windows 10 - Security - WHFB v1
Every element seems justified on its own.
The result is a name that's long, repetitive, and surprisingly difficult to scan.
Stop Repeating Information Intune Already Knows
CONTOSO
Unless you're managing multiple companies inside the same operational workflow, there is little value in prefixing every object with the company name, you're already inside that tenant !
Adding the company name to every policy doesn't improve readability.
Intune
I've seen prefixes like:
- Intune
- MEM
- MEMCM
- UEM
Again, why?
The object already lives inside Microsoft Intune.
Unless you're exporting every configuration into a shared repository alongside Group Policies, SCCM baselines and other technologies, the platform is obvious from the context.
Windows 10
This is another common one.
If the policy only exists because Windows 10 requires a different configuration than Windows 11, then specifying the OS may make sense.
Otherwise, avoid it.
The assignment, filters, platform column and policy type already provide that information.
Don't duplicate metadata that's already visible elsewhere in the console.
Environment Is Worth Keeping
One field I almost always recommend is the environment.
I've seen many organizations with production policies living next to testing policies without any obvious distinction. That's how test configurations eventually end up affecting production devices.
Use something explicit:
- PRD
- TST
- DEV
- QA
Avoid single-letter abbreviations, writing PRD instead of P costs almost nothing and removes ambiguity.
Device or User?
This one is more debatable.
Some organizations use:
- Device
- User
Others shorten them to:
- D
- U
Personally, I don't consider this mandatory.
Most device-targeted configurations are part of a baseline anyway, and the assignment type is already visible inside Intune. But it's nice to have too.
If you do include it, don't use Dev.
"Dev" universally means Development. Use Device instead.
Functional Scope Matters More
Instead of trying to describe every technical detail, I prefer indicating the functional scope.
For example:
- Standard
- Finance
- HR
- Shared Devices
-
Kiosk
This immediately tells the next administrator whether the configuration is intended for everyone or only for a specific audience.
That's usually far more useful than knowing it targets Windows 11 for example.
Avoid Unnecessary Version Numbers
Another habit I often see is adding version numbers to every policy.
- Windows Hello v1
- Windows Hello v2
- Windows Hello v3
Unless you're genuinely maintaining multiple active versions in parallel, versioning usually creates more clutter than value. Configurations should evolve.
If your change management process is sound, you already have:
- backups
- exported configurations
- documentation
- change history
The policy name doesn't need to become a revision log
Keep It Human
A naming convention should optimize for the people reading it every day.
Not for completeness.
Something like this is usually enough:
PRD - Standard - Windows Hello
PRD - Standard - Microsoft Edge Baseline
PRD - Standard - Microsoft Edge Favorites
PRD - Production - Internet Explorer Baseline
DEV - Production - Internet Explorer Baseline v2
TST - Finance - Microsoft Edge Favorites
If you prefer being explicit about assignments:
PRD - Standard - Device - Windows Hello
PRD - Standard - Device - Microsoft Edge Baseline
PRD - Standard - User - Microsoft Edge Favorites
PRD - Production - User - Internet Explorer Baseline v1
DEV - Production - User - Internet Explorer Baseline v2
TST - Finance - User - Microsoft Edge Favorites
That's already enough information to answer the questions that matter:
- Is this production or a test configuration?
- Is it part of the standard build or a special case?
- Who is it intended for?
- What does it configure?
Everything else can usually be found elsewhere in Intune. Also take in mind, that in the near future Copilot might read those for you, so you really want him to understand the contexte by being simple and precise !
Finally, a good naming convention isn't the one that stores the most metadata. It's the one that lets an administrator understand a policy in two seconds without having to decode a sentence or read a doc.
0 Comments