Skip to main content

Hi All,



I thought i would share with the community my method for deploying High Sierra with Casper Imaging.
The method basically consists for two scripts.



I have tested this with a 10.13.1 Netboot Image created with AutoDMG and AutoCasperNBI



restoreMacOS.sh To deploy the correct image which runs as a "before" script



imagingPostinstall. To run after reboot to run the Sierra Upgrade if needed.



The first script will decide which image to deploy to the Mac based on the currently installed Operating System or File system.



-If it is APFS it will deploy the 10.13.1 APFS image to the APFS container.
-If it is HFS+ it will check the currently installed OS. If the OS is already 10.13 it will image using the 10.13 HFS+ image.
-If the filesystem is HFS+ and the current OS is not 10.13 it will deploy 10.12.6 and then upgrade to 10.13 on next reboot using startOSInstall.



Script 1 RestoreMacOS.sh This replaces your base image in your Casper Admin Config



#!/bin/bash

######################################################################################

#

#   RestoreMacOs.sh - Ashley Stonham <reddrop>

#   Restores either High Sierra or Sierra based on a best guess

#

#   Variables:

#   DP      - Set this to the path that your DP mounts as

#   SIERRA      - Set this to the filename of your Sierra image 

#   HSIERRAAPFS     - Set this to the filename of your HighSierra APFS Image    

#   HSIERRAHFS  - Set this to the filename of your HighSierra HFS Image

#

######################################################################################





## Set these Variables

DP="/Volumes/casperdp"

SIERRA="osx-10.12.6-16G29.hfs.dmg"

HSIERRAAPFS="osx-10.13.1-17B48.apfs.dmg"

HSIERRAHFS="osx-10.13.1-17B48.hfs.dmg"





## No need to change anything below

TARGET="$1"

SOURCE=""



FSTYPE=$( diskutil info "$TARGET" | grep 'Type (Bundle)' | awk '{print $3}' )





## If the filesystem is APFS just restore High Sierra APFS



if [ "$FSTYPE" == "apfs" ]; then

    echo "APFS Detected setting SOURCE to $HSIERRAAPFS"

    SOURCE="$HSIERRAAPFS"

fi





## If the filesystem is HFS check the currently installed OS Version

if [ "$FSTYPE" == "hfs" ]; then

        echo "HFS Detected checking OS Version"

    VERSION=$( defaults read "${TARGET}/System/Library/CoreServices/SystemVersion.plist" ProductVersion )

    echo $VERSION

    if [[ "$VERSION" == *"10.13"* ]]; then

        echo "High Sierra Detected"

        SOURCE="$HSIERRAHFS"

    else

        echo "High Sierra Not Detected"

        SOURCE="$SIERRA"

    fi  

fi





if [ "$SOURCE" == "" ]; then

    echo "ERROR: Unable to determine source"

    exit 1

fi



echo "Running ASR ${DP}/Packages/${SOURCE} to $TARGET"



## If restoring APFS

if [ "$SOURCE" == "$HSIERRAAPFS" ]; then

    echo "Restoring APFS Volume"



    ## Workout APFS Container

    APFSDISK=$( diskutil list "$TARGET" | head -1 | cut -d' ' -f 1 )

    APFSCONTAINER=$( diskutil apfs list "$APFSDISK" | grep 'APFS Physical Store Disk' | cut -d':' -f 2 | tr -d '[:space:]' );



    if [[ "$APFSCONTAINER" == *"disk"* ]]; then

        echo "Restoring ${DP}/Packages/${SOURCE} to /dev/${APFSCONTAINER}"

        asr restore --source "${DP}/Packages/${SOURCE}" --target "/dev/${APFSCONTAINER}" --erase --noprompt 

        diskutil mountDisk "${APFSDISK}"

    else

        echo "Error unable to determine APFS container"

        exit 1;

    fi

else

    echo "Restoring HFS Volume"

    asr restore --source "${DP}/Packages/${SOURCE}" --target "$TARGET" --erase --noprompt --corestorageconvert

    #diskutil cs convert "$TARGET"

fi



exit 0


ImagingPostinstall.sh this scripts runs as an After Reboot and will create a launchDaemon to install HighSierra if the current OS is 10.12



#!/bin/bash



## Check OS Version if 10.12 Upgrade to HighSierra





OSVERSION=$( defaults read /System/Library/CoreServices/SystemVersion.plist ProductVersion )

