Product Office Hours #8 - Jamf Setup Manager & Checklist - Oct 8th *Q&A in Thread*

This will be good. 🤩

Oooh, i’m excited for this one

👏🏻 Love the two products. Highly recommend for anyone not using it yet.

Thank you for the later start! I’ll be there!

I’m excited and terrified :- ) I started workin on Setup Manager this summer and pushed everything there (security apps + office, browsers etc). Then at JNUC i think it was I heard someone say Setup Manager is more initial setup and checklist should be used to allow users to select what is necessary.  Eager to learn more on this and if necessary pivot. hopefully this won’t cost me a lot of time as I want to deploy before mid November. 

*Friendly reminder this session is one hour later than previous Product Office Hours have been *

​@duff2481-1 Believe I heard the same thing. Be a good question to ask them. My thought is that the tools are for you to do decide what is organizational preferred. 

We have some specific security apps/agents that need to be installed at the beginning. So we need to front load some stuff prior to hitting the desktop.

​@mvu  Agreed, I would rather have all software installed and when the user hits the desktop, they can immediately be productive but will certainly see what checklist might be able to offer us.  

Yeah, same here. I just tweaked some of my Setup Checklist stuff with different wallpaper choices and cleaned up some things. Adds nice final touches and sign in requirements we need.

So we currently use Setup Manager for the exact thing being discussed here, getting all of our core apps installed (security, secondary management, ztna, etc) in order to ensure they are on the device ahead of the user getting to their desktop. Then, we actually still use SYM for things like what the user would like to install tertiary to that based on the role that they chose themselves since they are very different payload bundles for each. 

What I would like to do eventually is remove the need for SYM and just have JSM trigger and be able to query the users identity to be able to choose for them, while still having everything available in Self Service incase items are missing or needing additional things. Then, have Setup Checklist be used for things like screen recording, setting up the office suite (outlook, teams, onedrive), getting finished auth’d into ztna, things of that nature that are annoyingly still a little too manual and popup heavy.

I definitely got up this morning for Office Hours and realized I had the wrong day...

When a profile is in Checklist debug mode, is there a way to reset it to as if nothing has been executed?

Thank you for today’s session.  I had been testing SetupManager and was using cli for testing and validation.  In today’s session there was a comment around using the GUI version for Setup Manager and Checklist that Ian created. 

In finding this utility and importing my plist, I also discovered that you could test and validate on the fly with this utility.  Thank you for pointing this out.  Can we please also include this utility (On-boarding-tool that combines Setup Manager with Checklist?)

 within https://concepts.jamf.com/ not just on https://github.com/Jamf-Concepts/the-onboarding-tool? 

This session covered Jamf Setup Manager and Setup Checklist, with Armin Briegel, Consulting Engineer and core team member behind both tools. Here's every question asked during the session, pulled from both the live Q&A and the chat. 

We currently use macOS Onboarding. Is it Jamf's recommendation that we move to Jamf Setup Manager? When might we be able to configure it natively via the Jamf Pro web UI? No strong recommendation either way, they started out as separate projects with different goals, and the teams building each one didn't even know about the other at first. macOS Onboarding launches after the user is created and can do a few things Setup Manager can't, like watching for Jamf App Installer and VPP app installs, since it runs later in the process. Setup Manager is the right tool if you want a single-touch workflow or want to shield the user from big installs at the very start. If you don't have a strong preference already, it often comes down to which UI you prefer, some installers also don't like running before a user is logged in, which favors macOS Onboarding for those. Plenty of customers run both: Setup Manager for the bulk of installs, macOS Onboarding for anything that needs the user already logged in.  

On native Jamf Pro configuration specifically: not confirmed, but there's a Jamf Concepts tool called The Onboarding Tool (built by Ian Myers) that provides a UI for building profiles for both Setup Manager and Setup Checklist. One other difference worth knowing: macOS Onboarding isn't Site-aware, so Site Admins can't build their own custom onboarding workflows for their individual sites. 

https://github.com/Jamf-Concepts/the-onboarding-tool 

