You may have heard, we built an enrollment tool called Setup Manager for Jamf Pro and Jamf School.
As with any new tool, there are some things that it doesn’t do yet and there are some conflicts with other software that we hadn’t anticipated.
We are working on these things, but it takes time. Until then, I thought it might be useful if there were a way to trigger you own scripts when Setup Manager is finished with its workflow. This wasn’t too hard to put together and I can already see a few useful applications.
How it works
You can use LaunchDaemons to run your own scripts and tools in the background. There are many different triggers you can use to control when your LaunchDaemon launches. One option is a WatchPath which triggers when a file at a certain path is created, deleted or modified.
Setup Manager creates a flag file at /private/var/db/.JamfSetupEnrollmentDone when it completes successfully. We can use this file as a watch path to launch our own script: setupManagerFinished.sh.
In the script, we first set a few useful variables. Since the WatchPath LaunchDaemon triggers on creation, deletion and modification, the script checks first whether the flag file exists, otherwise it just exits without doing anything.
Then the script waits for the jamf binary to not be running anymore. With Jamf Pro, when Setup Manager finishes up, it creates the flag file and then runs its final recon/inventory update. It has to do it in this order, so that an extension attribute that is checking for the flag file gets updated correctly. That means that our script will be triggered before Setup Manager is actually really done. But we can be fairly sure that when the jamf process is done, then Setup Manager has really finished its workflow.
Setup Manager might be still displaying its UI here, but the work is done. (If you want to defer launching until Setup Manager itself quits, you can replace jamf with "Setup Manager" (quotes are important) in line 30.)
Then, we get to the point where we run what we actually want to do. In the sample project, the script runs the jamf binary with a custom trigger. All policies in scope with that custom trigger will be executed. You can even attach a restart action to the last of those policies to force a reboot at this point.
SetupManager and this LaunchDaemon can run with Jamf School, as well. In that case, you wouldn’t run the jamf binary since that is exclusive to Jamf Pro. But you can modify the script to run other commands here to finish the setup.
Chicken, meet egg
You can do additional installations using Installomator, especially for tools that might interfere with Setup Manager. You can send notifications to Slack or Teams with data from the completed Setup Manager workflow.
You can also force a restart here with the shutdown -r +5s command. (The five second delay gives the LaunchDaemon script a chance to clean up and exit.)
Authentication tools, like Jamf Connect or XCreds, need to restart the login window so that their software can load correctly. If you are using the option to run Setup Manager at the login window, this will quit and then restart Setup Manager, too.
Some tools and apps have installation workflows that simply don’t work well with Setup Manager for other reasons.
That means you want to avoid installing these tools with Setup Manager directly, but you can install them after Setup Manager is done.
With this LaunchDaemon, you can run all kinds of additional workflows and install troublesome tools, either with a Jamf Pro policy or Installomator.
Usage
Download the repo and adapt the setupManagerFinished.sh script to your needs. The code you want to adapt is in lines 39 through 47.
The default script triggers a custom policy trigger (setup_manager_finished, defined in line 10)
The buildSetupManagerFinishedPkg.sh script will assemble the LaunchDaemon plist, the script and the installation scripts into a pkg.
You will have to adapt the name of the certificate you use to sign the pkg in line 20. If you do not have a signing certificate, you can set signature="" and the script will build an un-signed pkg. You need a signed installer pkg when you want to add it to the Jamf Pro Prestage or install it with Jamf School. When the pkg is not signed, you can still install it with a Jamf Pro policy with a Setup Manager action. As long as it is installed before Setup Manager finishes, it will trigger when the flag file gets created.
Conclusion
You can find the code on the repository. I am curious what workflows y’all are going to build with this! Let us know in the Mac Admins Slack in the #jamf-setup-manager channel!