Don’t fear the framework

All organizations have their own unique needs and requirements, and sometimes as an Apple admin you may find yourself using a device management workflow that generally gets the job done but isn’t ideal for the way the organization works. In situations like this, having a complete understanding of the Jamf Pro framework can help you to exercise finer control and optimize your management workflows. It may seem confusing, but once you understand a few key ideas, it's easy to start harnessing the full power of the framework.

Jamf director of product strategy Katie English, who you might recognize from the Jamf After Dark podcast, presents a JNUC 2022 session to familiarize viewers with the fundamentals of the Jamf Pro framework. Approaching it in terms of Mac management, there are two distinct “flavors” of tools for macOS. The first is the Jamf binary, and the second is mobile device management (MDM).

What is the Jamf binary?

The Jamf binary is an executable that lives on the managed Mac; it’s an older management tool dating back to the days when Jamf Pro was named Casper Suite. It works by periodically connecting to the Jamf Pro server, “phoning in” and asking whether it should be doing anything. The Jamf Pro server responds with a yes or no, and if there is an action to perform, it tells the Jamf binary what to do: visit a web address, download a package to install, run a script, update the inventory, etc.

Key to the style of communication that the Jamf binary uses is that it originates with the client itself, the binary having been granted root-level access to the Mac when it was installed. The binary mostly works on a schedule, checking in regularly to receive tasks. It can, however, be invoked by the end user (by means of the Self Service app) or by a remote command from an admin that calls the binary by command line or script. This is fundamentally a “pull” style of management.

What is MDM?

The MDM flavor of management is different in that the action starts with the Jamf Pro server itself. When a device falls into scope for a new setting or command, or when an admin issues an MDM command, the server contacts the Apple Push Notification system (APNs) with a request for it to have the device phone home and receive instructions. The device, which is out in the world, maintains a persistent connection to the APNs, so there is no significant delay as there can be with the Jamf binary.

MDM is a “push” style of management, and when an MDM command is delivered, the response from the device should be nearly instantaneous. Obviously, there are advantages to this immediate response time, and all other things being equal, MDM is better for quickly initiating a workflow that you’d like to either conclude quickly or get rapid feedback on.

Policies and MDM

In Jamf Pro, policies constitute a primary type of workflows that the Jamf binary invokes. These include scripts and packages from a distribution point. With MDM, you’re dealing with configuration profiles, MDM commands (both mass actions and device actions) and app installations (through the App Store or Jamf Pro’s App Installers feature).

As a Mac admin, you may want to do something simple like deploy an app along with settings for that app. These are two different actions in Jamf Pro, and for Macs the app and its settings will probably be deployed separately. English gives examples of how admins might handle this deployment, using either policies, MDM or a combination of both.

When you’re deciding what kind of workflow is best, English recommends considering three criteria:

• Scope – There are plenty of good reasons to scope an app and its settings the same, and also good reasons for keeping them different. Don’t feel like you have to create separate scoping logic based on the management protocol you’re using.
• Source – Both the binary and MDM work for deploying content to devices, but you need to think about your desired outcomes. A policy may take longer to initiate but can give you greater flexibility when it comes to end-user interaction and logging your results. MDM is faster for initiating actions, but it can feel like a black box that you can’t inspect until it’s done processing.
• Future – We can expect that MDM workflows to become more mature, and that Jamf workflows will move to MDM-first technology over time, but keep in mind that policies aren’t dead by a long shot.

Using Jamf tools together

You can also extend the Jamf Pro framework by combining it with other Jamf tools. Jamf Protect has its own framework and console, which you can integrate with the Jamf Pro framework; in fact, doing so can reduce the overhead of both systems. While Jamf Connect doesn’t have a specific console to connect to, the cloud services authenticator process is effectively the same way to permit Jamf Pro to automatically deploy and update Jamf Connect to your managed devices, which it accomplished by communicating with the Jamf product package repository. English provides examples here of how this all works.

When a Mac gets into an unhealthy state, it can get to where either the Jamf binary or the MDM profile (usually the binary) stops phoning the server. In this case, you can use an MDM command to redeploy the framework. This essentially amounts to a reenrollment event.

Again, we can look at such workflows in terms of the same criteria used above:

• Scope – When you have multiple product frameworks working together, it is more important than ever to make sure your target device groups make sense. If you’re going to take advantage of Jamf Pro’s integrations, make sure you understand the target groups before you get started. It’s rare for the management framework to require significant maintenance, so if you run into framework failure with any frequency, talk with Jamf Support.
• Source – It’s worth taking the time to think about your desired end state, and you should start by scoping small. You can use automated tools to keep things up to date rapidly, or download packages and distribute them with your own version control in mind.
• Future – As a long-time Apple admin herself, English notes that it makes sense to be wary about automatic update workflows and want to maintain control as you get started. But as you go, don’t forget that automation options exist; you may want to convert and save yourself the effort.

Beyond Mac management

This session primarily deals with the framework as something exclusive to Macs. However, the problems we solve on mobile devices are very similar – we just use MDM exclusively to solve them. English gives examples of this in terms of App Config and per-app VPN.

Final thoughts

English says that in general you and Jamf are going to be most successful moving into the future with MDM, but the Jamf binary is far from dead. When working with scope, you should try to minimize group creation. You can usually use an exception-based workflow for deployments, in which apps and settings are treated identically unless a testing workflow requires some different configuration. The framework can be overwhelming at times, but the advantage is that there are usually about four ways to solve any given problem. So now that you hopefully understand the Jamf Pro framework a little better, it’s time to start finding out what works for you!