if [[ "$OSVERSION" != *"10.12"* ]]; then



    ## Do nothing and exit

    echo "OS is not 10.12"

    exit 0;

fi





/bin/mkdir /usr/local/scripts





cat <<"EOF" > "/usr/local/scripts/NextBoot.sh"

#!/bin/bash

OSVERSION=$( defaults read /System/Library/CoreServices/SystemVersion.plist ProductVersion )



## If already on 10.13 remove the scripts.

if [[ "$OSVERSION" == *"10.13"* ]]; then

        ## Remove LaunchDaemon

        /bin/rm -f /Library/LaunchDaemons/com.scripts.NextBoot.plist



        ## Remove Script

        /bin/rm -fdr /usr/local/scripts



        launchctl remove com.scripts.NextBoot

        exit 0

fi



## Sleep for 30s to give the mac a chance to connect to network

sleep 30



## Update Device Inventory

/usr/local/jamf/bin/jamf recon



## Run HighSierra Upgrade

/usr/local/jamf/bin/jamf policy -event highSierraUpgrade 



exit 0



EOF





/usr/sbin/chown root:admin /usr/local/scripts/NextBoot.sh

/bin/chmod 755 /usr/local/scripts/NextBoot.sh



## Install the launchdaemon

    cat << EOF > /Library/LaunchDaemons/com.scripts.NextBoot.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>Label</key>

    <string>com.scripts.NextBoot</string>

    <key>ProgramArguments</key>

    <array>

        <string>/bin/bash</string>

        <string>-c</string>

        <string>/usr/local/scripts/NextBoot.sh</string>

    </array>

    <key>RunAtLoad</key>

    <true/>

</dict>

</plist>

EOF



##Set the permission on the file just made.

/usr/sbin/chown root:wheel /Library/LaunchDaemons/com.scripts.NextBoot.plist

/bin/chmod 644 /Library/LaunchDaemons/com.scripts.NextBoot.plist





exit 0

Is there a reason why we cannot just use this method to go from 10.11 to 10.13?

@dstranathan I'm with you!



However, I find myself in an interesting place when dealing with this. We have a BYOD environment in which we will never be able to utilize DEP, but still need to re-provision. If I could just get some type of iOS-ish "Erase all content and settings" admin feature of the macOS I'd be golden! I'd be happy to leave the OS alone and manage an upgrade path. Instead, my current method is to wipe the unit, re-install whichever OS is applicable, and THEN upgrade... TEHN run policies. Eh... By September, I will need to do this programmatically for >300 random laptops in a day.

@dstranathan I'm not sure what you're waiting for. Jamf's method will allow you to take a 10.13 machine and reimage it to 10.13. We all still need a workflow in place to get from 10.12 --> 10.13... If you continue to use casper imaging on 10.13 machines, you'll miss out on firmware updates that may come out between versions of 10.13.



My opinion is jamf is making it more confusing that they're leaving casper imaging in the supported list (for 10.13). The whole mac community would be better off if instead they adopted a model like imagr that allows you to automate wiping the drive and then loading os via apple's supported startosinstall method, at which point DEP/MDM can take over and queue off other software installs (I'm using depnotify). It is significantly slower than imaging, but that's apple's fault not jamfs. Jamf could do a better job with documentation, though.



Of course, imagr or the above @reddrop method isn't helpful with the T2 chip which can't network boot at all (in new iMac Pros and presumably in all new hardware). If only Apple had timed their push for end of imaging with an announcement about APFS snapshots or at the very least allow admins to cache macOS installers via caching services because using internet recovery is not practical in many cases.

One thing I havent understood is why we cant push out prerequisite firmware updates to all pre-10.13 Macs proactively (Via Jamf policy, Jamf Remote, ARD - whatever). Wouldn't this make the High Sierra imaging process easier for those of with older Macs (assuming these Macs dont get upgraded in-place of course)?

@dstranathan because Apple doesn't want us to. They stopped unbundling firmware years ago, unfortunately. They are concerned with what state it would leave the machine in they say. For awhile you could strip it out, but there are reports if you do this with latest firmware revs it doesn't actually update firmware.

@reddrop Whenever I try to run the "RestoreMacOS" script on an APFS volume I get the following error:



Result of running RestoreMacOS.sh was: APFS Detected setting SOURCE to 10.13.3-Clean.apfs.dmg
Running ASR /Volumes/CasperShare/Packages/10.13.3-Clean.apfs.dmg to /Volumes/Macintosh HD
Restoring APFS Volume
Error unable to determine APFS container


It works fine with HFS partitions.



Also, what does your upgrade eligible smart group look like? Does it just check the model and currently installed OS?

I would also like to know how you're running your script at image time with autorun (if you are). We can't seem to figure out how to run scripts during imaging anymore.

@jmahlman There might be something unexpected about your partitioning scheme that my script does not handle. My suggestion would be to open disk utility and reformat the entire drive (Not just the APFS container) as APFS before you try imaging again.



Ash :)

