I was asked last week to think of some practices as a Jamf Admin that I’ve adopted into my environments that have really helped me out. One of the first things that came to mind was organization practices. Organization is key to keeping a clean environment and can help you quickly identify what is being configured and where. I’ve made some notes on how I like to keep my environments organized with naming conventions and will share them below.  
 

Naming conventions will help to keep objects organized, reduce confusion, and help optimize our Jamf Pro platform. As additional policies, configuration profiles, packages, groups, etc. get added to the platform, a consistent naming scheme will provide clarity.  
 

The name of any object in Jamf Pro should quickly describe what it does or what it’s for. Each object within Jamf Pro should also be tied to an appropriate category. Keep it simple.  
 

Static/Smart Computer Groups  
 

What Smart/Static Groups are:  

These are groups within Jamf Pro that can be used to group computers together for the purpose of scoping a policy or configuration profile to that specific group.  
 

What Smart/Static Groups are not:  

These groups are not built for the intention of building reports. If a group is being made without the purpose of having another object scoped to it, then an advanced search should be created instead. Again, these groups are built for the purpose of applying an action, not for reporting.  
 

Keep it organized:  

Within Jamf Pro, Smart Group calculation is a taxing operation on the database, and therefore Smart Groups should/need to be limited to actually providing value.  
 

Computer groups should be named based on what policies or configuration profiles will be scoped to that group.  
 

Note: If a computer is added to a static computer group (manually assigned), the membership will not persist after a computer is removed from Jamf and re-added. Beware that this may cause complications with scoping of configuration profiles and policies if scoped to these static computer groups.  

For any criteria that you are building the Smart Group/Static Group for, you can follow the criteria to match the computer’s inventory record. For example:  

Computer Configuration Profiles  
 

Configuration profiles are used to deliver managed preferences (a configuration) or set of rules to a computer that affects the way the operating system or an application is allowed to be used.  

A configuration profile should quickly identify what the profile is being used to managed. In most cases, the prefix of the profile name will come from the Payload being applied, then use the item that to which the settings will be applied.  
 

Keep it organized:  
 

Use one payload per configuration profile unless the profile requires it (i.e., profiles for 802.1x require the certificate payload and the network payload to work together). Keeping the profiles modular can help for troubleshooting and modification purposes.  
 

Profiles should have a description and be tied to a category. This is important to keep track of what the profile does at a glance and to keep things organized within the Jamf Pro platform.  

When making changes to a configuration profile, please keep in mind:  
 

• If making scope changes, then apply then distribute the change to newly assigned devices  

• If making configuration changes, then distribute the change to all devices  

Below is a table of examples for naming configuration profiles within Jamf Pro:  

Policies  
 

Policies in Jamf Pro are used to install packages, run scripts, and perform various other tasks that can be run once or can be ran ongoing. There are 5 main parts of a policy:  

• Name: The name of the policy in Jamf Pro. The name in Jamf Pro and the name presented to the end-user in Self Service can differ.  

• Frequency: How often the policy is allowed to run  

• Trigger: What causes the policy to run  

• Scope: The computers or group of computers that the policy is targeted.  

• Payload: What is being delivered in the policy.  
   

Keep it organized:  
 

• If possible, avoid creating policies that are Ongoing at recurring check-in without updating the inventory. This will cause a policy to run at every check-in which may not be necessary.  

• Policies that are ongoing and update inventory should be targeted to smart groups that will be affected by the inventory update. For example, a policy to update Google Chrome that is ongoing and updates inventory should be scoped to a Smart Group Outdated App - Google Chrome  
   

Policies should be named so the purpose of the policy is made clear for Jamf Pro admins and for end-users that see the policy within Self Service. Additionally, if a policy is made available to the end-user in Self Service, all information shown to the user should be completely filled, including an icon.  

Any dialog prompt shown to the end-user as a result of a policy should be branded and checked for grammar. This is to help provide a trust to the end-user that what we are delivering to their computer via Jamf Pro is legitimate.  
 

A helpful link for getting icons for Self Service policies: macOS Icons  

 
Attributes  
 

Extension attributes are data fields that can be created within Jamf Pro to gather additional information not included in default computer inventory updates. For instance, scripts can be ran on a computer during inventory updates to gather information, gather LDAP attributes, manually enter a text field, or choose from a pre-populated list.  

EAs are able to be assigned to various sections of a computer’s inventory record. Use best judgement on where the EA should be displayed within an inventory record.  

Extension attributes should be named so they quickly identify the information they are gathering.  

Keep it organized:  

Each EA script ran on a computer requires resources when a computer inventory is updated. No need for script fluff here, keep it simple. If the information asked can be gathered in a different way, use the other way (i.e., user LDAP information can be gathered from LDAP, Application Versions can be gathered from Patch Management, etc)  

An audit of EAs should be conducted quarterly to ensure performance for the end-user is optimized and EAs are not causing issues.  

 
Scripts  
 

Scripts within Jamf Pro can be deployed via script payloads inside of policies. Same with EAs, best judgement should be used when naming scripts. Names should not include prefixes to put them at the top of a list alphabetically. Scripts need to have a category assigned and need to include a brief synopsis of script versions, update dates, and what the script actually does.  

A script should not include any usernames or passwords, information passed in these scripts are plain text and can be intercepted. Even including encoded or encrypted passwords is risky.  

Additionally, any parameters that can be passed into the script need to be defined in the Options tab of scripts. Any limitations should also be defined.  

 
Applications and Packages  
 

Applications in this context is referring to Mac Apps purchased within Apple Business Manager, assigned to Jamf Pro, and made available within Mac App Store Apps. Since the information for these apps is imported from the Apple App Store, keep all naming and information as default. A category should be assigned in Jamf Pro.  
 

Packages uploaded to Jamf Pro should be renamed before uploading to Jamf Pro to the name of the application being installed with the pkg and the version of the app (i.e., jamfConnect-v2.19.pkg). Renaming the pkg before it is uploaded to Jamf Pro will prevent multiple packages in Jamf Pro being named the same. It will also help quickly identify the latest version of packages.  

A category should be assigned to each package uploaded to Jamf Pro.  

The info box can contain any information that can be useful to a Jamf Pro administrator when a package is deployed or uninstalled (i.e., package contains post-install script to activate software).  

The Notes field can contain information on when the package was uploaded and by who (i.e., Uploaded 02.03.2023 by Robert Schroeder or Package created and uploaded 02.03.2023 by Robert Schroeder)  

Advanced Computer Searches  

 
Advanced Computers Searches are used for reporting. If a Smart Group is required to gather information, but will not be used in any scope, use an Advanced Search instead. Searches can be configured to automatically email results of the search and can be saved for later use.  

The criteria for an advanced computer search will come from information held within the computer’s inventory record. Because of this, you can use a hierarchy approach to name your search. For example, if you are searching for computers that do not support the Ventura operating system, you can name your search: Inventory - Operating System - Latest OS Supported - Does not support Ventura. For our advanced searches, our names may get longer but keeping the hierarchy approach will keep things consistent.  

Use your best judgement while naming advanced computer searches.