How Jamf Pro can be scaled to manage hundreds of instances hosted in a hybrid cloud

James Ridsdale, Managing Director and founder of dataJAR, has worked in the Apple space for more than twenty years. He and Ben Toms, otherwise known as @Macmule, Technical Director at dataJAR and Jamf Hall Of Fame award-winner, shared their experience leveraging open-source tools when installing, provisioning and maintaining Jamf instances.

First, Ridsdale outlined DataJAR’s history. The bottom line being – don’t give up.

"My vision is a simple one… to provide a completely scalable and hosted managed service. This will provide organizations with cradle-to-grave lifecycle management of Apple devices. Our focus will be organizations who either do not have the time or resources to support Apple technology or are new to the Apple platform." — James Ridsdale, October 2013

Here they are now, six years on, with 10 remote employees in SE England and a plan to expand the team further in 2020. The UK’s largest MSP for Jamf, with three qualified integrators, a customer base that ranges from farmers to fintechs, and managing over 100 Jamf Pro instances.

DataJAR’s aim is to extend Jamf Pro far beyond what comes in the box. datajar.mobi is their core product, and at the heart of that is Jamf.

Looking at a basic Jamf Pro deployment, your OS is running MySQL, Java Tomcat and lastly Jamf Pro. This is fine until you need to scale up and host multiple Jamf Pro instances as a Jamf MSP.

One option is to run Jamf Pro in a multi-context setup, again one OS. Maybe one MySQL, Java and Tomcat. The difference here is that the root.war is not expanded in Tomcat’s /ROOT folder but with subfolders named after their customers.

To configure the initial Jamf environment, they have set build times. These usually range from two days for a complete iOS/iPadOS/tvOS setup, to three days for a macOS setup. They use a slack channel for the 2FA codes so teams can administer the Apple IDs and ensure they have security and auditing in place.

For configuration, standardization is key. Just because you can do something in 15 different ways in Jamf Pro, doesn’t mean you should.

They use a strict naming convention - categories, profile names, packages and scripts. With a team that works remotely, they need standard practices to stay organised. They also ensure their clients are enrolled into the relevant deployment programs for device enrollment and software procurement.

In 2016, they launched jamJAR, which stands for Jamf AutoPKG Munki. This forms the core of their software distribution platform. Also known as Auto-Update.

The team uses Mac mini headers in their vSphere cluster to run macOS services. On these they run AutoPKG. This will inject the software and add to dedicated client Munki repos.

With 400 titles, how do they know what is available? DataJAR created Munki Catalog Browser, linked from the github.

So how do they remember all the URLs? It starts with Self Service bookmarks, and then they load DataJar’s Jamf switcher app. If an app is not available via VPP, they use Auto-Update (jamJAR) to manage the process.

Transparency is key when it comes to clear communication with their clients. Knowing when things expire, like APNS tokens, means they can’t hit snooze on the alarm.

All datajar.mobi logs are aggregated into Paper Trail, with alerts set for certain messages. These are then sent through Datadog, a monitoring product. Datadog then automatically logs a ticket on Zendesk.

datajar.mobi has an onboarding screen so the user can pick a Mac configuration from a pre-determined list. It’s the same user workflow whether the customer is a school or enterprise business.

The session video will be available soon to watch the onboarding workflow.

As a final sign off, the team encouraged admins to continue to sell themselves. Brand their services to make users comfortable. Create an identity that the end users will trust and recognize.

Further reading

https://github.com/datajar/jnuc2019