When I start a new ConfigMgr project or when I have the first customer meeting, I always ask if they can give me the naming conventions they use in their SCCM infrastructure.
The top most answer is: Naming Conventions?? We just check other objects and use then a similar name. As you can imagine nearly every object has different patterns. For example, Microsoft is sometimes shortened to “MS”, then written as “Microsoft” and at other places “Microsoft Corp”. This just as an example.
Because of that I created a long time ago (2013) a Best Practice Naming Convention for our customers which is still working for all of them. But now I have updated it to reflect new features which are available in SCCM CB. Mostly there are updated names like Endpoint Protection is now called Windows Defender or that there are more settings which can be deployed than only compliance baselines. Additionally, the usage of OS Upgrade Task Sequences should also get a place in the new structure.
So have a look on it and use it as a starting point in your new infrastructure.
The main benefits of the naming conventions are:
- Single deployment type per collection for more transparency
- Defined patterns allow automatic changes by PowerShell
- All employees have a guideline on how to name collections.
Important to know:
- All variables, like Manufacturer
, SoftwareName “USWR Microsoft OfficeProPlus Prod”.Split(” “)[3], ProfileName , should be written without spaces. Only then the defined sections can be easily retrieved in a PowerShell Script. For example if you take the 4 segment of a Application collection you always get the life cycle status:
- Use always the correct vendor and application names, do not use abbreviations of it, this rises the chance that others are using different names for the same thing.
- If a version has to be included somewhere, always use the real version number and not the marketing version. For example Office is Published as Office 2016, but 2016 is not the real version number. It’s better to use 16.0.4229.1024. If the package you create is always installing the newest version like Office ProPlus, then you can use “Current” instead of a Version Number.
I hope these tips help you to create a streamlined environment.
- Microsoft Sentinel ASIM Parser demystified - March 31, 2024
- Enhancing Network Security Insights with IDS/IPS of Ubiquiti Dream Machine Pro and Microsoft Sentinel - March 10, 2024
- Ubiquiti Dream Machine Pro Logs to Microsoft Sentinel - February 6, 2024
4 Comments
majid · June 15, 2020 at 16:44
Hi, I really like your naming Convention. Can you share some of the screen shots of the collection name in your sccm server. I just like to know how do you upgraded or patch a application.
Thomas Kurth · June 15, 2020 at 22:10
That depends. In a simple environment I have just a Pilot, Prod and Uninstall Collection per Application. If I have a new version I just deploy the new version to the pilot and later to the production. With configured supersedence and removal of the old deployment this works really well. If it’s just a patch. I deploy the patch and create a dependency to the full application.
Does this help?
Andrew Grant · June 30, 2020 at 23:08
Hi Thomas,
Thank you for an excellent article, this gives me what I need to bring structure to the ConfigMgr infrastructure I’ve inherited. I’m new to ConfigMrg, and it didn’t immediately occur to me what USWR etc means. For anyone else in the same boat, here are the meanings:
USWR: User targeted required application
USWA: User targeted available application
DSWR: Device targeted required application
DSWA: Device targeted available application
Cheers
Thomas Kurth · July 1, 2020 at 07:22
Thank you, that is correct.