You are not logged in.


[2017.09.08] DeployStudio build v1.7.8 (checksum, release note).
[2016.08.26] DeployStudio build v1.6.19 (release note).
[2013.02.23] DeployStudio last universal build v1.5.17 (release note).

#1 Re: Usage » 10.13.2 Netboot Set = Faster Boots » 2017-12-14 03:45:20

Yes; it is not really a "master" in the classic sense.  It is just a machine that has had 10.13.2 installed via an AutoDMG-created OS dmg that has been applied via a DS workflow.  There is nothing custom other than having used AutoDMG to create it.  The AutoDMG-created dmg file will create a fresh 10.13.2 recovery partition when applied to a system via a DS workflow.  Once that step is done, I install the 1.7.8 DS tools and step through DS Assistant as usual.

This has worked for me with 10.13.0 and 10.13.2 (never built one for 10.13.1).

#2 Re: Usage » 10.13.2 Netboot Set = Faster Boots » 2017-12-13 06:29:00

I created an 10.13.2 dmg using AutoDMG (, uploaded it to my DS server, generated a workflow that would deploy the OS.  I then booted  up my newest Mac off from one of my older NBIs, deployed the 10.13.2 workflow that included the AutoDMG-generated dmg, let it do its thing, and then generated the NBI using the DS 1.7.8 tools from this "master" 10.13.2 computer.  Using this method (AutoDMG-generated dmg), you will get an updated 10.13.2 recovery partition as well.

#3 Usage » 10.13.2 Netboot Set = Faster Boots » 2017-12-11 20:14:18

Replies: 5


I built a 10.13.2 NBI today, and if you have not done so yet, I would recommend it.  It was previously taking around 4 minutes for my systems to Netboot off from earlier version of High Sierra.  With the 10.13.2 Netboot set, that is down to about a minute.  Hopefully you see the same in your environment.

Happy deploying!


#4 Re: Usage » ? Folder after High Sierra Reboot - Where to deploy Firmware in workfl » 2017-12-07 20:54:48

If you are trying to upgrade a system that had a pre-10.13 OS on it to 10.13, you are going to have get the firmware upgraded before deploying 10.13.  If the system still has a working OS, you can just create a workflow that simply install the FirmwareUpdate.pkg.  If you have a system with a non-working OS or blank drive, you will need to first deploy something like 10.12.6 autodmg follow by the FirmwareUpdare.pkg.  Then you will need to follow that with your 10.13 deployment workflow.  Essentially, it requires two workflows to do an "upgrade" due to the necessary reboots that need to take place for the firmware update to execute.

That is how I am handling it anyway.  If anyone knows a more simplified process, I'm all ears.

#5 Debug » 1.7.8 w/ 10.13 NBI - Workflow Sleep » 2017-12-07 20:34:36

Replies: 1

Not sure if this a known issue, but it appears that if the workflow takes more than X minutes ... I'm guessing around 15 or so, I haven't timed it ... the system is going to sleep.  This is with a 10.13 NBI.  If the system goes to sleep, the workflow pauses and won't continue until the system is "woken up" again.

I can provide more specific information if necessary but just wanted to see if anyone else has seen similar.  I am considering adding in file to the NBI to see if that would make any difference.



#6 Re: Future » APFS, the end of imaging and the future of DS? » 2017-08-30 04:32:54

I am guessing you ran into this, which I can only assume will require an update to DeployStudio's NBI generation procedure to resolve (likely due to changes in asr to support APFS containers):

"NetRestore in System Image Utility

If you want to create a NetRestore image that you can use to re-install macOS High Sierra on a Mac with all flash storage, don't create the image from the macOS Installer. Instead, connect another Mac with macOS High Sierra via Target Disk Mode, and use it as the image source. The resulting NetRestore image will be APFS, and is only supported to re-install macOS High Sierra on a Mac with all flash storage."

I believe this means there will need to be 2 separate NetBoot sets, depending on if you need to NetBoot a Mac with a HDD or a Mac with a SSD, in order to apply your workflow to the appropriate partition.

#7 Re: Future » Future of DeployStudio?? » 2015-10-29 00:20:42

Thank you for the update!  We appreciate your contributions to the Mac community!

#8 Re: Future » Future of DeployStudio?? » 2015-10-26 18:03:26

There is a place in France that has a training session up for using DeployStudio with El Capitan slated for mid-November.  While it may be wishful thinking, I don't think they'd continue selling training on a dead technology.

#9 Debug » Issue w/ OS X v10.10.4 & DS 1.6.15 » 2015-07-01 13:35:26

Replies: 30


I am experiencing an issue with a new NetBoot set built for OS X v10.10.4 using DeployStudio Assistant v1.6.15.

Upon boot to the Netboot set, I repeatedly am receiving a "unable to connect to server" error when using the DNS name.  If I switch over to the IP address, there is about a 30 second delay after entering my credentials (compared to about 2 seconds pre-10.10.4), and then the connection is finally made.

For what it's worth, everything works fine with my OS X v10.10.3 Netboot set and my OS X v10.9.5 Netboot set.

The server is running OS X v10.7.5 Server.

My early assumption is that a patch may be needed to support OS X v10.10.4.



#10 Re: Install » Nightly in Production » 2014-01-03 16:18:26

Thanks for the replies!

Strawgate, when you are building your Netboot set, are you using the 1.6.3 DeployStudio Assistant and just checking ignore version mismatch before uploading to the server?  The 1.6.0 Assistant doesn't work with Mavericks.

#11 Install » Nightly in Production » 2014-01-02 20:58:18

Replies: 6

Is anyone using the latest nightly build in production?  We have received around 50 of the latest models of laptops and iMacs and will soon be receiving around 20 Mac Pros.  These will all be needing Mavericks v10.9.1.  I am currently debating between using 1.6.3 and the nightly build to upgrade my production server which is currently at 1.6.0.  Unfortunately, I have to have this working by end of next week.

Any suggestions?

#12 Re: Debug » Nightly Build & iMovie 10 » 2013-11-14 20:00:40

No file copy errors either in the DS logs or system logs.  Oddly, I was able to get it to work successfully yesterday.  As this time, I am going to classify it as an intermittent issue.  As a result, I believe it may either be an issue with hard drive from which I was creating the clone or with the August 16, 2013 build of hdiutil.  I will report back if it happens again as I move forward with completing the production build.

#13 Debug » Nightly Build & iMovie 10 » 2013-11-06 18:46:27

Replies: 2

For the developers:

It appears the current nightly build is stripping out the following file from iMovie 10 under Mavericks when included as part of the image:


This causes the app to crash immediately upon launch.

If the file is on the master Mac prior to executing the default Create a Master workflow from the DeployStudio Runtime, it is removed from the DMG.  You can verify this by comparing the resulting DMG to the original disk.

Oddly, it only seems to impact iMovie, not iPhoto, iWork apps, or Garageband.

If you manually return said file to its original location from a known good copy of the application, it launches normally.

If you try to create a disk image of through Disk Utility, the file remains in place.

The only way I have been able to replicate the behavior is through the previously described workflow.

#14 Re: Usage » Netboot Image Creation » 2013-11-05 15:25:49

I would create a 10.6.8 Netboot set on one of your 10.6.8 clients (with the combo update of 10.6.8 installed) using the Setup Assistant and then copy it up to your server's Netboot set repository (/Library/NetBoot/NetBootSP0).  You could use the one created for 10.8.5 on the server, but only if the machines you are imaging can support booting to 10.8.5; otherwise, you need to boot off an older version of the OS (10.6.x, 10.7.x, etc.).  I've had the best luck Netbooting machines off the major OS X version that the machine shipped with initially; sometimes trying to Netboot a machine that shipped with 10.6 off a 10.8 Netboot set seems to not work for me.  This has been particularly true with Mac Pros which seem to love Netbootng from 10.7.5 but not 10.8.5 for some reason.

I keep around one Netboot set for the last versions of 10.5, 10.6, 10.7, and 10.8. just for this purpose (i.e. supporting old hardware).  The oldest ones mainly so we can wipe the hard drives of retired machine using Disk Utility via DS.

#15 Re: Usage » 10.8.3 works fine with DS 1.5.17 » 2013-03-15 15:01:40

Just for reference, it is not working with DS 1.0.rc135.  You can create a netboot set, but when you try to boot from it, you get to the DS screen, the screen flickers a few times, and then the machine reboots.

Looks like an upgrade to DS 1.5.17 may be required if you want to netboot to 10.8.3.

Note:  This was when tested against a Late 2012 21.5" iMac.

#16 Re: Usage » Any known issues with Fusion drive? » 2013-03-14 15:27:13

I just got bit by this sort of thing yesterday with a 1TB Fusion drive in an iMac.  Thanks for the info!

#17 Usage » Updating NetBoot Sets » 2012-11-21 14:56:51

Replies: 2

The last three times I have updated DeployStudio on my server, I always receive a message at the end that says "The NetBoot sets XXX.nbi cannot be updated.  Please check the installer logs for more details.".  Is there some special sauce I am missing that makes it so that your netboot sets get updated automatically?  I have been recreating them from scratch everytime I upgrade the server, and it is fairly time consuming, because I keep one 10.5.8 PPCs, one for 10.6.8 for older Intels, one for 10.7.5, and now also one for 10.8.2.  Is there an easier way, or is this what most people have to go through?  I feel like I am missing something obvious here, but perhaps I am not.

#18 Debug » 10.6.2 /.Trashes Ownership » 2010-02-04 23:22:49

Replies: 1

I just wanted to report a potential bug in the handling of the /.Trashes directory when creating a new image in 10.6.2.  It appears that the owner of the /.Trashes directory is not being properly updated prior to being converted to a .dmg.  If I view the image as it is being created as a temporary device in /Volumes, the ./Trashes is being assigned the owner and group of the user creating the image instead of maintaining the owner and group settings of the master.

I can manually change this during the image creation with chown; however, it might be something worth considering adding as a check before converting to the .dmg file.  The correct owner/group appears to be root:staff.  If this not set on a newly imaged system, the owner/group appear as _unkown/_uknown unless the user/group you created the image also exist within the image you are creating.

The downside to this not being set is a log file full of notifyd EV_DELETE failed errors.  I haven't seen other problems, but if you like to keep a fairly useful system.log, it's worth the effort.


Board footer

Powered by FluxBB