You are not logged in.

Announcement

[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: Debug » Mojave error trying to make NetBoot set » 2018-12-27 12:12:20

@mlevit

I believe technically it should be possible to create a Mojave bootset in the way DeployStudio has done so for versions up to and including High Sierra but it would require the developers updating their software to support doing this.

With Apple having made it clear they don't want people to do imaging anymore it is looking like the DeployStudio developers have given up.

At the moment the only solution possible for the latest T2 Mac models requires a full blown Mojave installation as a normal boot drive via which you manually run the DeployStudio runtime tool. On a USB memory stick this is extremely slow to boot compared to a DeployStudio created High Sierra bootset on the same USB memory stick but it does work. On a USB hard drive it is normal boot speed.

So to confirm you can do imaging and a full DeployStudio workflow but you have to boot from a full copy of the Mojave operating system.

#2 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-11-09 16:11:45

@carlocarlo

Ok, I received my Mac mini 2018 which only supports using Mojave. I created a standard external Mojave boot drive and installed DeployStudio Runtime on it. I was able to run then the DeployStudioRuntime and try various permutations of my previous script to use the startosinstall command.

My results and comments can be viewed here - https://jelockwood.blogspot.com/2018/11/apple-really-dont-want-you-to-use.html

To summarise. Apple supposedly removed the --volume option in High Sierra, for some reason it still works in a DeployStudio created High Sierra Runtime image. Since DeployStudio has not been fixed to allow successfully creating a Mojave DeployStudioRuntime image and instead you have to use a full Mojave boot drive the --volume parameter definitely does not work on a normal Mojave boot drive. Without the --volume parameter you have to run the installer targeting the drive you are booted from.

It is my feeling that Apple removed the --volume parameter specifically in order to try and kill off imaging approaches. :(

However AutoDMG has been updated to successfully create a Mojave thin image. It is possible to therefore go back to the previous approach of using DeployStudio to restore a thin image in APFS format for Mojave. Historically this approach - at least for High Sierra did not trigger installing firmware updates, so far the only Mac models that require booting from a Mojave drive do not yet need firmware updates so this is not yet a problem.

On a related topic in yet another case of Apple seemingly going out of their way to break things the EFIgy tool no longer works on Mojave or T2 equipped Mac models. As such it is no longer possible to check whether a Mac has the right version of EFI firmware. Apple have also changed the format of the version number returned for EFI firmware. :(

(In theory I can see a new approach EFIgy could use but this would require a relatively simple change to the software and a more significant update to the online database the authors maintained. So far there has been no response from the authors.)

I have now successfully made a Mojave 10.4.1 AutoDMG APFS image, used DeployStudio to restore it to a Mac mini 2018, and then run my normal post-restore tasks  as another DeployStudio workflow resulting in a fully built Mac. Hurrah!

#3 Re: Debug » Mojave error trying to make NetBoot set » 2018-11-08 15:16:57

For what its worth the new Mac mini (Late 2018) comes with Mojave 10.4 (18A2063). This as one might expect appears to be a device specific build as it is newer than the original Mojave 10.4 (18A391) that was released.

A 'standard' Mojave 10.4.1 should work even if copied from another Mac model.

It would seem extremely unlikely that any High Sierra build would work. (From a date point of view the current High Sierra build post-dates the release of the Mac mini - this is due to the recent Security Update, I don't believe this will help though.)

Whilst I can see why the developers might not want to spend a lot more effort on DeployStudio due to Apple's changes it would be a help if they did make it possible to generate a Mojave based runtime boot drive.

Now that my Mac mini has arrived once I have a 'standard' Mojave boot drive built with a manual DS Runtime on it I will begin testing modifications to my script for deploying a Mojave image.

#4 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-11-05 17:29:02

@carlocarlo

As per http://www.deploystudio.com/Forums/viewtopic.php?id=8132 it is currently not possible to create either a Mojave NetBoot image or a Mojave USB DeployStudio Runtime drive.

As of today all Macs still can boot from High Sierra - although the MacBook Pro 2018 requires a custom build. (This custom build works on old models.)

A workaround for presumably the new MacBook Air 2018 and the Mac mini 2018 which ship later this week will be to make a normal full blown bootable Mojave drive (not a DeployStudio Runtime drive) and then install the DeployStudio software on that and manually run the Runtime.

If you boot from some sort of drive and run the DeployStudio runtime you can then use it to format the internal drive and to run the workflow which runs my script.

#5 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-09-26 17:17:06

As requested here is the script to install Mojave.

• First you need to use a High Sierra boot image to run the DeployStudio Runtime. This could be a NetBoot image for older Macs or a USB boot drive for e.g. the MacBook Pro mid 2018
• Second you should start off by erasing the drive you intent to install Mojave on to as Mac Extended aka HFS+ (the Mojave installer will convert it to APFS if it is an SSD)
• Then you run via a DeployStudio workflow the following script

Currently it is not possible to use DeployStudio 1.7.8 to build a working Mojave NetBoot or USB boot image, hence the need to use a High Sierra one instead.

The Mojave installer is in a sparsebundle disk image downloaded/created using Greg Neagle's installinstallmacos.py script

The type of disk image is different to the High Sierra one and the location of the Mojave installer on it is also different.

#!/bin/sh

IMAGE="/tmp/DSNetworkRepository/Files/Install_macOS_10.14-18A391.sparseimage"

# Path to an empty folder where the contents of the image can be found
MOUNT="/Volumes/Mojave"

# Do the magic
# -owners on = Honor file/folder permissions in image
# -nobrowse = Don't show in Finder (-mountpoint is still visible)
# -mountpoint = Attach to a folder.
/usr/bin/hdiutil attach -owners on -nobrowse -mountpoint "$MOUNT" "$IMAGE"

"$MOUNT/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall" --applicationpath "$MOUNT/Applications/Install macOS Mojave.app" --volume "/Volumes/Macintosh HD" --agreetolicense --nointeraction

exit 0

#6 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-09-25 11:16:42

For what it's worth a modified version of this script worked to install Mojave 10.14.

As per a different thread I have started I am not able to create either a Mojave NetBoot set or a Mojave USB boot set so I am having to use a High Sierra based runtime to install the Mojave OS.

#7 Debug » Mojave error trying to make NetBoot set » 2018-09-25 10:47:31

jelockwood
Replies: 11

Yes Apple do not want you to use NetBoot to image Macs anymore.
Yes newer Macs e.g. MacBook Pro 2018 cannot NetBoot.

However USB booting with a MacBook Pro 2018 can work - at least with a High Sierra OS.

I am trying to create a Mojave 10.14 (18A391) based NetBoot set which in theory would work for older model Macs. The DeployStudio Assistant however gives an error when I try this saying -

"DeployStudio NetBoot set creation failed!

An error occurred while trying to create the DeployStudio NetBoot set.
Please check your system log file for more details."

I could not find anything obviously related in the log but if someone tells me where and what to look for I will add it to this thread.

Not too surprisingly trying to create a USB bootable drive also fails from the same Mojave running MacBook Pro.

#8 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-08-07 11:53:28

Now that I have the basic Dan authored script working, and seem to have established it is not possible to include the erase option I have a suggested enhancement.

The script for downloading a macOS installer written by Greg Neagle and available here https://github.com/munki/macadmin-scripts/blob/master/installinstallmacos.py is the only way to download a full High Sierra installer app for the new MacBook Pro 2018 models. (If/when High Sierra 10.13.7 is released you will be able to download it from the App Store as normal but until then you need the custom build for the new MacBook Pros.)

This script as standard produces a disk image containing the install app.

There is also the related situation that for any other Mac model you still need to use the standard High Sierra 10.13.6 installer. This means that you almost certainly will have a need to at the moment use two different copies of the High Sierra install app.

The original Dan script assumes you are only going to have a single installer with the original standard file name.

My suggested enhancement is a modification of the script to mount a disk image containing the High Sierra installer. The High Sierra installer will still have its standard name but the disk images can be named uniquely to reflect their build number. This is how Greg's download script actually names the disk images.

So I used Greg's script on a new MacBook Pro 2018 model to download its 17G2112 build and make a disk image called - Install_macOS_10.13.6-17G2112.dmg and on an older Mac I used Greg's script to download the standard 17G65 build and make a disk image called - Install_macOS_10.13.6-17G65.dmg

These are both stored in the DeployStudio/Files directory which is where Dan's script looks for the installer.

I then modified Dan's script as follows -

#!/bin/sh

# Location of the image to be mounted
IMAGE="/tmp/DSNetworkRepository/Files/Install_macOS_10.13.6-17G2112.dmg"
#IMAGE="/tmp/DSNetworkRepository/Files/Install_macOS_10.13.6-17G65.dmg"

# Path to an empty folder where the contents of the image can be found
MOUNT="/Volumes/HighSierra"

# Do the magic
# -owners on = Honor file/folder permissions in image
# -nobrowse = Don't show in Finder (-mountpoint is still visible)
# -mountpoint = Attach to a folder.
/usr/bin/hdiutil attach -owners on -nobrowse -mountpoint "$MOUNT" "$IMAGE"

"$MOUNT/Install macOS High Sierra.app/Contents/Resources/startosinstall" --applicationpath "$MOUNT/Install macOS High Sierra.app" --volume "/Volumes/Macintosh HD" --agreetolicense --nointeraction

exit 0

This script could potentially be further enhanced as follows -

#!/bin/sh
# Find Mac model number
model=`system_profiler SPHardwareDataType | grep "Model Identifier" | awk '{print $3}'`
# Location of the image to be mounted
if [ "$model" == "MacBookPro15,1" ]; then
    IMAGE="/tmp/DSNetworkRepository/Files/Install_macOS_10.13.6-17G2112.dmg"
else
    IMAGE="/tmp/DSNetworkRepository/Files/Install_macOS_10.13.6-17G65.dmg"
fi

# Path to an empty folder where the contents of the image can be found
MOUNT="/Volumes/HighSierra"

# Do the magic
# -owners on = Honor file/folder permissions in image
# -nobrowse = Don't show in Finder (-mountpoint is still visible)
# -mountpoint = Attach to a folder.
/usr/bin/hdiutil attach -owners on -nobrowse -mountpoint "$MOUNT" "$IMAGE"

"$MOUNT/Install macOS High Sierra.app/Contents/Resources/startosinstall" --applicationpath "$MOUNT/Install macOS High Sierra.app" --volume "/Volumes/Macintosh HD" --agreetolicense --nointeraction

exit 0

If more models and disk images need to be considered you could use a case statement instead.

#9 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-08-06 20:16:45

@Peteo

The new MacBookPro15,1 uses a build that is specific to this model. As you said when 10.13.7 comes out that will include the drivers you need.

What I did and I presumed you had, was to use a script to download the correct installer and create a disk image with it. The script is here https://github.com/munki/macadmin-scripts/blob/master/installinstallmacos.py

You _must_ run this on the MacBookPro 2018 model. The build number to select was the first in the list for me. I don't have the MacBook at home to look up the number.

#10 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-08-06 15:56:11

I made the DS Runtime boot drive from the MacBook Pro 2018 before I wiped it.

No, the install script is not postponed.

My steps are as follows -

1. Boot from DS Runtime boot drive
2. Run Disk Utility - wipe entire drive as APFS, I show hidden volumes and select the parent device to erase not the Macintosh HD volume
3. Run workflow containing only Dan's script
4. Let it run and reboot and then install
5. When it gets to the normal brand new Mac wizard I reboot from the DS Runtime drive again
6. I then run a second workflow which does not do a format or install but only runs my normal workflow tasks e.g. renaming Mac, installing packages and settings

#11 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-08-06 15:19:34

> > Peteo wrote:
>
> > > jelockwood wrote:
>
> > Ok, using the script suggested by @dan.kuehling I was able to get a new MacBook Pro 2018 booted from an external USB drive using DeployStudio Runtime and to run the script from the DeployStudio repo and to run the High Sierra installer. I used the python script to download and build the >custom build for the 2018 model.
>
> >I did try various permutations to try and automate erasing the drive. All failed in various ways, the modification to Dan's script failed with an error 801 or something similar. (Don't have the number in front of me.) I tried using DeployStudio partition workflow but this did not create an APFS >volume. I tried making an empty APFS disk image and restoring that but that did not work either. So to do an erase I am booting from the DeployStudio Runtime and using Disk Utility. I then run the Dan script. This works as far as it goes.
>
> >Has anyone been able to automate then running the rest of a standard DeployStudio workflow? I have managed to reboot and run a second workflow but would like it to be automatic as part of a single workflow.
>
>
> How did you get the installer to work? did you run the install script as a post install? This does not work for me. It might be because I delete the apfs container, create a new one and a new Macintosh HD APFS volume using these commands:
>
> diskutil apfs deleteContainer disk0s2
> diskutil apfs createContainer /dev/disk0s2
> diskutil apfs addVolume disk1 APFS "Macintosh HD"
>
> That works fine but then when I run the startosinstall app in the same script it says no valid image found
> I cant not run this post install since there is no macOS on the volume for DS to modify

It worked as a workflow containing just a single script as written by Dan. It ran the Apple installer and found the "Macintosh HD" volume I created using Disk Utility in the DeployStudio Runtime.

I was hoping to then get it run subsequent workflow steps but not been able to do this so far.

#12 Re: Usage » High Sierra 10.13 Imaging Install School Manager DEP process theory » 2018-08-06 14:55:04

Ok, using the script suggested by @dan.kuehling I was able to get a new MacBook Pro 2018 booted from an external USB drive using DeployStudio Runtime and to run the script from the DeployStudio repo and to run the High Sierra installer. I used the python script to download and build the custom build for the 2018 model.

I did try various permutations to try and automate erasing the drive. All failed in various ways, the modification to Dan's script failed with an error 801 or something similar, I tried typing the command manually in Terminal. (Don't have the number in front of me.) I tried using DeployStudio partition workflow but this did not create an APFS volume. I tried making an empty APFS disk image and restoring that but that did not work either. So to do an erase I am booting from the DeployStudio Runtime and using Disk Utility. I then run the Dan script. This works as far as it goes.

Has anyone been able to automate then running the rest of a standard DeployStudio workflow? I have managed to reboot and run a second workflow but would like it to be automatic as part of a single workflow.

#13 Re: Debug » Admin... Why does imaging change permissions on /Library directory? » 2018-03-07 20:03:18

Related to this issue it appears DeployStudio also changes the permissions of /Library as well as the group.

The correct original permissions should be drwxr-xr-x but DeployStudio leaves it as drwxrwxr-x

As @ooshnoo states the owner:group is also changed from root:wheel to root:admin

For most situations these changes do not cause obvious problems although the suspicion is that this will affect the security of the computer. However I have encountered at least one major issue caused by this. The Sophos anti-virus installer runs a check before installing to verify that the following directories have the correct permissions -

/
/Library
/Library/Application Support

All three should normally be drwxr-xr-x

As mentioned because of this bug in DeployStudio /Library ends up with the incorrect permissions and group ownership. As a result the Sophos installer refuses to allow an install. Since /Library is protected by SIP the only way to fix this requires turning off SIP, modifying the permissions/ownership and then turning SIP back on. With the permissions fixed on /Library the Sophos installer then works.

I only noticed this after setting my DeployStudio to provide a High Sierra 10.13.3 image, I do not recall it happening on older versions of image. I am using DeployStudio 1.7.8 on a Mac mini running macOS 10.13.3. The High Sierra image was created using AutoDMG.

#14 Re: Future » macOS Server Changes » 2018-02-02 10:30:08

If the DeployStudio team fail to port their software to Linux you could look at either the free NetSUS - https://github.com/jamf/NetSUS from Jamf, or the also free Imagr - https://github.com/grahamgilbert/imagr (see also https://macmule.com/projects/autoimagrnbi/ )

Personally I hope they do port DeployStudio as it is (currently) the best solution.

#15 Re: Future » macOS Server Changes » 2018-01-27 15:55:21

I get the impression that the 2018 version of Server.app will remove these options if your not already using them but leave them if you are, however it is clear that the following version - presumably 2019 will lose them completely regardless.

If DeployStudio is to have any future it needs to be ported to Linux as a number of people have already suggested. They authors could perhaps combine this with improved Linux and Windows imaging i.e. add workflows for those operating systems.

#16 Debug » Hostnames i.e. .local names in DeployStudio » 2018-01-04 17:44:48

jelockwood
Replies: 0

I am currently running DeployStudio 1.7.8 under High Sierra 10.13.2. It is all working fine even for APFS images.

However compared to when I last setup a DeployStudio system with an older version I am seeing a change in behaviour which might be considered a minor bug. As everyone should be aware in DeployStudio Admin you can in the Computers section define for each computer a variety of settings in particular the 'Local' Hostname i.e. something.local and the 'Computer name' e.g. MyComputer.

As I recall previously DeployStudio left the capitalisation of both of these values exactly as you typed, so if I typed a Local Hostname as - "CapitalName.local" it would be left like that, however I am currently finding it is converting all of the local hostnames to lowercase only.

This is not preventing anything from working but it is mildly annoying.

Is there either anyway for me to fix this, or could the developers undo this change in behaviour in a future update?

#17 Re: Usage » Couple of first boot queries » 2017-12-18 16:41:06

Solved it myself,

For the PlistBuddy commands you need something like -

    /usr/libexec/PlistBuddy -c "Add menuExtras string array" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add menuExtras: string '/System/Library/CoreServices/Menu Extras/Bluetooth.menu'" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add menuExtras: string '/System/Library/CoreServices/Menu Extras/Volume.menu'" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add menuExtras: string '/System/Library/CoreServices/Menu Extras/AirPort.menu'" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist

#18 Usage » Couple of first boot queries » 2017-12-15 15:31:56

jelockwood
Replies: 1

I am trying to add a few more controls to my first boot script for setting up Macs as part of my DeployStudio workflow. I have most things working but I am struggling with the following two items.

First I am trying to turn on some extra menulets as follows.

for USER_TEMPLATE in "/System/Library/User Template"/*
  do
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver "NSStatusItem Visible com.apple.menuextra.bluetooth" -bool true
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver "NSStatusItem Visible com.apple.menuextra.volume" -bool true
    /usr/bin/defaults write "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver "NSStatusItem Visible com.apple.menuextra.airport" -bool true
    /usr/libexec/PlistBuddy -c "Add :menuExtras: string '/System/Library/CoreServices/Menu Extras/Bluetooth.menu'" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add :menuExtras: string '/System/Library/CoreServices/Menu Extras/Volume.menu'" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add :menuExtras: string '/System/Library/CoreServices/Menu Extras/AirPort.menu'" "${USER_TEMPLATE}"/Library/Preferences/com.apple.systemuiserver.plist
done

The /usr/bin/defaults commands work but not the PlistBuddy ones although the the same PlistBuddy commands do work if run after first boot in Terminal or even via Apple Remote Desktop Admin.

Note: I have another similar section in the script to apply the above to any existing user home directories, as below.

for USER_HOME in /Users/*
  do
  USER_UID=`basename "${USER_HOME}"`
  if [ ! "${USER_UID}" = "Shared" ]
  then
  if [ ! -d "${USER_HOME}"/Library/Preferences ]
  then
  mkdir -p "${USER_HOME}"/Library/Preferences
  chown "${USER_UID}" "${USER_HOME}"/Library
  chown "${USER_UID}" "${USER_HOME}"/Library/Preferences
  fi
  if [ -d "${USER_HOME}"/Library/Preferences ]
  then
    /usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.systemuiserver "NSStatusItem Visible com.apple.menuextra.bluetooth" -bool true
    /usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.systemuiserver "NSStatusItem Visible com.apple.menuextra.volume" -bool true
    /usr/bin/defaults write "${USER_HOME}"/Library/Preferences/com.apple.systemuiserver "NSStatusItem Visible com.apple.menuextra.airport" -bool true
    /usr/libexec/PlistBuddy -c "Add :menuExtras: string '/System/Library/CoreServices/Menu Extras/Bluetooth.menu'" "${USER_HOME}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add :menuExtras: string '/System/Library/CoreServices/Menu Extras/Volume.menu'" "${USER_HOME}"/Library/Preferences/com.apple.systemuiserver.plist
    /usr/libexec/PlistBuddy -c "Add :menuExtras: string '/System/Library/CoreServices/Menu Extras/AirPort.menu'" "${USER_HOME}"/Library/Preferences/com.apple.systemuiserver.plist
    chown "${USER_UID}" "${USER_HOME}"/Library/Preferences/com.*.plist
  fi
done

I am also trying to set the TrackPad/MagicMouse to turn on Right-Click and in the case of the TrackPad to use the bottom right corner for right-click this is not working at all.

The client is running Sierra 10.12.6, it is being imaged via DeployStudio. The first boot script is being run as a postponed i.e. after first boot script.

#19 Re: Install » DeployStudio on linux? » 2017-11-08 18:57:41

I would add my vote that a version of DeployStudio server that could run on Linux would be helpful in this era of no Apple server hardware. ;)

Regarding the GUI issue, the client side GUI i.e. the DeployStudio runtime is run on a Mac client netbooting from the NetBoot server - which could be Linux. Therefore this aspect does not represent a problem. The GUI for the DeployStudio Admin program also runs on a Mac and talks over the network to the DeployStudio server. The DeployStudio server is on the surface little more than a HTTP server.

In summary there is no GUI that one needs to worry about as all the GUI aspects are separate to the actual DeployStudio server itself.

I am not one of the DS developers so not speaking from inside knowledge but in theory DeployStudio runtime and DeployStudio admin and their talking to the DeployStudio server are not the issue, most likely the issue is DeployStudio Server and its ability to replicate to other DeployStudio servers although not everyone needs that function.

It would be interesting to see what would happen if you copied the DeployStudio databases to an Apache2 server running on the different port DS uses and pointing DeployStudio Admin at it. Or to do some WireShark sniffing.

Whilst the efforts of the DS team are much appreciated they might need to reconsider their stance over this. The creation of Imagr which is able to run on a Linux server shows there is a demand even ignoring this thread. Not to mention JAMF's NetSus appliance.

If someone were to create the equivalent of DeployStudio Admin for Imagr then you are very close to a replacement. (Imagr currently is purely command line based.)

Update: See https://github.com/mosen/spirit non-functional as is but could be a starting point.

Update: See also https://macops.ca/interfacing-with-deploystudio-using-http/ and the fact that DeployStudio Admin to DeployStudio Server uses REST.

#20 Re: Usage » DS 1.7.7 and APFS restore of 10.13 is possible :-) ! » 2017-10-05 11:31:54

As per this thread there is an approach where DeployStudio can run a workflow that allows formatting a drive as APFS and then restoring an image on to it. The trick part is checking and if needed updating the firmware.

It maybe that dealing with the firmware would be best done by a different tool to DeployStudio - for example Munki. You could have a package in Munki that you deploy based on a conditional check. The conditional check would first look for the current firmware version - here is a command to get the current firmware version

system_profiler SPHardwareDataType | grep -i "ROM Version" | awk -F ': ' '{print $2}'

If it is determined to be too old then the install is run. You would do this to your entire fleet and then you can presume in DeployStudio that all your Macs are already running new enough firmware.

It maybe however that another better approach would be adding functionality in DeployStudio to handle this directly. As far as I can see the current DeployStudio package install process does not provide a means of including conditional checks unless you create your own custom installer package as a wrapper around a standard install package. Hence it would currently fail if already up-to-date and then this causes the entire workflow to fail.

Frankly Apple are creating a problem here where one did not used to exist. It used to be that such firmware updates were simply pushed out using the standard Apple Software Update Mechanism and therefore would have automatically been installed.

#21 Re: Usage » DS 1.7.7 and APFS restore of 10.13 is possible :-) ! » 2017-09-12 11:03:34

> mjsanders wrote:

> It should, all the files are included, but I only tested it (yet) on a MacBookPro8.1

If I take a look inside one of the subfolders I can see these EFI firmwares, and this looks like the complete (? not checked) list of 10.13 supported Mac's (taken from 10.13 beta8) of munkipkg folder

$ls  FWupdSA_10.13b8/scripts/Tools/EFIPayloads/
IM101_00CF_00B.scap	IM171_0110_B00.fd	MBA71_0171_B00.fd	MBP143_0167_B00.fd
IM111_0037_00B.scap	IM181_0151_B00.fd	MBP101_00F2_B00.scap	MBP61_005A_00B.scap
IM112_005B_00B.scap	IM183_0151_B00.fd	MBP102_010B_B00.scap	MBP71_003D_00B.scap
IM121_004D_00B.scap	MB101_0154_B00.fd	MBP111_0142_B00.scap	MBP81_004D_00B.scap
IM131_010F_B00.scap	MB61_00CB_00B.scap	MBP112_0142_B00.scap	MBP91_00D7_B00.scap
IM141_0123_B00.scap	MB71_003D_00B.scap	MBP114_0177_B00.fd	MM41_0045_00B.scap
IM142_0123_B00.scap	MB81_0168_B00.fd	MBP121_0171_B00.fd	MM51_007B_B00.scap
IM143_0123_B00.scap	MB91_0159_B00.fd	MBP131_0212_B00.fd	MM61_010B_B00.scap
IM144_0183_B00.scap	MBA31_0067_00B.scap	MBP132_0233_B00.fd	MM71_0224_B00.scap
IM151_0211_B00.scap	MBA41_007B_B00.scap	MBP133_0233_B00.fd	MP61_0120_B00.scap
IM161_0212_B00.fd	MBA51_00F4_B00.scap	MBP141_0167_B00.fd
IM162_0212_B00.fd	MBA61_0103_B00.scap	MBP142_0167_B00.fd

As far as I can see the above list is missing at least one model although this maybe deliberate. It is missing the MacPro5,1 for example which is officially supported by High Sierra. One obvious conclusion is that while a MacPro5,1 may support booting High Sierra it might not support booting High Sierra with an APFS volume.

It is somewhat surprising the MacPro5,1 is not listed since the equally old and also hard drive based Macmini4,1 is listed.

There have been firmware updaters in the past for the MacPro5,1 - this is after all how people unofficially upgrade MacPro4,1 models to 5,1 firmware enabling those 4,1 models to then run Sierra and High Sierra.

#22 Re: Future » DeployStudio Version 2 - Server-side cross-platform » 2016-01-18 12:25:09

> prbsparx wrote:
> This is probably a little far thinking and definitely a Version 2 kind of change... Has there been any discussion on making the server-side component of DeployStudio able to be installed on other platforms... specifically Linux.
>
> Use Case:
> Many enterprises are moving towards Virtualized environments and currently Apple does not allow OS X to be virtualized on Datacenter-grade hardware (i.e. 1-3U rack-mountable, 64+ GB of RAM)
> Right now, I have a Mac Mini just for running DeployStudio when I'd prefer to be able to host it in our Datacenter.
>
> I'd be glad to work on this with the developers of DeployStudio and get some traction from large enterprise customers that may want this functionality.

JAMF have a Linux based NetBoot server - see https://jamfnation.jamfsoftware.com/viewProduct.html?id=180&view=info this clearly shows it should be possible from a technical point of view to have a similar Linux based DeployStudio server. Depending on the licensing perhaps the JAMF appliance could be used as the starting point for this.

#23 Re: Debug » TImezone and NTP server being set incorrectly » 2016-01-18 12:17:42

I have not rechecked this for a long time but original also found the built-in step was unreliable. Currently I use the following in my own shell script along with many other settings.

/usr/sbin/systemsetup -setusingnetworktime off
/usr/sbin/systemsetup -settimezone "Europe/London"
/usr/sbin/systemsetup -setnetworktimeserver "time.euro.apple.com"
/usr/sbin/systemsetup -setusingnetworktime on

#24 Re: Usage » Automatic enrollment getting stuck. » 2016-01-18 12:07:15

I also found that trying to use the built-in enrolment step failed. I ended up finding and copying the relevant shell script to my own and running it as a shell script marked for postponed execution, the actual content is effectively identical and is of course using the same enrolment and trust profiles.

I originally reported this here http://www.deploystudio.com/Forums/viewtopic.php?id=6046

#25 Re: Debug » DeployStudio Finalize Script hanging after Profile Manager Auto Enroll » 2015-09-14 13:59:22

This is now an oldish thread but this is still a problem and goes back longer than even this thread. See my older thread on this topic http://www.deploystudio.com/Forums/viewtopic.php?id=6046

I originally hit this problem as you can see in 2014 with Mavericks. I was able to get round it at the time by making my own enrolment script which was almost identical to the built-in one in DeployStudio. My approach still works for all Mavericks setups, but does not work it seems for Yosemite so I am back to square one.

I will look at options like putting the enrolment profiles in an Apple installer package and also trying the auto install location of /var/db/ConfigurationProfiles/setup however I was specifically trying to do the enrolment process early in the DeployStudio workflow so as to make my self-signed rootCA trusted for later use by both Open Directory binding and Munki repository access. (The Profile Manager Trust profile makes the self-signed rootCA trusted in a way that is fully trusted for both Open Directory binding and Munki or more specifically curl which is the tool used by Munki, merely adding the rootCA via Keychain Access for example does not make it full trusted. One can do this of course via the command line using the /usr/bin/security tool.)

While I can believe this issue may be partly or totally Apple's fault it is not helped by the DeployStudio developers not seeming to have a real bug tracking system themselves that we can use to see if they have responded about issues like this. It would therefore be much appreciated if the dev could comment on this issue.

Board footer

Powered by FluxBB