DeployStudio and Catalina?


Yes Apple have said for some considerable time that imaging is dead and to use DEP. However It has been possible to use DeployStudio to run the macOS Installer and then a 'normal' DeployStudio workflow and furthermore Apple have failed to provide a means to add pre-DEP purchased machines meaning those machines cannot be DEP provisioned.

I was therefore with Mojave even with T2 Macs able to use DeployStudio to install the OS and then do basic configuration and run the QuickAdd.pkg to enrol.

With Catalina I have got partway but hit problems. (This is to wipe and deploy Catalina on older pre-DEP Macs.)

By having a Catalina boot drive on which is a copy of the DeployStudio Runtime I can connect to the DeployStudio repo and install Catalina via. script which triggers startosinstall and hence this also correctly does firmware updates. I have discovered that to enable scripts and file copy commands in a DeployStudio workflow I need to add /bin/sh to Security & Privacy full disk access. What I am currently stuck on is running 'postponed' installer packages.

It would seem that since these being postponed obviously run within the destination Catalina OS and that had not been told to authorise these processes so they are blocked by its Privacy settings. This is probably not going to be resolvable but it would be worth hearing other opinions.


Valued Contributor

DS is dead, man. Time to move on.

New Contributor III

Even if machines are not DEP enabled, it is easy enough to have a provisioning script in a policy run via enrollment trigger in order to "image" them. Have a dummy file placed via touch for machines that have already run the provisioning script, that way if they ever get re-enrolled, they don't go through the script again. For example:


# Check if script has run before, and if so, exit program
if [ -f "/Library/Preferences/dummyfile.plist" ]; then
echo "script has already run once. Exiting."
exit 0
#run whatever you need to run here
#Create temp file to signal script was run once before
touch /Library/Preferences/dummyfile.plist
exit 0

You can get pretty fancy with this, using different dummy files for different things, even utilizing the API to add a machine to certain groups based on the presence of a certain file. Utilizing something like this means there is literally no need for DeployStudio anymore. To get macOS on a machine, use Internet Recovery or install it from a policy (you can do an erase and install using one click in self service). Check this article out.


What's easier? Running an eraseinstall on a group of Macs, walking through setup assistant, double clicking an enrollment.command file, approving the MDM profile, and walking away? Or banging your head against the wall trying to make tools made for other operating systems and other file systems work for the new one, and even if you get it working they'll only work until next year?