@dstranathan



If you are using something like Margarita, you can filter for the update by typing in something like "10.12.6 update" or "10.13.2" update etc.



You'll get a list of applicable updates and you can then click on the "I" button and it will show all the installers within that update. This will include the firmware updates. My current method which seems to work is to just add the applicable firmware update to my imaging workflow that matches the version of macOS that I'm distributing.



Whether this is the right way to do things I have no idea but I've been doing this for about a year, so far without any obvious issues.

So I'm utilizing your scripts for this. The issue I'm running into is that the machine will not auto-reboot. Am I missing something here? When I reboot the machine it just shows a blinking folder with a "?" like it can't find the startup disk. I can netboot again and go to "startup disk" and select the only drive there and restart - and it boots just fine. Am I missing something when it comes to this script?



Graci!

@Chubs



Have you created all 3 boot images using autoDMG?
10.12.6 HFS
10.13.3 APFS
10.13.3 HFS



You also need to customise these variables to suit your environment.



## Set these Variables

DP="/Volumes/casperdp"

SIERRA="osx-10.12.6-16G29.hfs.dmg"

HSIERRAAPFS="osx-10.13.2-17C88.apfs.dmg"

HSIERRAHFS="osx-10.13.2-17C88.hfs.dmg"

@reddrop



I’ve done everything exactly as described here. I also customized the variables properly.



If I choose “boot to target drive” on older macs (non-APFS only macs), it works fine.



I’m noticing this behavior on APFS only macs.

@Chubs is your netboot environment based of a 10.13 image?

@Chubs
@reddrop



Regardless if on an APFS or JHFS+ volume, it is most likely that the bless function is inhibited by SIP...



If SIP is disabled...



In new dual boot environments, ie new Mac's with APFS. You'll notice that the BootCamp.exe in Windows, blesses a volume labelled "Mac". Whereas previously it was the label of the JHFS+ volume ie "Macintosh HD".



It could be that the bless function in Casper Imaging/Jamf Imaging is trying to bless the volume name "Macintosh HD", or whatever the target volume name Imaging is imaging...



It would be interesting to
1. disable SIP
2. bless "Mac" (APFS bless, the same way the BootCamp.exe blesses OSX)
3. Review the results

@reddrop My netboot environment is based on 10.13.2



@bsuggett If that were true, then all of my machines would be effected. Unfortunately, it's only the machines that are APFS based.



All of the rest of them are running 10.12 which has SIP enforced. Never had an issue until we acquired APFS only machines. Even with older machines that have been converted to APFS do not have this issue - it's only the new ones.



If I do checkbox the "boot to target drive" on the newer macs with APFS only, it reboots, but doesn't target the internal drive. After checking logs, it doesn't select any drive to boot to - so we have to manually go into disk utility after imaging and select the hard drive as a boot source, then reboot.

@Chubs



Sorry for the confusion, I meant to say any Mac that has done the APFS conversion or is using APFS.



Using a new Mac with APFS and dual booting into Windows, we were able to identify that the new version of the BootCamp.exe for windows blesses something with the label "Mac" and successfully reboots from Windows into macOS/ an APFS volume. Whereas previously it would bless "Macintosh HD" which just so happens to be generally the Mac's partition label where macOS is installed.



We're having to update our scripts for our dual boot labs for those machines that are running on APFS volumes. To get maintenance rebooting back and forth overnight working again.



Previous Windows Command To Bless "Macintosh HD" volume
eg. C:Program FilesBoot CampBootCamp.exe -StartupDisk "Macintosh HD"



New Windows Command To Bless the APFS volume
eg. C:Program FilesBoot CampBootCamp.exe -StartupDisk "Mac"



Now because Windows knows nothing about APFS, SIP, etc. It isn't governed by Apple or macOS rules. I would assume that the BootCamp.exe in Windows is writing to PRAM/NVRAM what to boot from next. In this case the APFS volume, ie something labelled "Mac"



