Take control of Mobile Device Management

Jamf Pro is the most comprehensive Mobile Device Management (MDM) product available for Apple admins. However, the best way to use it can vary based on company growth, IT goals and security requirements.

Katie English, Director of Product Strategy at Jamf, discussed how to optimize organizational Jamf instances during her JNUC 2024 presentation. She reviewed the various management protocols to use with Jamf Pro, reminded attendees of paths for common workflows, and talked about optimizing for your company’s future.

She outlined three contexts for MDM.

Local agent communication from macOS

The local agent is the Jamf Management Framework, and includes Self Service. These are Mac-specific binaries installed on a managed client, and they're idle on the client until prompted to take an action.

These prompts include:

• A launch statement that fires periodically to tell the binary to check in
• A prompt from an end user selecting a button in Self Service to download an app
• Interactions with Jamf Pro policies

All of these client-initiated communications have an inherent few-second delay in the launch daemon.

This type of communication is frequent. Some admins have intervals of every five minutes; the vast majority of these check-ins are only a few kilobytes. They’re checking to see if there's anything new. And while individual policies might be complex, or require significant effort from the management server, they are comparatively infrequent.

Imperative MDM

Imperative MDM is legacy, traditional MDM.

When an admin initiates a command or scopes a configuration profile to a device:

• The management server reaches out to Apple's push notification servers
• It tells those servers to phone home to their management server
• Immediately

A single MDM command might force every single one of an organization’s managed devices to hit the server in a very short time period. Depending on the complexity of whatever admins have told them to do and the size of the required download, this could end up jamming up servers with too many commands and downloads at once.

Imperative MDM has the benefit of being quite fast and the feedback being more or less immediate, but it also has the downside of being indiscriminately fast.

Jamf has been working to enable push notifications for the Jamf Binary, a major component of the Jamf management framework: a local binary on the Mac.

The goal is to get to a point where the binary "phones home" at the right time because the device is in scope for something new rather than relying on automated check-in behavior.

Jamf expects this to radically reduce overall communication to the server and has done some testing with this functionality already. While Jamf has more work to do on this particular feature, there will be more opportunities for beta and testing coming up.

Jamf Remote Assist is an app that lives on the Mac: a local agent that only initiates a remote session after being activated by a local MDM profile. This shares the computational load of imperative communication.

Jamf has matured management contexts over the years:

1. First, Jamf started with client-initiated actions
2. Then, it added in server-initiated actions,
3. Now, Jamf is “crossing the streams” to find a sweet spot between client autonomy and server immediacy

Declarative management

Declarative Device Management (DDM) strikes a balance between legacy imperative ("do this now") while empowering the client to handle its business.

A declaration is a set of instructions that admins ship off to a device. This allows the device to know how to behave under a set of conditions without constantly being told what to do.

Declarative management example: enforced software updates

An admin sets a day and a time for a particular software version to be applied to a particular device. They send it off to the client, and then the client handles everything after that, including:

1. Local time-zone math
2. Local notification and deferral behavior
3. Starting the update process on time
4. Reporting back to the server once it's completed by sending a status report back that conveys new states such as OS version

DDM gives IT the most efficient outcome considering communication versus computational effort.

With any given action admins take, it helps to remember:

• What's happening
• What kind of communication it will require
• Where the computational load will land

How does this impact workflows?

For every workflow, admins must consider scope and implications for timing. Ideally, DDM trends toward providing complex instructions to the client, allowing the client to sort out what it needs to do and receiving a quick heartbeat once it's done.

Unfortunately, this isn’t always possible. The scope of declarations available right now is still getting larger, but is still small. Additionally, figuring out how an admin would optimize a complex workflow is not always intuitive.

To get around this, in some cases, IT can mimic a declarative outcome even if it's not specifically invoked by a declaration.

Jamf Pro’s management protocols

Seeing a few examples of how to use management protocols should give admins a sense of what they might bump into when things tied to common workflows don’t go quite right.

Policies

Policies leverage the local management framework on the Mac. They start by:

• A launch statement
• A script
• A command line in Terminal
• A user taking action that requires the device phone home to ask if anything's new

The server handles scope calculations and hands out the tasks for when the client is in scope and happens to ask for it.

Configuration profiles

Configuration profiles are how Apple admins create a setting for a managed device. If the device is in scope, the management server asks to have that device dial home to pick up a new setting. All managed devices can do this.

Self Service

Jamf’s Self Service can be implemented by a local agent communication or an MDM command, depending on the type of device and the type of content. The content itself could come from an organization’s own infrastructure, or it could come from the App Store.

Software updates

These can get even more complicated. Depending on the flavor of the command, it could be a legacy imperative command or a declaration. In addition, many Jamf admins use scripted workflows to nudge end users.

Apple App Store and App Installers title updates

App Store and App Installer's title updates are MDM commands. It’s up to IT to decide whether to automate these updates or leave them for the user to do in Self-Service, which behaves more like a policy.

Potential workflow problems

Even common, out-of-the-box workflows that admins perform all the time originate in multiple places and use multiple command types. This can mean that it won’t always be easy to anticipate where problems could occur.

