Running Jamf Pro at scale for macOS and iOS devices

Enterprise software giant SAP runs a massive fleet of Apple devices throughout its global presence, so if anyone can provide pointers on how to manage devices at scale, it’s them. In this session from JNUC 2022, IT technology senior consultant Rich Trouton and senior IT consultant John Woll distill the experience of years spent managing tens of thousands of pieces of Apple hardware. Even if you’re already skilled at using Jamf Pro in smaller settings, there’s plenty to learn here. As Trouton says, there are things you can ask Jamf Pro to do when you’re managing 300 devices that you absolutely shouldn’t with 30,000.

macOS infrastructure at scale

SAP runs separate Jamf Pro systems for their macOS and iOS devices, and this session begins by looking at the unique challenges posed by macOS. The advice given here focuses on developing the right infrastructure for on-premises installations; with Jamf Cloud, you can get Jamf to help you iron out the difficulties of scaling up. It also assumes that you’re using a clustered Jamf Pro setup, which Trouton recommends because it reduces the risk inherent in having a single point of failure.

Lesson one of infrastructure is that memory matters. IT admins should proceed by identifying the minimum memory needed for the operating system to run, then quadrupling that number and allocating it to the OS. All other available memory on the host should be dedicated to Java. This assumes that the only things running on the host in question are Java, Jamf Pro’s Tomcat software (which uses Java’s allocation of memory) and the operating system.

On a similar note, processors matter, and the more processor cores you can make available, the more smoothly your system will run. Java is a multithreaded language, meaning it can work on multiple tasks simultaneously, but it will run into bottlenecks if you don’t have enough processors. Trouton suggests viewing Java’s threads as hands and the processors as mouths; it doesn’t matter how much food you can pick up if you don’t have enough mouths to eat it.

One of the key guidelines for infrastructure is to scale up, not out. You’ll encounter better results with a small number of instances equipped with lots of memory and processors than you would with a greater number of low-memory, low-processor-count instances. So start by enhancing your existing Jamf Pro cluster nodes with more processor cores and memory.

Finally, there’s no kill like overkill. That means that it’s always difficult to estimate the level of resources that you’re going to need to allocate to Jamf Pro, especially if you have a rapidly growing population of macOS devices. You should always err strongly on the side of too much, and plan for even more if you’re using virtualization to host your Jamf Pro servers. You can always adjust your processor and memory allocation to match the real-world performance that you experience.

The smallest database is the best database

The more you gather data and grow your database, the more difficulty Jamf Pro will have finding the exact data it needs to do its job. The smaller you keep the database, the better performance you’ll get. By default, Jamf Pro is set to gather application usage data and active services data; but if you’re not using this information for anything, you can slim down your database considerably by turning these features off. It may be counterintuitive to gather less data than what is available, but this is how you can keep Jamf Pro running smoothly while you add more devices for it to manage.

Admins can also look at what is being reported in Jamf Pro by extension attributes. You can save space in the database by using binary code to indicate a status, with a one indicating that something is present and a zero standing for every other condition. So if you have an extension attribute that reports whether a device has a T2 chip, it can send a one for yes and a zero for no.

Jamf Pro stores its logs in the database, which takes up a lot of extra space. You can ship these logs somewhere else to keep the database slim. Trouton says that they send their logs to Amazon’s Cloudwatch service, but there are other good options out there too. One is the Jamf Pro add-on for Splunk, which uses the API to retrieve logging information and send it to a Splunk log server.

Another good practice is to keep the bare minimum of logs in the database. Remember that Jamf Pro always retains the most recent record. Trouton says that he flushes the logs on a weekly basis and would do it even more often if possible.

API usage

As you scale up with Jamf Pro, you’re likely to have stakeholders outside of your team asking for access to the data stored there. Trouton advises some tips for maximizing efficiency of your API. Neither the Jamf Pro API nor the Classic API includes a server-side mechanism for API rate limiting, so it’s important that this is handled in the application sending the API calls. Jamf also recommends having no more than five concurrent connections.

An additional best practice provided by Jamf that Trouton notes here is to use webhooks if your API-using application is requesting data more than once a day. This allows Jamf Pro to notify your application in real time when changes occur. The webhook data will not include all the information usually provided by an API call, so it may be necessary to have your application send a follow-up API call to gather anything more that you need.

Rate limiting is the idea that you deliberately limit how many API commands you send within a defined period of time. Listen to the full session for a detailed anecdote about why this is important!

Considerations for iOS device management

John Woll wraps up the session by providing some considerations from the iOS device management side. SAP has around 90,000 actively used iOS devices on a global scale, and with each one performing a daily inventory update, they get an update roughly once per second. Woll says that whenever they make or schedule changes that affect all devices, they plan for the change to take two to three days to complete. The company has a presence in every time zone around the world, and it is important to make changes that don’t adversely affect employees in a certain region.

It's also important to test any major change in a dedicated test environment. If you have a Jamf Cloud instance, you can create an identical Jamf Pro test server that resembles your production server as closely as possible, or create another Jamf Cloud test instance with all identical policies and configurations. Regardless of how large your device population is, this is a critical measure to have in place to ensure smooth operational changes.

When Woll joined the team, they were about to migrate all of SAP’s iOS devices (about 60,000 at the time) from their existing MDM solution to Jamf Cloud. Developing the Apple@SAP app in-house made it easier for end users to manage the migration on their own. It also helped to make Azure registration with device compliance into a more user-friendly and efficient process.

Finally, it’s crucial for your Jamf Pro admins to develop close relationships outside of the team. This session shares an illustrative anecdote of how cultivating ties with Jamf Support led to positive results in one case. It’s also important to communicate with the IT service desk staff about upcoming changes and known issues. Woll says that if he becomes aware of one issue, he assumes that it will affect at least 1,000 users. Holding regular meetings with the service desk employees to talk through these issues is key to empowering them to swiftly resolve user problems.