Will Setup Checklist always be a Jamf Concept, or will it one day be configurable via the Jamf Pro web UI? Genuinely don't know yet. For now, it stays a Jamf Concept for the foreseeable future. Every Jamf Concept's goal is eventually to move into the core product, but there's no guarantee or timeline on that yet. 

Can the agreement step be approved or skipped altogether on behalf of the user, so it's one less step for them to click? Yes. Every step in Setup Checklist is entirely configurable, and you don't have to include any given step at all. You could run zero agreement steps, or multiple if your legal team insists. The configuration profile is just a flexible, ordered list of steps, you decide what's in it and in what order. 

Is there a repository for the little video clips used within Setup Checklist, for example, the one showing users how to enable screen recording for Teams? Not an official one, you'll most likely need to build your own since most organizations use a different mix of apps. There are good third-party tools for this, including some free and open source options. One shared by the community: recordly.dev, which can do a cursor zoom effect to highlight exactly where a user needs to click. 

What's the benefit of the onboarding tool versus just using the schemas in Jamf Pro? Mainly the UI. Jamf Pro only recently added a schema for Setup Checklist (Setup Manager has had one for longer), and while the schemas work, the complexity of both tools' profile structure means the Jamf Pro UI runs into real limitations. iMazing Profile Editor is another option some people use to build these profiles, and it has its own different set of limitations. The Onboarding Tool, built independently by Ian Myers, exposes most of Setup Manager and Setup Checklist's features with a lot more flexibility than either built-in option. If you already have an existing Setup Manager or Setup Checklist plist, you can upload it directly into The Onboarding Tool to tweak and reuse, and you can also upload icons to Jamf Pro from inside the tool. 

Are the setup profiles that Setup Manager and Setup Checklist use forward-compatible with DDM? Technically yes, with one current wrinkle. Setup Manager needs its settings available in the pre-stage specifically, since that's where it launches and runs, and declarations can sometimes arrive later than pre-stage profiles do. So while Setup Manager will read settings from a declaration just fine once it's there, the declaration might not have landed in time. The product team is aware of this and working on a declaration equivalent for pre-stage profiles. Setup Checklist doesn't have this problem at all, since it launches well after enrollment is complete, by which point every declaration has already arrived. 

Does Checklist clean itself off the computer after it completes its run? Are there ideas for future workflows beyond enrollment, where it could handle things on behalf of the end user? Checklist is actually designed to be relaunched in the future rather than removed. Every time it launches, it compares current settings against what they should be (is the default browser still set correctly, is Teams screen sharing still enabled, etc.) and only shows the steps that actually still need fixing. So if a user changes something back later, IT or the user can just relaunch the Checklist app and it'll walk through exactly what needs remediating. There's no built-in self-removal mechanism, but a sample script in the repository shows how to remove Checklist manually if you want that at some point. Worth trying the "change something back, then relaunch" workflow yourself, it's a genuinely useful pattern, still being refined, and feedback is welcome. 

https://github.com/Jamf-Concepts/setup-checklist/blob/main/Examples/uninstall.sh 

When a profile is in Checklist debug mode, is there a way to reset it as if nothing has been executed? Not built in today, but there's a sample script in the repository showing how to build a custom reset script, genuinely useful during testing (you'd customize it to your own workflow). This is an area the team is actively working on improving. 

https://github.com/Jamf-Concepts/setup-checklist/blob/main/Examples/resetEverything.sh 