Mass actions, for instance, can feel appealing to admins. They click one button and wipe 20,000 devices. Unfortunately, this could overload the servers. And mass actions can run into exception processing difficulties including:

• Devices that are offline
• Devices that don't have enough battery
• Devices that might be in a broken management state already

Any of these factors can create a compound challenge of communication and computation. In this case, the computational needs are heavily on the server to do all the math about the devices that might not respond. It's not obvious, but it can add up pretty quickly.

Sometimes a combination of complex management actions with multiple steps invokes many Smart Group calculations. These amplify the management tasks on the server.

The very nature of — and appeal of — Smart Groups is that IT can add layers of logic such as actions limited to a certain group but also filtered through location considerations and, possibly, permissions. It's easy to start stacking those expensive calculations that can quickly become burdensome on the server.

Better workflow practices

Using policy limitations to an admin’s advantage.

IT can have a maintenance policy that runs once daily but only after 5 p.m. local time. With the inherent client offset and differing time zones this will minimize server load.

This policy could also be set up so the maintenance script processing is handled on the device client itself.

Handling limited device availability

If for whatever any of the reasons above for mass commands to fail on certain devices,

IT can write scripts that periodically target Smart Groups that might not have achieved the status to try again, or use Jamf Pro’s built-in retry logic. The client OS can also be empowered to play catchup with declarative device management.

Forced software update, if it’s offline within an hour of powering on it will update itself.

Fixing errant long-running processes on the Mac

There are various tools and watcher scripts out in the community that will help your client recover, and help the management framework stay healthy in case of a runaway process. An excellent resource for this is Jamf Client Communications Doctor on GitHub.

Adding to organizational infrastructure

For large-scale events, or for particularly sophisticated use cases, IT can augment Jamf Pro usage and workflows with API scripts. Additionally, they can employ bots to build automations based on Jamf Pro events.

The future of Mobile Device Management is declarative management.

Apple has explicitly described declarative management as the protocol of the future. That’s why Jamf has been working hard to implement these tools across our platform.

DDM workflows themselves are currently somewhat constrained; they are very powerful, but they can't do everything that management servers can yet.

What we have now gives us a peek into the future, when a client acts far more autonomously. And declarative management can change the user experience based on:

• Log in context
• User identity
• Declared local assets to prevent, for instance, the round trip of requesting authority to connect to Wi-Fi

We are seeing the beginnings of computational burdens shifting away from management servers and toward devices, which minimizes communication requirements.

Understanding status in Jamf Pro instances

Like management contacts themselves, logging and outcomes are varied across Jamf Pro. For any given deployable object, IT can select it and see the status and logging history of any profile policy or App Installer title.

Apple admins can add those devices to their dashboards to maintain visibility.

They can also:

• Invert the view
• View the device record
• Track particular events
• Scour MDM logging by way of the API

Keep in mind that the act of scouring the log incurs some costs on the matrix of computation and communications, so it’s best to use this sparingly and ensure searches are targeted.

Minimizing the impact of legacy MDM

Configuration profiles, a useful tool for Jamf Pro admins, currently use legacy MDM. And MDM action scoped at scale can occasionally lead to a logjam.

How config profiles work

1. The command starts off as pending
2. The command might stay pending for a while
3. It will end up as completed or failed

What happens with pending commands?

1. Jamf Pro talks to the Apple Push Notification server and asks that a device reach back to the management server for command.
2. The device may, under specific conditions, send back an MDM response known as NotNow. Different things that might evoke this response; a common one is if an iPhone is locked behind a passcode screen.
3. Jamf Pro puts that command in the queue, leaving it pending.
4. Jamf Pro keeps track of pending commands and periodically retries the command by way of a blank push, again asking APNS to have that device phone home to pick up whatever commands are waiting for it.

If a device is offline and not responding to commands, those commands will similarly be put back into queue and retried once the device comes back online. If the command ultimately fails, it's generally for a good reason.

For example, if volume purchasing for an e-book is coded incorrectly or a license has already been used, IT sees a failed profile due to a compatibility issue on a target device. IT might see a pending command ultimately go into an inactive state labeled as "failed."

This is one of the many ways that Jamf Pro is designed to be resilient to potentially thousands of devices communicating and thousands of commands being processed as well as thousands of commands waiting for devices to return to a state where they can acknowledge a command.

By default, the command retry interval is six hours. If nothing else has happened, meaning no new application installation commands invoked by Self Service or Smart Group changes that might put the device in scope for something new, no device inventory update has been requested or the admin hasn't sent an additional blank push.

This is meant to strike a balance between the computational requirements and the communication requirements.

For example: if an Apple App Store application is set to automatically update when a new version is released, Jamf Pro will automatically retry a failed app installation command once every 24 hours for a total of three times. Infinite tries can jam up the server or admins can wait for a long time for an action that simply isn’t going to work.

The tasks of device management are spread out over a number of different kinds of workflows. These workflows can be initiated by the management server or by the client. Because it’s easy to over-index one way or another, admins should find a sweet spot where the communication and computation loads are distributed.

By sharing the load, outcomes will be more reliable. And ultimately, Declarative Device Management will help balance this and make it easier.

As Jamf continues to work on those features, developers are also looking forward to the new features that Apple will be adding in the years to come.