Using this knowledge, we could try and apply this while booted into macOS/Netboot
Attempt the following with SIP disabled first, just to eliminate possible errors...
Try blessing an arbitrary name ie "Mac" like what the BootCamp.exe does
Try using "systemsetup -setstartupdisk "Mac"



I've not tried this, but would be interesting to know...

ok... Just finished...



:-(



It looks like any sort of bless function in the command line, you have to specify a mountpoint :-(



It would be interesting to know what command the gui is running to bless an APFS volume...

Team



I am getting "Unable to upgrade macOS" when using the ImagingPostInstall script to upgrade from 10.12 to 10.13, struggling to find log files with a more detailed explanation, has anyone else come across this or know where I should be poking around?

@jmahlman in answer to your question about running scripts this may help [https://www.jamf.com/jamf-nation/discussions/18200/casper-imaging-the-script-could-not-be-found](link URL)

@marklamont I know that thread, I was the one who posted that it's not a bug 😉 Also, it doesn't answer the question about running scripts at image time, that just works for first boot.



We'll probably end up just using a custom launch daemon like we did for our fusion repairs.

@reddrop
We follow the instruction but would like some help on the concept.



If we understand this correctly, systems with macOS 10.12 HFS will get restored to 10.12 HFS because of the RestoreMacOS script. With the After priority, the ImagingPostinstall script will install the launchdaemon which will launch at the next login. Because it is 10.12, the ImagingPostinstall script will run and call the highSierraUpgrade policy. This policy will run the installer which was downloaded from Apple App Store.



When we look in the /var/log/JAMF.log, I don't see an entry for the highSierraUpgrade policy. I see an entry about "Fail to load launchAgent for use adobeinstall".



We got confused with your answer to @mwilkerson as it seems to use a script called ReconOnReboot and an installer from Apple. Can you explain how the three scripts, the policy and the installer work together to upgrade an 10.12 system to macOS 10.13 please? Is your solution intend for re-imaging using Casper Imaging? or an upgrade process made available through Self Service?



Thank you in advance for the advice.

@hphan You can choose what the upgrade does in your version of the "highSierraUpgrade" policy to runs the upgrade. You can add the switch "--converttoapfs NO" to the startosinstall command you're probably calling if you DON'T want to convert the target to APFS if it was eligible to be upgraded (fusion drives and spinny drives can't be upgraded).



ReconOnReboot just runs a recon after reboot because Jamf doesn't know about changes (like an OS upgrade) until a recon runs after the change. In our case I run this before I call the highSierraUpgrade policy because we have the High Sierra installer in our restricted software, and use an extension attribute to flag a machine that's ready to be upgraded (it has the NextBoot launchdaemon installed from the imaging process). The ReconOnReboot updates the Jamf server so that the machine is in a smart group that's set as an exception for the High Sierra restricted software. Another ReconOnReboot helps your Jamf server know if the upgrade was successful - or you could wait until your recon runs normally (default is 7 days I think).

An issue I have at the moment is I'd like to KEEP the jamf.log through this imaging process. It seems to be getting lost - initially by doing the ASR to reimage the drive.



I have a section in the RestoreMacOS.sh script, that runs before the ASR section, that copies the existing log to the current boot drive (we're not using netboot)...



## Lets Save the existing /var/log/jamf.log file

if [ -e "$TARGET"/var/log/jamf.log ];then

    cp "$TARGET"/var/log/jamf.log /var/tmp/

fi


...and then at the end of the script it copies it back to the target drive and changes the permissions on it.



## Let's put back the jamf.log file

if [ -e /var/tmp/jamf.log ];then

    cp /var/tmp/jamf.log "$TARGET/var/log/"

    chmod 777 "$TARGET/var/log/jamf.log"

fi


But it's not there at the end of the whole upgrade process. I think that its being lost during the High Sierra upgrade, but that doesn't make sense. The upgrade wouldn't be dumping the contents of /var/log. It looks like jamf.log is there before the machine reboots to run the upgrade.

I can't get this to work for the life of me, and it may just be that I'm doing something wrong...but it may also be because I'm using 10.13.4 on both my NBI and my image itself.



Has anybody else had luck with 10.13.4 yet??

I've not updated my netboot server yet so currently using an external HDD with my netboot image booting from it, but I'm not having any issues restoring an HFS+ formatted 10.13.4 image that was created with AutoDMG.

Reply


Terms & ConditionsCookie settings