Here’s five ways to improve your Jamf Pro with these weird old tips …

(I apologise for the click-bait title but a certain Marcus Ransom inadvertently put the idea in my head today. “witty names for his blog posts” indeed! 😀 )

5. Naming Conventions

Name everything (policies, configuration profiles, blueprints etc) in easily readable plain language.

Bonus points for using prefixes on names to help categorize your controls by taking advantage the fact that Jamf Pro loves using alphabetical order for everything.

You want to be able to look at something and high level understand what it is in a few seconds. This is great when you’re looking for something you need to fix that you engineered a year previously and even better when you’re a new hire trying to understand what your predecessors did before you.

4. One Task per Policy / Profile / Blueprint

You have a task. Install some EDR software but the vendor insists you follow some extra instructions before and after you run the pkg on the system.

Not everything can be one shot. A policy that runs runs a script, installs a pkg then runs another script is fine.

What isn’t fine is when you start merging multiple tasks together. Debugging that without breaking something else but possibly related becomes awful if you start doing multiple tasks in one policy, for example.

Think modular in your construction and then remember no.5 above for naming.

3. Categorise All The Things!** (but keep it neat!)**

Placing apps, policies etc into categories keeps things tidy. Opening up specific policy categories can make finding things a lot easier. However you can have too much of a good thing: 10 categories might not be enough but 50 is probably too much.

Following on with naming conventions: your Self Service categories should have plain names. However you can take advantage of Jamf’s alphabetical order penchant by doing things such as:

• 1 – Enrollment
• 2 – Deployment
• 3 – System Config
• 4 – Department Config

That would cover your policies and configuration profiles for management (and keeps them separate and ordered), then you could do the following for Self Service:

• Browsers
• Developer Tools
• IT Support
• Utilities

What I’m saying is keep things neat with categories and your naming of things. Don’t go too overboard though!

2. Focus your API Integrations

This one’s just good security practice.

Make your API integrations specific for it’s application or purpose … and no more. Don’t re-use for multiple applications or you’ll have a bad time when you have to rotate secrets after a 3rd party vendor compromise.

1. Investigate Terraform for IaC

Frankly this is where management is going, and given that products like Terraform aren’t free it’s going to be difficult going there unless your organisation has this.

Being able to have an accurate copy of production in a test instance, make changes without breaking anything and carrying those over to production is a good thing. Having a secure github repo, github branches for test and production, API credentials secured and rotated via Vault, peer reviewed code commits and peer reviewed pull requests that has a lot of attribution and tracking can only be a good thing.

I’d start with #terraform-provider-jamfpro on the Mac Admins Slack first.