The guide to a successful Jamf Pro on-premises upgrade

Introduction

Jamf’s Apple Enterprise Management platform has become the tool of choice for Mac administrators, due to its ability to automate the entire lifecycle of Apple in the enterprise, including device deployment, management and security.

The common trend for Jamf Pro users is to host their instance directly with Jamf in the Jamf Cloud platform. This provides a cloud-hosted management platform with minimal effort, as well as a phone number to call when the back end infrastructure hits an issue. Despite these benefits, certain Jamf administrators need to host their instance themselves, on-premises and/or within their own infrastructure. As with all self-hosted software solutions, an on-prem Jamf Pro setup will need updating – whether for new features, bug fixes or security patches.

dataJAR’s own datajar.mobi platform includes one of the largest deployments of Jamf Pro, numbering in the hundreds and hosted in the dataJAR Cloud, so we go through this process regularly. As a result of this, plus assisting other on-premises customers with their own upgrades, we have gathered our own notes on best practices and recommendations that I thought useful to share.

Planning and pre-testing

What should you look to do before you even start the upgrade process?

Review and plan to upgrade in increments

Jamf has a great knowledge base article exploring which incremental upgrades you should perform if moving from an older version to the current version. This can be found here: Incremental upgrade scenarios for Jamf Pro 10.0.0 or later. I suggest taking the time to have a good read of this and plan, at a minimum, to run through all the updates listed as required. This ensures the Jamf upgrades are performing all the required tasks in between each upgrade and minimises the risk of a failed upgrade. Additionally, if length of downtime is an issue, you could run some of the upgrades in one downtime window, then complete the rest in the next available window.

Review each version’s requirements prior to the upgrade

Carefully review the supporting components and their requirements for the upgrade and plan to action these at the required time. You may need to update Jamf Pro, MySQL or Java first – or indeed a combination of the three. This is especially important when you need to run through a number of incremental upgrades that may require various versions of these components at different points in the upgrade path. Also, do not assume that a much older version of Jamf can run the latest version of each component (e.g. can v10.13 of Jamf Pro work with the latest version of MySQL and Java?). 

Some examples of these requirements (but not an exhaustive list) are:

• Upgrading from Jamf Pro v10.13 or older, to v10.14 or newer requires Java 11+
• Upgrading from Jamf Pro v10.26 or older, to v10.27 or newer requires MySQL 5.7.8+

Again, the Jamf article Incremental upgrade scenarios for Jamf Pro 10.0.0 or later should help here, as well as the release notes for each version, viewable here: Jamf Pro release notes.

Review each version’s release notes for changes

Review the release notes pages for each version of Jamf Pro you will be upgrading to for any known issues or changes that may affect you. The release notes for each version can be found here: Jamf Pro release notes.

A good example is the few tweaks Jamf has made for the APNs changes over recent releases (more information on that from our blog here: Upcoming changes to Apple Push Notification Service (APNs) protocol).

Plan to wait

Some Jamf Pro upgrades make large changes to the database when the Tomcat service is started up. Depending on the changes and size of your database, these can take a long time – occasionally more than an hour or two. Plan for this as part of your downtime and in your playbook for the upgrade work. How long should you plan for? 

Test the upgrades in another environment

It is possible to take your last database backup (you are backing it up, right?), restore this to a second test or development Jamf Pro server and run through the upgrade process in isolation. This should give you an idea of the time the process may take and any issues you might come across. It will also give you the opportunity to ascertain whether your backups are good and usable.

If you go ahead with this, we would suggest cutting all internet access to the test/development server to ensure the restored backup instance cannot send any MDM or other commands out to devices or Apple. 

Create a playbook

There are potentially a great many tasks and steps you would need to follow in order to minimise any issues with the upgrade path; it can be easy to forget something, or perform a step in the wrong order. I would strongly recommend you create a list of the work you will need to do, and in what order.

This should start off as a high level list (backup server, stop Tomcat, install upgrade, start Tomcat), followed by additional sub-steps going into more detail. Your list will also help if you are interrupted or if something goes wrong, enabling you to see exactly what has been completed or not.

Support

Even with this level of preparation, things can still go wrong. It is a good idea to check you have the correct details for Jamf support and know how to reach them should the worst happen. Details for support can be found here.

Before the upgrade

You have completed your research, your testing and have a plan of action – what next?

Backup, backup, backup

Before you even get close to touching anything, take backups of your setup.

• Are your Jamf instance/s hosted on virtual servers? Take VM snapshots.
• Is your database backed up? Run a manual backup and store it somewhere off the server in addition to the snapshots.
• Is your Tomcat directory backed up? Run a manual backup too.

I cannot stress enough how important it is to take these backups. If the upgrade fails in any way, these may save your bacon in more ways than one.

Backup

But you just did a backup? Then backup again. Seriously, if you hit some sort of catastrophic failure, these backups may be the only way to bring things back into working order.

Database pruning

One single element that can affect the time it takes to upgrade (and arguably may also affect the failure rate) is the total size of the Jamf Pro database itself. If possible, we would suggest reducing your database size as much as reasonably possible prior to any upgrade work.

A quick and easy way to find out the size of the various tables in your database is via the Jamf Pro admin console. Login and navigate to ‘Settings’ > ‘Jamf Pro Information’ > ‘Jamf Pro Summary’. Once here, untick all options except for ‘Table Sizes’ under ‘Database’ and click the ‘Create’ button. This will give you a list of all the tables in the database and their size.

Once you have the list of tables you are happy to prune down, pop to ‘Settings’ > ‘System Settings’ > ‘Log Flushing’ and use the ‘Flush’ option in the bottom right corner, picking the time scale to keep as per your requirements.

If you are not sure which tables correspond to which flush option in the admin console, take a look at this knowledge base: Data and tables affected by log flushing

Log a proactive support case

Not strictly necessary, but if you are unsure of the upgrade, or this is your first Jamf Pro upgrade, consider proactively logging a support case with Jamf. They can triple check your process and potentially arrange a suitable time when they can remote in and be immediately ready to help if anything goes wrong.

After the upgrade

You have completed your upgrade and so far everything looks good. What else should you do?

Spot-check

The first suggestion would be to login to the Jamf Pro instance and spot-check a handful of areas to see if anything looks out of place or incorrect – such as a few policies, profiles, smart groups and advanced searches. 

Testing

Grab a spare device and put it through a deployment run with the updated Jamf Pro system. Check it completes without issue and the required software and settings are deployed and working. 

Run through a number of common and/or business critical processes you use Jamf for and check for any issues. Also consider launching the updated Self Service and checking things like icons and branding, making changes where required.

Logs

Consider browsing through your Jamf software server logs and look out for any errors or issues. If you are not sure what to look for, our GitHub repo of what we are monitoring the logs for is a good starting point: JAMFSoftwareServer.log messages.

Summary

Congratulations. You have managed to complete your Jamf Pro upgrade – hopefully without any issues or problems. I hope the above suggestions have been helpful and insightful. If you think you might need assistance, feel free to contact Jamf support, or take advantage of our own professional services engineers who will be more than happy to help.