If you’re anything like me, I know three things about you:
You’ve seen lots of commercials for medications trying to convince you that you have some medical condition that you don’t have.
You don’t see your doctor enough.
You don’t give your Jamf Pro server the care it needs to make your quality of life look like the “after” shots of the people in those commercials.
Okay. If you don’t think number three belongs in that list, let’s talk about what the Health Check process is, why it’s important, and how to perform it regularly and improve your quality of life.
The year I started with Rocketman was the same year I saw a primary care doctor for the first time in [mumble mumble] years. Yes. Years. My doctor ordered all of the usual tests that one goes through when one sees a doctor regularly. But he also ordered a full battery of other tests to establish just how good (or bad) of shape I was in. And because I am over 40, he added some other tests to which I was not looking forward and you don’t want me to discuss.
How much easier would it have been if I had just kept up with my doctor all along? How many follow-up appointments could have been skipped if I had been aware of creeping conditions before intervention was needed.
Later that year, I joined Rocketman and was introduced to the Health Check that, just like those regular check-ups with a doctor, establishes a baseline of care and determines what treatments are required. Performing that first Health Check kept reminding me how much these two have in common.
Is your Jamf Pro server in good health or does it have an undiagnosed chronic condition? When was the last time you gave it a check-up? Have you reviewed the settings you put in place during your JumpStart training and how long ago was that?
Can you answer the following questions without looking:
Roughly, how many Jamf Pro Administrators do you have? Do they all need their current level of access?
What is your organization structure, and how are computers/devices organized into those groups?
Is your Automated Device Enrollment token, your VPP token, or your Push Certificate expiring in the next month?
If you received a SOC 2 or ISO 27001 audit of your Jamf Pro server, would you pass?
Now look at your Jamf Pro server and go to your list of packages and for each one ask the following:
Who created it and when?
How was this package created? Composer? Direct download from a site?
Where would you go to update the package?
If the answer to any of those is, “I don’t know,” then you are in need of a Health Check.
If you’re still reading, you are thinking, “Okay! You convinced me. I need a Health Check. But how do I do it?”
I’m glad you asked.
When we perform a Health Check for our customers, it’s like those tests my doctor prescribed. We check everything from top to bottom and we document everything we find, good or bad. It’s a time-intensive process that you might not have time to complete once let alone one to four times a year.
So let us prescribe a smaller dose you can definitely swallow. We’ll focus on those areas that tend to get neglected and cause problems first.
Security Checks
First, we’re going to quickly glance at some security measures that should be in place to harden your Jamf server. These are all available in the Settings part of Jamf:
Jamf Pro User Accounts & Groups
Are your accounts local or are you using LDAP or SSO? If you are using local accounts, when was the last time the passwords were changed and do your password requirements meet or exceed your organization’s guidelines? If you are using SSO, your accounts still have local passwords. Were they set up with a single generic password or was each one given a good, secure unique password? Whether you’re using SSO, LDAP, or Standard accounts, do you have an Account Lockout set?
Imagine if a hacker got admin access to your Jamf Pro server. What kind of damage could they do with root access to all your computers?
Jamf Cloud customers: Did you know if you don’t have an account lockout set, you are susceptible to brute force attacks, even if you’re using SSO or LDAP accounts to login?
LDAP Servers
You may not have LDAP configured in Jamf, but if you do, do you have “Use SSL” checked? Do you have “Enable LDAP Proxy Server” checked? If you said no to either of these, and are using Jamf Cloud, you have major security risks. Fixing these are outside the scope of this blog post, but you may want to look into Jamf’s Infrastructure Manager and LDAP over SSL.
Click “Test” on the bottom of the LDAP Servers Mappings tab and do User Mapping, User Group Mapping, and User Group Membership Mapping tests. Are the results what you expected? If not, you may need to change your Mappings.
Change Management
Briefly scroll through Change Management. Do you notice anyone using generic accounts to make changes? All users within Jamf should be making changes with an account tied to their username for the sake of accountability. Backdoor admin accounts should only be used as a last resort.
Security
Now scroll down to “Computer Management” and click on “Security.” Is SSL Certificate Verification turned to “Always” for Jamf Cloud servers? Or to “Always except during enrollment” for on-premise servers that don’t have a trusted 3rd party certificate?
Tip: Having this turned to “Never” is a huge security risk that makes all your computers susceptible to man-in-the-middle attacks.Certificate Expiration Checks
Expired certificates can be bad news, ensure you know when your certificates are expiring next and how you plan to udpate them.
Push Certificates
What is the expiration date of your MDM Push Notification Certificate? Do you know what Apple ID you originally used? Do you have a reminder to renew that is visible to everyone who manages Jamf?
Tip: If your Push Certificate expires you will have to re-enroll all your mobile devices, and you’ll break the MDM Profile on your computers. Automated Device Enrollment
When was your Automated Device Enrollment’s last sync? When is your token expiration date? Do you have a reminder to renew that is visible to everyone who manages Jamf? Do you have access (or know who has access) to your Apple Business/School Manager account to renew the token?
Volume Purchasing
Do you notice a red triangle when you open up this Volume Purchasing? This could mean your Volume Purchasing token is in more than one server. Also note the expiration date, and ensure you have a reminder set to renew it the same time you renew the Automated Device Enrollment token.
Tip: A Volume Purchasing location can only be connected to one MDM server at a time. If you’re connected to two or more servers, this could cause your VPP content to go a little haywire. Performance Checks
Cloud Distribution Point
How much data have you downloaded in the last 30 days? In the last 12 months? Do these numbers seem reasonable for how much you’re deploying the computers?
Tip: Too much data downloaded in a short period of time can be a sign of a rogue policy running too often.Infrastructure Manager (optional)
If you have an Infrastructure Manager server setup, when was its last check-in? Does the hostname and IP address adhere to your organization’s current standards?
Inventory Collection
Sometimes less is more. Are you collecting information with every single inventory update/recon that isn’t necessary to help you manage your devices? If you are collecting fonts, how are you managing them? If you are collecting sizes of users’ home folders, how are you reporting it and what policies do you have in place to control it? As of this writing, Adobe Flash is supposed to die in a dumpster fire sometime this year, but until it does, I’m still gathering all the plug-ins on my computers.
Check-In
How often are your computers checking-in? The default of fifteen minutes is fine for most organizations, but do you need more up-to-date management? Do you have too many devices that even the tiny amount of traffic per check-in multiplied by the size of your fleet has been noticed by your network team?
Organizational Checks
Categories
Take a look at your categories and assess if they are all necessary.
Additionally, create a category along the lines of “Quarantine” (a term with which we are all too familiar these days) where we are going to put anything we can’t immediately identify as necessary and flag it for the phase that comes next.
Buildings and Departments
Buildings and Departments not only allow you to label and inventory your devices based on who has them, but they are one of the types of “Targets” available when you scope your Policies, Configuration Profiles, etc. Are the buildings and departments you have listed helping you determine how to manage devices based on their physical or logical locations within your organization?
Network Segments
Similarly, are your network segments defining which devices should use which distribution points or automatically assigning devices to Buildings and Departments? Network segments are part of the “Limitations” section of Scope and can help you manage your devices efficiently without the need to create overly complex static or smart groups.
Packages
Take a good look at each of your packages. Do they have display names that identify which version they are? Or is that information at least available in the info and notes fields? Can you tell when they were created and how and by whom? If not, move them to the “Quarantine” category you created earlier. We’ll get back to it.
Scripts
Same thing goes here. Also, did you write it or (like many of us) did you find it on Jamf Nation or some other blog? If so, does it say that in the info and notes? And in the script itself, is there a comment header that explains precisely what the script is for? In the body of the script, are there comments explaining what each section does? If not, move it to “Quarantine” and move on for now.
Extension Attributes
This is my favorite feature in Jamf. As a former sometimes database administrator, it makes me weep to see a field in a table being used for something other than what it was intended. Jamf allows us to create any field we want and populate it in a number of different ways.
But not all extension attributes are equal. Script-based extension attributes in particular, are powerful tools to gather information on each computer, but every single time a computer submits inventory, each script-based extension attribute has to run. A badly written script can waste space at best, or do damage at worst.
Make sure you understand what each and every extension attribute is doing for you. Fill in the Description field for each one that you do, and add “Quarantine – “ to the beginning of the name of each one you don’t.
Mobile Device Management
Just like with your computers, make sure the inventory collection and extension attributes you have are all working for you and get rid of what isn’t.
WHEW!
Let me catch my breath here. Maybe my doctor was onto something about needing to exercise more.
Ready? Let’s keep going!
Workflow Checks
For the last leg of our Health Check, we’re going to look over the workflows set up within Jamf. Head over to the Computer tab on top while we go through our Policies, Configuration Profiles, and Groups:
Policies
This is where things start to get interesting. Starting at the top, look at each policy. Click the chevron to the left of the name and see what actions/payloads it performs.
Did the package, script, or printer it previously deployed get deleted, but the policy remained, so it’s no longer performing the work for which it was created? If so, fix or delete it.
Is a policy doing too much? If you have a policy that installs three packages and one of them fails, you have to run the entire policy again, including the packages that already ran fine. Make sure each policy does one action or a small number of related actions and nothing more.
Is a policy doing the same as some other policy, but slightly differently for a subset of your fleet only? Move them into “Quarantine” for now and we’ll keep going.
Are there policies that have no scope or are scoped to a single (test) computer? Quarantine.
Are there policies that are not “enabled” and you don’t know why or when they were disabled? Quarantine.
Policies don’t have descriptions or info/note fields. Consider documenting, with access granted to appropriate team members, the following:
The policy ID number (can be found in the URL)
What it was meant to do
Who made it and when (remember, history only goes back as far as your flushing settings dictate)
Configuration Profiles
Just like policies, take a look at each one and determine what it’s doing. Is it still necessary?
Do you have profiles that do the same things over and over but to different groups of devices/users? Make sure each of your configuration profiles are as lean as you can make them. Better to have 20 profiles, each handling one or two related items (like certificates and WiFi) and scope them to multiple groups.
Unlike Policies, Configuration Profiles have description fields to fill in with all the who, what, when, why, and hows of you’ve been doing so far.
And if you don’t know what it does or what it’s for, move it to “Quarantine” for now.
Static and Smart Groups
For both computers and mobile devices look at your various groups. Ideally, their name should tell you exactly what they are for, but if not, add them to the document we started with Policies.
Are each of your Smart Groups necessary?
Do you have one group that looks for every device that has an application and another that looks for devices without that same application? Just choose within your team if your groups should look for the ideal condition (has the application) or the trouble condition (doesn’t) and scope accordingly.
A policy that installs on every computer that doesn’t have an application is exactly the same as installing it on every managed computer/device excluding the ones that have it. Choose one and stick with it and you’ll have far less to maintain.
ONE MORE DEEP BREATH…
Now that we have everything nice and clean and properly documented, let’s take a look at those items in quarantine.
Like my doctor said, “Don’t worry. This won’t hurt a bit.”
By now you’ve taken a look at everything and you should have an idea of what goes with what. Ready for another really complicated process? Me neither.
Packages and Scripts – If they aren’t being deployed in a policy, document and delete.
Policies – If they aren’t being useful, document and delete.
That’s it. It’s all over.
For now.
That’s right. You may be done for now, but I’m giving you two prescriptions right away:
Prescription #1 – Perform another health check soon. Ideally, I’d suggest once a quarter. But once or twice a year is good, too.
Yes, yes, yes. I hear you! You have a lot to do and unless Jamf just happens to be your primary role, even this one was pretty painful. Like an eight on a scale of one to ten.
But here’s the thing: do the next one in a few months or a year from now and it won’t be that bad! Why not, because…
Prescription #2 – Document everything along the way!
Every package uploaded should have the version in its name. Everything that has a description, info, or notes field should be filled in with everything at the time it is created rather than waiting for the next Health Check. Every policy should be included in that internal document you are keeping.
Then when that ping you’ve been dreading goes off and it’s time to perform another Health Check? No sweat! You’re in. You’re out. Lollipops all around!
Now. If you’ll excuse me, I need to take my pill and get on the treadmill.
At Rocketman Tech, every project starts with a Health Check. Contact info@rocketman.tech for more information.