App Installers now available for Jamf School

App Installers is part of the app lifecycle management story and enables educators and Mac Admins alike to stay ahead of the game when deploying and updating third-party apps. Unlike iOS, Mac App Store app deployments are just part of the story since there are many other apps that need to be installed on educational computers that need to be sourced directly from the vendor.

Repetitive app management tasks

This kicks off a not-so-fun-game that requires:

• procuring a vendor-provided package
• tweaking the contents, like adding post-install scripts
• repackaging the software plus all configurations
• and uploading it to Jamf School

where it’ll be ready for deployment. However, once it’s been initially deployed, the game starts anew each time a new update is released. This can be a daunting process that adds a lot of administrative overhead per app per occurrence and we all know that one app that seems to update every other day!

App installers help admins work smarter, not harder

It's very easy for an admin’s time to be engulfed by the third-party app update factory.

App Installers help alleviate admin fatigue when managing third-party apps by providing a workflow that can deliver an App Store-like experience when deploying and keeping apps up to date.

Simply put: the Jamf App Installers team does the work for you, sourcing packages securely from vendors, repackaging them (if necessary) and making them available in the App Catalog for administrators to deploy with just a few clicks. Better still? App Installer-deployed apps are kept up to date automatically just like apps deployed through the Mac App Store.

App Installers, Jamf School’s killer new app

…But, App Installers isn’t new!

If you are sitting here thinking “Wait a second. I’ve heard Jamf talk about App Installers for a while now”, you’re right. Jamf first spoke about App Installers back at JNUC 2021 and this technology was released sometime after that as a review for Jamf Pro. And while it has since gone full release, it's not been available to another Jamf MDM platform until now.

Extending app management support

App Installers was built with the Jamf platform in mind — not just Jamf Pro — and this is an amazing thing for admins tasked with managing Mac on different Jamf platforms.

App Installers is its own service. It's not a part of the Jamf Pro codebase which means Jamf School (and Jamf Now which also recently benefited from this integration) is using the same App Installers service as Jamf Pro. This means the same packages being delivered to Jamf Pro admins are also being delivered to Jamf School admins.

One service, many opportunities

App Installers is one service that benefits the entire Jamf device management landscape: Jamf Pro, Jamf School and Jamf Now.

Example time! Let's take the idea that Google Chrome has recently been updated. The Jamf App Installers team monitors these updates, tests it, and subsequently builds an updated package once. It's then made available to all three platforms, resulting in a better solution that is both cohesive and more robust service than if each platform did this independently of each other.

Focusing on App Installers for Jamf School

If you are Jamf School admin, let’s take a peek under the hood to see how it works, as this is always good from a troubleshooting point of view. If you happen to use Jamf Pro as well as Jamf School, then this will serve as a good refresher. Also, it provides an overview of how Jamf School implements this service, which does have its differences from Jamf Pro.

First, let’s start by looking at how simple it is to integrate App Installers with Jamf School.

Getting Started with App Installers

To get going with App Installers, the service first needs to be integrated. If you’ve ever installed the Scripting Module or connected Jamf School to Jamf Safe Internet, this is something that will be familiar to you.

It's simply a one-click connection to get started.

Once you are logged into your Jamf School instance, navigate to Organization → Settings → Modules, from here you will see the new App Installers module. Click on the module, read and agree to the Terms & Conditions, then click the“Enable App Installers” button.

After the connection is made, a small green banner will appear in the top-righthand corner informing you of its successful integration. Once this simple step has been completed, the App Installers service is connected to your Jamf School environment and you begin making use of it.

Click on the Apps sidebar menu item to reveal the Apps menu, here you will find the new App Installers menu.

When you first click on the App Installers menu, you will see a blank App Installers Inventory until you add the App Installers you want to deploy in your environment.

To browse and add App Installers, click the “+ Add app” button in the top-righthand corner of the window. This launches a new window with a list of all the App Installers available. Navigate to the app you wish to deploy, then simply select the“Add” button next to the app. By design, multiple apps may be selected at once. When you have selected all of the apps required for your environment, select the “Done” button to complete adding your app(s) to Jamf School.

Once you return to the main App Installers Inventory page, you will see the App Installers that you added with relevant information regarding each app. Some of the critical details you will be able to see include the app’s:

• Name
• Vendor
• Version

Including when the app was “Last Updated” by App Installer. When you first add an App Installer it is seen as being“updated”; going forward this this will indicate that the time that has passed since an app has had a new version added to the App Installers service, which follows shortly after an update from the vendor.

Note: There may be a short delay between when a vendor releases a new version and that version becoming available in App Installers. This is expected as this brief pause provides the App Installers team necessary time to thoroughly test, validate and create the App Installers package before making it available for deployment to production environments.

Now that you have App Installers in your Inventory, the next step is to deploy the apps to your devices. This can be done in any number of ways depending on your setup and organizational needs. Not unlike Mac App Store apps or in-house macOS packages, the following methods are available to admins for deployment:

