Note: everything described in this blog post is a recommendation and guide based on my experience with slow instances. There are more tips to give but consider this a part 1. I'll go over topics one by one, and they may be a bit lengthy at times but bear with me. :D
Installing configuration profiles is fast and easy, however - a mistake is quickly made. Here are a few things why a configuration profile might fail:
- Invalid macOS version
- There already is a profile of the same kind installed
- The profile requires the user to approve the MDM profile
- System error because of an invalid key or connection problems with a connected server like (AD CS, SCEP)
MDM commands are stored in the mobile_device_management_commands (also mdm_command_group and mdm_command_source but they're linked) and are big by nature. Having 30 million rows in this table has a bigger impact than having 30 million records event_logs for example. While it's rare for these tables to be this big, it can happen. Reach out to Jamf Support if you have large tables like this.
Macs that have used the user-initiated enrollment need to be MDM approved. In the management tab, you will see; "The profile must originate from a user-approved MDM server." if the user has not approved the MDM. The profile installation might fail to be installed. There is a couple of things you can do.
- Display a pop-up via Self Service with a guide to enable the MDM for the user.
- Reach out to users affected by making an Advanced Search and guide them to enable this.
If you want to go for the first option you can follow the guide below:
- Create a Smart Computer Group with the following criteria:
Name: User MDM is not Approved
Criteria: User Approved MDM
- Create a policy with the following:
Name: Prompt user to approve MDM profile
Trigger: Recurring Check-in
Frequency: Once every day
Scope: Smart Computer Group - "User MDM is not Approved"
Configure: Files and Processes: "Execute Command: open -a "Self Service"
If the user has not enabled this yet it will open Self Service once every day and show a screen like below:
!! Please note that you need to enable the following two options under: Settings > Self Service > macOS
For more information on how to work with configuration profiles please read my article about it!
Extension attributes are incredibly handy if you want to gather more information than the default displayed for a device. But depending on how often we run an update inventory, it can have a huge impact on the database and, therefore, on your instance's performance.
The information created during an update inventory is flushed with "Computer Inventory Reports" and depending on the current log flush settings, this information can massively build up the database. It's a good idea to limit the amount of data you collect or tone down the number of inventory updates. Remember that you do not need all data at every time of the day. If you're troubleshooting an issue or need data from one specific device and you need that data ASAP, run a "jamf recon".
It's also a good idea to regularly check if your extension attributes are still valid. Don't forget, most of the extension attributes you have may just be scripts. An OS update may break this script resulting in invalid data. While this shouldn't necessarily impact the performance of the instance, it can certainly mess with your workflows. You can run a "sudo jamf recon -verbose" to get a quick reading of this.
And lastly, about extension attributes, consider if you actually want to use them! Your extension attribute may not be valid anymore because you created it either a long time ago, doesn't work, or it's lost its value due to a software change. Keeping this clean makes it easier to figure out what is still active and valuable for your inventory reports.
Smart Computer Groups
There is a common misunderstanding of Smart Computer Groups. Smart Computer Groups were brought to life specifically for scoping or notifying when the membership changes. See below for a few reasons to create a Smart Computer Group:
- Scoping to a configuration profile
- Scoping it to a policy
- Sending a notification upon membership change
And that's mostly it. I know it's tempting and very handy to see those little numbers on the side to know exactly how many people fall into the scope. However, this is not what they're intended for.
Smart Computer Groups always recalculate with every change to keep everything up to date. An update inventory, a change to the criteria, or an API call can all make that recalculation happen. How often and how many Smart Computer Groups you have can seriously slow down your instance. If you have an on-premise testing server, (and I do mean this, only an on-premise testing server) create a few Smart Computer Groups that are linked and contradict each other and watch your server burn down.
Try and take a very harsh look at your current Smart Computer Groups and think; do I really need it or can I put this in an advanced search?
Advanced searches have the benefit that they only recalculate at the moment that you press view. To double down on that, you can even send daily reports to your security team or yourself via email. You can set up how often and at what time, the fields that you want to see, etc.
The API is a great way to automate things that Jamf hasn't made possible via the GUI. Workflows for clearing commands, exporting data, uploading data, anything your heart might desire. But it comes with a downside. It's incredibly heavy for the instance if you over abuse it. Ever heard of DDOS? Yeah, might not come as a surprise but hitting your own API 5 times a second is practically the same as a DDOS attack.
Although it might not be a visible problem yet, it depends on what you do with the API. Just a simple GET call that collects one piece of data might not cause any harm. But remember the Smart Computer Groups? Updating data via the API can cause a recalculation. Say we hit that API 5 times every second for hours, that will grind your instance to a halt. My advice for this is to either limit what you use the API for or put a delay of a few seconds in the calls to slow down the number of calls made.
If you're collecting data from the database via the API, consider using the advanced search option and find a workflow to import a .csv, .tsv, or XML file automatically in your report system. It's not uncommon for people to leverage the API for this. (And yes, I do urge you not to :) )
Set up appropriate log flushing! I know it's tempting to set everything to a year and keep all that data available for when you need it. But consider that if there is an issue, you'll probably know within a week. The sweet spot is 1-3 months for most things. Things like access logs and change management can go over that but think about the last time you needed that information 6 months after it's already been changed.
Remember that if you have any issues with the responsiveness of your instance you should definitely reach out to Jamf Support!
Something you want to see? Something you want to know? Email me at [email protected] and I’ll consider it!
Feedback about my site or content? Contact me at [email protected]