Best way to provision computers

Not applicable

I've been using Jamf Pro for a while, and have setup many different workflows for different clients over the years, and wanted to open the discussion up for what is, ultimately, the best way to provision computers.

I've often used an enrollment script. To do this, I create a separate policy for each software I want to deploy and add a custom trigger. I then create a policy for an enrollment script that calls all the triggers and runs at enrollment complete and recurring check-in, once-per-computer. This is a great method, because it gives you a lot of flexibility to customize a provisioning workflow, and seems to be standard practice, but I've found several problems with it.

  1. The enrollment complete trigger doesn't always run, which is why I check the "recurring check-in" trigger as well.
  2. If enrolling through DEP, the script can get triggered while the user is still going through the setup assistant. Depending on the policy, it may fail if a user isn't fully logged in yet
  3. If the script takes a while to run, the recurring check-in trigger can be called twice, and the provisioning script may run several times
  4. If the script gets interrupted for any reason, it won't re-run, since it's only set to run once per computer.

Typically, I run this script because it gives me the flexibility to choose when policies run, but you can do the same thing by having all policies run at the recurring check-in (and/or enrollment complete) trigger and name them alphabetically/numerically in the order you want them to run. This method seems to be a lot more dependable, but you can still run into the DEP problem where the policies to install software can run while the user is still going through the setup assistant, and potentially fail.

I know DEP Notify and Splash Buddy's main purpose is to inform the user of the provisioning process, but do either of these tools solve the above issues?

What methods does everyone use to provision computers through Jamf? Have you run into any of the issues I have?

2 REPLIES 2

mm2270
Legendary Contributor III

I have not had any issues using the overall process you outlined, specifically, creating a script that calls all the policies I want to run by their custom triggers, and then using that script in a policy that fires on the Enrollment Complete trigger. For me this has worked just about every time. But I do add a few details to my process to ensure that it works.

For example, as for preventing policies from running before a user is fully logged in, that's not too hard to address. Just add a loop section in your script that keeps checking for the Dock to be running (a good indication that someone is fully logged in), and once it sees that, exit the loop and THEN proceed with running all the other policies. I use something like that in my script and I've never had an issue with it running properly or kicking off too soon and dying.

…you can do the same thing by having all policies run at the recurring check-in (and/or enrollment complete) trigger and name them alphabetically/numerically in the order you want them to run.

I wouldn't use that approach personally. In my experience, having several policies all using the Enrollment trigger ends up causing all kinds of issues. Usually the policies will end up clobbering each other in some manner that causes some of them to fail, and may even stop the entire process of them running at all. Use the enrollment trigger on one policy, and use that policy to run your script that calls all the other ones in the order you want.

Also, I would switch your main policy using the Enrollment Complete trigger to use only the enrollment complete trigger (not check-in too) and use Ongoing for the frequency. And also, in the case of DEP enrollment, be sure to make a Smart Group for Macs that get enrolled using your Prestage Enrollment and use that as the target group (or one of them at least) This prevents your DEP enrollment policy from firing on manually enrolled Macs, like BYO or user initiated enrollments for example. It should only fire on Macs that get enrolled using your specific Prestage or Prestages.

I know DEP Notify and Splash Buddy's main purpose is to inform the user of the provisioning process, but do either of these tools solve the above issues?

I wouldn't say that any of the GUI DEP tools solve the issue of how to get a DEP enrolled Mac to properly run all given policies. That is up to you in how you craft the workflow. Both of these products are really just interfaces to show what's happening, otherwise the process is mostly silent. It also helps, whether an end user or a tech is setting up the Mac, to know when the provisioning process is actually done. Otherwise it may be hard to know, unless you force a restart at the end. A reboot would be a good indicator that it's "done".

garybidwell
Contributor III

Yep, both solve the issue to some extent
Although SplashBuddy (which has now evolved into Ceremory) has a prettier UI for the user, it became too much of a p.i.t.a to keep maintaining if you do a lot of changes, as you need to rebuild it each time and use a special naming convention for all of the packages it installs.
We have just moved over to DEPNotify instead and all driven by using the "DEPNotify-Starter" script provided by the Jamf engineers.
https://github.com/jamf/DEPNotify-Starter
We can now pretty much modify the deployment workflows on the fly by calling any policy by their existing event tiggers and its proved far more reliable with any network issues that arise due to the logs it keeps to record its build status.