Non-DEP workflow for application installation?

MDS by Twocanoes and the equivalent tool by Apple both leverage the the --installpackage switch of startosinstall to add packages to an OS installation. You might try one of those tools or that switch with your own rebuild script to install an enrollment package produced by Jamf Recon.app . If successful you'd still run into UAMDM limitations, but you'd get basic app installs.

You're not going to be able to avoid some touching of the machines, particularly without DEP. The tools to do that simply don't exist as of this writing, but you can automate quite a bit.

@DanJ_LRSFC While it doesn't help with bypassing the Setup Assistant phase, you can easily use DEPNotify and Jamf's DEPNotify-Starter script to drive a non-DEP workflow for initial app deployment triggered by Enrollment Complete.

As for avoiding Setup Assistant, I always preferred DeployStudio to Jamf Imaging, but I have the feeling it's pretty much EOL as well. MDS from Twocanoes Software sounds like an interesting hardware based tool to automate the interaction with Setup Assistant, but I've not tried it personally.

@DanJ_LRSFC Just like the other the other two has stated, Check out the MDS from Two Canoes.

For my Non-Dep enrolled macs, I used the MDS Two Canoes stick along with an Arduino Device, I personally use the Adafruit Itsy Bitsy - The Arduino allows the computer to login & acknowledge the UAMDM so you can then continue to manage the device in an automated format. Here is a link to my generic Arduino Script - you will need to modify for your environment.

https://github.com/Hugonauts/Arduino/blob/master/MDS-UAMDM%20AIO

My Workflow is as follows.

-Installation Phase.

Mac Deploy Stick contains - OS Installer, Quickadd.pkg for Jamf, 2 API Scripts (Packaged) & placed on the desktop.

The process that it follows is this, OS is installed, Quickadd package is ran (Computer is autonamed by Serial Number option via MDS) & Computer is enrolled in Jamf, API Scripts package is ran & the 2 scripts are placed on the desktop (this is very important)

-First Bootup Phase.

Computer boots up for the first time, the Arduino Script logs the computer in, The arduino script navigates to terminal & runs the first API script as the admin user. This api script moves the device into a group that is scoped to nothing, no configuration profiles & no policies, no nothing & runs a Recon, it pauses to guarantee all configuration profiles are removed from the device. This way, only the UAMDM Profile remains.

The arduino script then closes everything, opens up system preferences & navigates to the Profiles Tab, navigates the MDM profile & approves it.

Then, navigates back to terminal, runs the 2nd API script as Admin. This API script removes it from the Nothing Group & Places it into our Smart DEP Group. This group is scoped to everything as if this were a computer in DEP & our DEP Prestage Enrollment.

Then the arduino script runs a sudo jamf policy -event command to trigger all the policies scoped to this group that would normally occur at enrollment for a Prestage DEP group. Everything is then brought down to the machine, policies & config profiles, etc.

Once completed. Inside Jamf, the final policy to run after everything is successfully installed is a reboot. The computer then restarts & you are now at the login screen as if this computer were just DEP'd. Login & then like the rest of our DEP enrolled machines, depNotify starts & we continue like normal, finishing out the provisioning of our machine.

Hope this helps!

Some really useful stuff here, thanks everyone - I'll have a good look at the solutions that have been suggested.

One thing I don't understand though, which it doesn't seem like any of these solutions currently replicate - how is it that Jamf Imaging is able to get the Mac to skip the first run wizard after rebooting? Is it literally just something like touch /var/db/.AppleSetupDone? EDIT: although no, that can't be the only thing there is to it, I seem to think it actually logs in with a temporary account (used to be called adobeinstall, now called jamftemp I think), anyone know how it creates that and does that?

EDIT: Also, how does Jamf Imaging set the computer name? It would be great if there was somewhere we could just plonk a list of serial numbers and computer names and have them named according to that.

EDIT 2: It looks like user accounts can be created with Greg Neagle's createuserpkg? https://github.com/gregneagle/pycreateuserpkg - will this work from recovery? wait never mind it looks like MDS can create accounts itself?

Also, how does Jamf Imaging set the computer name? It would be great if there was somewhere we could just plonk a list of serial numbers and computer names and have them named according to that.

My current solution is a policy that runs a script that calls jamf setComputerName -fromFile and uses a here file in the script, followed by an inventory update.

However, note that we are now using DEP, moving away form DeployStudio, and thus I don't have much experience with Jamf Imaging.

I walk through Setup Assistant, then run a .command to enroll the Mac in my Jamf Pro server. All of my smart groups are scoped to serial number. The enrollment script triggered by enrollmentComplete renames the machine from a private .csv on my Github, runs a recon, and installs the bare minimum. The Mac reboots after at the end of that, to switch the login screen over to NoLoAD. Then I just wait for check-in.

Note that this is just for my non-DEP lab machines. 1:1 staff are generally all DEP.

@Hugonaut Do you have examples of those 2 API's?

@Hugonaut This solution is very intriguing, but I do not understand how it works.

Do you install and run the Jamf Quickadd.pkg during the initial macOS recovery stage of the workflow, right after the installation of macOS, but before the first reboot of the process? By selecting "While Running Workflow?" Allow the Jamf enrollment profiles to download into the pre-booted macOS installation, allowing the computer to reboot and then have MDS login using a local administrator account created from its initial Jamf enrollment. Next, after the login running your first "API" script to allow the MDS to move the computer into a Jamf group that too enables the approval of the UAMDM profiles. And then, finally, to complete the process, running your second "API" script to move the computer into a Jamf group that allows all of the profiles needed by the computer to execute.

If it all possible, can you share a more detailed description of the process used to do this? Maybe you could post examples of the two "API" scripts that you used to accomplish this. Lastly, perhaps you could even post a video of how this process works? It would be beneficial.

Thank you, and I will await your reply.