Earlier this year I decided I wanted to upgrade our DEP Enrolment workflow, which involved quite a lot of work on the JSS. As I set to work, I found Jamf Pro painfully slow to deal with, and slight changes would result in Macs not enrolling correctly. After much Googling and many tickets to the very patient and helpful support staff at Jamf (Hey Gaurav, Matt, Jamie, it’s me again!) Jamf determined the only way to fix our server was a massive and time consuming clean up. At it’s peak, our Jamf Pro Database was 18gb – for the size of our organisation it should have been about 4gb.
Our smart groups were out of control; there were literally hundreds of smart groups that should’ve been Saved Searches (and Jamf, we need a button that converts smart groups into saved searches) and far too many Matryoshka doll smart groups; groups nested on groups nested on groups. Then there were groups based on Macs not being in other groups. Groupception.
Not only that, Macs were checking in every 15 minutes, and sending back an inventory every day.
No one was to blame here, and I recognised the same issues in my previous role. It seems that way too many smart groups and complex, nested smart groups are a natural outcome of a growing Jamf Server – the awkward teenage years.
When you first start with Jamf, there’s not a lot of overhead you need to worry about, and smart groups seem the most useful way of sorting your fleet. The “wouldn’t it be cool if we knew how many Macs have x” becomes any new reason to create a new smart group. And well, if we have a smart group for Macs with x, we should have another for Macs without x!
But as the fleet grows, you quickly feel the strain of these constantly updating groups. Our poor lil On Prem Jamf Server couldn’t cope.
Finally, I accepted Jamf’s recommendation I began the tedious task of Smart Group clean up. The first thing to look for are any polices that may trigger based on Smart Group membership, you don’t want random policies firing off on a Mac because a smart group it was in no longer exists. Search for policies scoped to recurring check in.
Nested smart groups create the biggest strain, and we had a doozy. Our Labs smart group was made up of 20 something individual smart groups based on Lab name. Then there was a Staff smart group, which was scoped as “Not a Member of the Labs smart group.” I was able to get both down to a single item – based on how the Mac was Prestaged.
I later changed that to an EA that was dropped at Enrolment, and pushed to all current Macs, but that’s for another post.
Then we had “Installed” and “Not Installed” smart groups for every single software title in Jamf Pro. As a university, that is a hell of a lot of smart groups. Thanks to the Reinstall button in Jamf 10, I felt there was no reason to keep these groups, as their main function was to make an App in Self Service disappear after a user installed it.
I deleted each one, but noticed that if i deleted too many Smart Groups in a single setting, the JSS started behaving badly, and I was seeing Self Service and Enrolment issues. So I began deleting overnight – I’d delete about 20 groups a night, then immediately run a database clean up.
On a Windows Server, that is:
Open Command Prompt with admin privilege and type the following:
cd c:\program files\MySQL\path\to\bin
and hit enter and now we are on mysql bin
c:\program files\MySQL\path\to\bin>mysqlcheck -u root -p –repair jamfsoftware
It will ask for root password, so specify it and hit enter.
c:\program files\MySQL\path\to\bin>mysqlcheck -u root -p –optimize jamfsoftware
Another thing to watch out for – make sure your Jamf Scheduled back ups are running, and check them regularly. Jamf cleans up the database during a backup, so you want to make sure it’s cleaning up as you go.
Also, whenever you find yourself on the Jamf server, run this command to delete any push notifications that are stuck on the server. If your push notifications build up, (and if you have multi-user computers like Labs you will) then enrolment can dramatically slow down.
mysql>delete from mobile_device_management_commands where command IN ("DeviceInfoAccountHash","DeviceInfoITunesActive","ProfileList") and apns_result_status="" and device_object_id=12;
I also changed Inventory to run just once a week, and removed recon from any policy I didn’t think needed it. Thankfully, Jamf no longer allows you to create a policy with recon, if it is set as “Ongoing” on check in. Follow that advice.
All up, the clean up reduced our server database down to just over 3gb, and Jamf Pro is so much snappier.