Is there a kind of audit mode for Setup Manager and Setup Checklist, so we can verify they're doing what we expect without wiping and re-enrolling a device? If we inherit a Setup Manager/Checklist implementation, what's good low-hanging fruit to check? And is there anything Setup Manager does that DEPNotify can't? There is a debug mode, but it's mainly for testing that your configuration profile's UI displays correctly, it runs without root access and just walks through the steps on a timer without actually doing anything. To properly test real behavior you need an actual enrollment, since it needs root to function. For auditing what's already deployed: hit Command-L while either tool is running to see a live log. Setup Manager also writes a dedicated setupmanager.log that captures system events it didn't initiate but which are genuinely useful for debugging enrollment timing issues, for example, devices that take several minutes to get the Jamf binary and framework installed. Setup Checklist doesn't have its own log file, it logs to the unified log, which you can pull with the log command (documented in the repository). Reading the configuration profile directly is also a reasonable way to audit what's configured, though the schema's complexity can make that hard to parse by eye. On DEPNotify specifically: it's effectively abandoned now, nobody feels responsible for maintaining it, and while it still works, it won't get future updates. Setup Manager follows current OS UI conventions and has Installomator built in, among other improvements. (If you're inheriting an instance generally, HCS Technology Group's "Jamf Setup Manager: The Complete Guide" and the Jamf Concepts scope-map tool were both recommended by the community for getting oriented.) 

https://github.com/jamf/Setup-Manager/blob/main/Docs/Extras.md#logging 

https://github.com/Jamf-Concepts/setup-checklist/blob/main/Extras/Logging.md 

https://www.hcsonline.com/support/jamf/jamf-setup-manager-the-complete-guide 

We use Setup Manager to install security software before anyone logs in, which works great, but then Setup Checklist opens System Settings while tools like Zscaler throw their own authoritative login prompts on top, and they're hard to hide or kill programmatically. Does it make sense to cache these packages in Setup Manager and use Self Service policy URLs to trigger the cached install as part of Checklist, to control timing better? That question makes complete sense. Caching does save the download step, but since these packages usually aren't huge, the time savings are fairly modest. The real issue is that these apps use launch agents that present their UI immediately regardless of when the package was installed. Checklist's newer focus window mode (which can hide background UI) might help somewhat, you could make a tool like Zscaler your first non-focus-mode step so its prompt is visible at a moment that makes sense to the user. This is still experimental territory industry-wide, some people have figured out how to suppress a tool's launch agent and trigger its prompt on demand instead. If you're using Platform SSO with SSO tokens, some tools can auto-configure themselves so the login dialog never appears in the first place, that's probably the cleanest fix if PSSO is in your environment already. (Community tip shared live: making Zscaler the first step in Setup Checklist helped one organization, and another attendee has a way to make Zscaler auto-configure itself via a configuration profile so users don't have to log in manually, though it still briefly flashes a GUI while it configures.) 

Does the new OIDC integration for end-user sign-in change the enrollment flow? Taking this as a question about Platform SSO: it depends. There are two PSSO enrollment modes, device first (unattended) and identity first (attended). With identity first, user authentication happens before the pre-stage/Setup Manager runs, then user creation happens afterward, possibly requiring a second authentication depending on your IdP's settings. With device first, the pre-stage and Setup Manager run first, then user authentication and creation happen together, though a second auth step or Touch ID/passkey setup may still be needed depending on your IdP. The exact order can shift with updates and varies by configuration. Security teams often prefer identity first, but it's not always the better user experience. Recommendation: test both workflows thoroughly and pick what actually suits your organization. (Flagging: this question may also have been about the Jamf Pro 11.33 beta's new OIDC sign-in feature specifically, rather than Platform SSO, that's still being worked out internally and wasn't fully resolved live.) 

Any news on User Template modifications that work with PSSO? The standard user template strategy, pre-populating files in the user template folder, still works whether or not you're using PSSO. Not something to overuse, since it can slow down first login and occasionally causes odd side effects, but it's genuinely useful in specific cases. One example: you can pre-populate the Launch Services database in the user template to set a default browser without triggering Apple's dialog. It's tedious to maintain, but it works. 

Is there a Setup Manager coming for mobile devices? Nothing confirmed as in development. Jamf Device Checker may partially cover this need already, it lets you check the status of things on a device, though it's unclear whether it can deep-link directly into specific Settings pages. One idea floated: an app could call the Jamf Pro API to set a default browser, calling, or messaging app, which could be a good feature request to log against Device Checker specifically. Worth knowing: iOS no longer allows universal links to open directly into specific Settings app pages the way older iOS versions did, so this is more constrained on mobile than it is on Mac.