• Directly from the App Installer by clicking on the app name and then selecting the Device Group(s) to deploy to.
• Via a Device Group or Smart Group by selecting the Apps tab in the Smart Group and searching for and selecting the required App Installer(s).
• Directly to a device using the device details menu, choosing apps then searching for and selecting the required App Installer(s).

Currently, when an App Installer is scoped to a device via one of the above methods, it will get installed when the device performs its next check-in. You can see this action taking place when the device checks in by navigating to a device in the Devices → Inventory menu and selecting it to view the device details.

Specific logging data relating to the installation of software deployed by App Installer is available under the “ActivityLog” section. Scan the records, looking for an Action called “Install Application (appName)” for relevant details, like Status, Target, and Date time stamp information.

What if a version of the app already exists on the Mac?

If the app being deployed by App Installers is already installed on the device, don’t worry, this won’t be a problem. Apps needn’t be deployed by App Installers in order to make use of App Installers updating the app in the future.

For example, if the app being deployed by App Installers is a newer version than the one that is currently installed on the device, App Installers will simply update it to the latest version shown in your App Installer Inventory.

How about if the app is currently open or being used during an App Installer update?

Should the app be open and/or in use while App Installer is either deploying or updating the app, the logic built into App Installers will notify the user that the app needs updating and prompt them to close the app.

How do App Installers enforce apps within macOS?

Two words: Configuration Profiles.

You might find, depending on the App Installers chosen to deploy, that devices managed by Jamf School will have an App Installer profile installed for each application scoped. Doing so enforces security and compliance for assigned apps and prevents managed apps from using the vendor’s built-in update ability.

This not only helps preserve the managed app’s settings as configured by Mac Admins but also ensures that the update cycle is managed with App Installers, falling in line with organizational needs and standards. These can be seen either on the device by navigating to System Settings → Profiles; or in the Jamf School console by identifying a device and selecting it to see the Device Details, then choosing the “Other Profiles” tab.

How does the App Installers service work?

Though App Installers deployments work just like Mac App Store app deployments on the surface, it is worth exploring the various elements that makeup App Installers. Breaking down the components enables a better understanding of what is happening on your devices and where to look if you need to troubleshoot.

There are two parts to App Installers:

1. The MDM framework command which delivers the App Installers package;
2. and the magic of the App Installers package itself.

MDM framework command

Like with all other MDM commands, Jamf School uses APNS in order to deliver the InstallEnterpriseApplication command to the device. The command itself simply tells the device that it must download a package from a given place. In our case, the App Installers service.

It's that simple! There’s little more that this command does, but similar to all other MDM commands if your network configuration interferes with APNS traffic, you are likely to experience issues with it (and other management aspects, like Mac App Store deployments).

App Installers package

The proverbial star of the show is really the App Installers package. As mentioned above, the App Installers team programed additional checks, functionality and logic before and after installing an app to make using App Installers such a seamless experience for those tasked with administering Mac educational devices.

In other words, it's more than simply downloading an app from the vendor’s website and copying it to your Mac’s Applications Folder.

Much more…

Once the App Installers package lands on the machine, it:

1. Creates a folder to /Library/Application Support/JamfAppInstallers with all of the resources, it needs for the installation, such as pre- and post-install scripts along with the app to install.
2. Adds a LaunchDaemon which kickstarts the process by running the scripts. Since it's a LaunchDaemon this process will start automatically, regardless of whether a user logged in or not.
3. Logic is then applied, such as checking if the app is already open and waiting until it's closed to install the update.
4. Deployed apps are then moved to the Applications folder before any post-install scripts are run (in case of more complex installations).
5. Clean-up is performed which removes the LaunchDaemon and the specific app folder created within the JamfAppInstallers folder in step 1.

Troubleshooting basics

Given that the MDM command is only responsible for telling the device to download an app from a remote location, it’s the App Installers package that actually installs the app. That said, there may be some times you find yourself needing to troubleshoot.

As stated in the Apple Developer Docs:

“In macOS, the device returns an Acknowledged response after validating the parameters, but before downloading and installing the app. However, it doesn’t notify the MDM server about errors that occur during the installation process.”

Essentially what is being said here is the device will report back to Jamf School that it has successfully received the command and it implicitly accepts that it will download the app. However, this does not mean the download or the installation was successful, sometimes leading admins to a situation where Jamf School shows the app as installed in the Device → Managed App window but the app was not actually installed on the device.

The success of the MDM command should not be inferred as the app was successfully deployed. Instead, it is best to verify that app installation just to be sure.

When issues occur, it’s good to know where on the device we can identify any errors to help fix the issue. The best places to see if the installation is failing are:

Console.app

Open up the Console App on the device and select Start Streaming in the main window. The system can now stream logs for the whole system. To make this simpler, we are only interested in App Installer activity. To limit logs to just this activity, enter com.jamf.appinstallers in the search bar located in the top-righthand corner of the window.

Back in the Jamf School console, select the Reinstall button next to the problematic app.

As you monitor the Console app on macOS, the App Installer process restarts, generating new logs.

