From Huh to H.E.R.O

[mattjerome]

At some point in your career as an Apple Admin, you’ve (most likely) inherited a Jamf instance and said either to yourself or out loud, “Huh, I wonder why they did that. I certainly wouldn’t do it that way” or “That’s not the best practice I was taught”.  

Caveat: There’s no such thing as best practice. The better concept is defining the best practice for your environment.  

This is where you get to step in and be the hero. It’s your job to take the environment, back it up first. Make sure you backup your instance and sync it to your free Jamf sandbox (If you don’t have one, talk to your rep). Once you’ve backed up and sync’d to the sandbox, I hope you’re noticing the theme here…you can get started with the H.E.R.O. process.  

Something not mentioned is the process of writing documentation. DOCUMENT, DOCUMENT, DOCUMENT. Write down everything from the current state, proposed changes, changes you made (with dates), how configs work, workflow processes, and everything else. The 1st thing after I learn an environment is to make something called a RunBook. A simple, easy to follow guide on how to do the basic tasks within the Mac/Jamf environment. 

In all seriousness, backing up and documenting your instance is crucial as a Jamf Admin. Jamf provides a tool called Jamf Sync to clone your instance to another one and Rich Trouton developed some great scripts here to download your packages as well as xml data for policies, reports, groups, etc. I do this monthly to an external drive kept outside of the office. 

Back to our process. In order to really overhaul an instance you need to take a few steps, easily laid out here.  

• Healthy 
• Efficient 
• Reliable 
• Optimized 

Healthy 

While an MDM environment doesn’t have body parts, organs, limbs, etc. It still needs to be healthy. Get rid of stuff you don’t need i.e. old policies, unused groups, non-relevant reports, etc. Taking the extra time to continuously clean up your production instance (let your sandbox get sick). This routine maintenance will make your job exponentially easier. One thing not to forget here is categories. Categories are an easy item to overlook when setting up policies, configs, and packages. Speaking of packages, another way to keep your environment healthy is to update your pkgs, dmgs, and scripts with notes of when they were uploaded, the version, reason for the change, and who did the change. Finally, remove old items when you don’t need them in your instance. If someone says what if we need that in the future, don’t worry, by this point you know how to back up your packages. A great tool for this is Prune.  

Efficient 

The word efficient can have a lot of different meanings. Some view it as a slimmed down environment, ease of data discovery, good naming conventions, etc. I view it as being efficient with your time in the console. The first thing I do for anyone with Jamf access (level of access doesn’t matter) is instruct them to go to their avatar in the top right -> Account Preferences -> Language & Region and change region, time zone and change Disable Relative Dates to Yes. Relative Dates is what changes the times from “5 minutes ago” to “2:53pm”. I don’t know about you, but the less math I have to do when looking at logs the better. By changing these settings, I’m being more efficient with my time and brain power so I can get more done in a given day with less effort. Next go to the Search Preferences and adjust everything to the most liberal searching possible. This will allow you to search by partial serial numbers/computer names vs getting the content exactly correct. 

Reliable 

Reliability is huge when deploying anything. It doesn’t matter what it is, it has to work consistently. This is actually very easy. It starts with testing and scoping. Test all your policies and configurations before you mass deploy. Use beta testers or deployment groups to verify things work how you expect them to and that it’ll be accepted by your users. You also have that handy sandbox to test in. A handy tool in testing the reliability is utilizing the custom triggers for Policies and self service for Configuration Profiles. Using this allows you to scope to anyone you need and not have it installed automatically. Create a testing matrix for different scenarios including OS versions in your environment, standard vs admin users, new install vs upgrade, etc. It’s better to take it slow and check all your boxes instead of rushing through it and being forced to pull back any changes (ask me how I know). This is also a great training tool for new admins joining your team. This doesn’t just go for policies and configs, tests your prestage enrollments, app installers, software updates via DDM, and Volume purchasing processes as well. It may take some more time, but future you will definitely thank past you! 

Optimized 

If you’ve accomplished H, E and R, you’re well on your way to having an optimized Jamf environment. How do you reach peak optimization? Go back through everything you’d created, changed and updated to make sure you don’t have any redundancies. For example, do you have multiple policies that install the same item? Do your config profiles conflict with each other? Do any policies run multiple times when you really only need them to run once or once per user? A good way to check for this is to get a brand new computer (or a freshly erased one), delete the existing Jamf record and set it up. Once complete, go through the policy and configuration logs to see what actually happens when a computer gets setup. Once you’re happy there, leave it running for a couple days and see what else happens. Doing this process a few times and refining it each time will get you to an optimized state. It’s worth noting here that you can use a VM for this as in most cases, user enrolled vs ADE shouldn’t make a difference unless you're testing PreStage Enrollments. 

Once you’ve done all this and your environment is functioning exactly how you want, and according to your current best practices (yes, they will change). Now is the time to sit back and, frankly, be lazy. Let your hard work and automations do the work for you. Let your work, do your work. This is the time for you to deep dive into all the things you discovered along the way that would be great or fun to do but you just didn’t have the time.  

Here are some ideas for fun to do/good to have projects: 

• App Patch Management 

• Zero Touch Deployments 

• CIS/NIST/Compliance of Choice benchmarks 

• Other items that you thought of along the way