Examine each log entry to detect any errors that are happening during installation. However, after selecting reinstall and an appropriate amount of time has passed, if the logs do not start to stream, then the issue is more likely related to the actual downloading of the remote package.

System files

Tucked away in a subdirectory within macOS is the installinfo.plist file which provides information about all MDM-installed applications — regardless if they’re deployed from the App Store, App Installers or custom/in-house macOS packages.

The full location of this directory is: /var/db/ConfigurationProfiles/Settings/Managed Applications/Device/_Completed/. It may contain many plist files, depending on how many apps have been deployed via MDM. Each one is uniquely identifiable by its UUID as the filename.

While it's almost impossible to find out which one relates to the latest install attempt by filename alone, each plist is time-stamped to aid admins in locating the one with the closest time stamp to the most recent reinstall command push. Once you’ve located the correct plist, pressing the spacebar allows a QuickLook at the contents.

Within the plist file, locate the key titled InstallFailed. It will also include a value of either true or false, where the latter means it was successful and the former means it failed. If an error was flagged, you will see the details included as well within the plist.

Note: Depending on the error type, error details may be as clear as stating “Download from failed.” or may require a bit more digging to reveal the root issue that is causing the error to occur.

Does App Installers require any further configuration?

The short answer is no.

Simply integrate the service, add your chosen App Installers and scope to your devices. No more configuration is required for deployment. However, that’s not to say you couldn’t add further configurations to help improve the end-user experience, such as streamlining the installation or update processes.

As previously mentioned, App Installers makes use of LaunchDaemons and other privileged processes, which execute it as a background process. In recent macOS versions, installing via background process and login items is a more transparent action for the end-user. This transparency is present in the form of a notification banner when a background item/process makes a change.

In line with Apple’s doubling down on security and privacy, notifications provide users with awareness when an app is doing something in the background. There are plenty of items that rely on background processes that are completely safe and necessary for system operation. This is especially true in managed environments. After all, admins likely do not want users to stop a background process or login item from running as part of required software (for example, Jamf Connect has items that launch at login).

By default, every Mac enrolled in Jamf School has the configuration required to ensure that the App Installers background processes cannot be disabled by end-users.

ProTip: Admins can further manage the above configuration by going to System Settings → Profiles and looking at the profile named Jamf Background Safelist. Additionally, the display settings for this message can be managed, including suppressing it altogether.

Silencing App Installers notifications

To perform this, a Notifications payload must be created in a profile and then deployed to the managed device.

1. Downloading a tool with a GUI interface, like iMazing Profile Editor or ProfileCreator, is recommended for ease of use but if you like crafting profiles from scratch, that’s okay too.
2. At a minimum, the bundle ID of com.apple.BTMNotificationAgent is required, alongside the NotificationsEnabled payload with the setting configured to false.

ProTip: It's worth noting that the profile above will also suppress notifications for managed login items for other apps installed through management — not just App Installers. If you are already managing background login items from other apps, there's a chance that you’ve already deployed this configuration.

Note: The code snippet below represents the minimum code requirement to suppress notification banners from appearing when App Installers are deployed to a managed device.

Recommended notification settings

However, if choosing to uphold the much-vaunted user experience Apple is known for, enabling notifications to inform end-users when an app needs to quit for an update is a simple way to improve the user experience.

Note: While this is not required to use App Installers, by choosing to not manage this setting, users could intentionally/accidentally turn off notifications for App Installers and not receive these important messages when apps are installed or updated in the future.

Configuring Alerts for critical notifications

Notifications are configured as Temporary Banners, by default. This means they disappear after a short period of time compared to an Alert which requires the user to acknowledge it to dismiss it. To configure Alerts, perform the following:

1. Create the payload of a notification for the domain com.jamfsoftware.selfservice.mac with your preferred notifications delivery preference.
2. Additionally, the custom mcx_preference_settings for the domain com.jamf.appinstallers.notify with a minimum key of notify_identifier and the value of com.jamfsoftware.selfservice.mac is required.

Note: Below is a sample code snippet of the full code required to construct an Alert profile.

While there exists a full list of mcx_preference_settings keys that can be modified to further customize to meet your organization’s unique needs, the minimum required for a universal approach to configuring notifications is found in the code snippet above.

Deploying custom notification profiles

Once you have both configuration profiles saved, they can be uploaded to Jamf School using the Upload custom profile option. Once they’re available in Jamf School, they can be scoped to any devices that you’ll be using App Installers with.

Both of these options are possible today with the additional configuration noted above, but as Jamf School iterates through and improves App Installers integration, these may be baked into the console and no longer required in the future.

One more thing…

Since App Installers ≠ the Mac App Store, it can easily install apps — but there is no way via the MDM framework to remove previously installed apps. If you descope devices or remove an App Installer from your inventory, Jamf School will remove any configuration profiles that were installed as part of that process, however, the app itself will remain — even with the “Remove this app when the management profile is removed” box checked.

At this time, the framework simply does not support uninstalling deployed apps. Fortunately for admins, the best method to uninstall an app is to simply use the vendor-supplied uninstaller or use the scripting module to script the removal of apps that are no longer needed.