Jamf Nation Community

reddrop · ‎11-02-2017

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

reddrop · ‎12-14-2017

ReconOnReboot.sh:
This was extracted from the SierraUpgrade script. I just cut it down i use it quite often for software updates etc.

#!/bin/bash
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# CREATE FIRST BOOT SCRIPT
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

/bin/mkdir /usr/local/jamfps

/bin/echo "#!/bin/bash
## First Run Script to remove the installer.

## Update Device Inventory
/usr/local/jamf/bin/jamf recon

## Remove LaunchDaemon
/bin/rm -f /Library/LaunchDaemons/com.jamfps.reconNextBoot.plist

## Remove Script
/bin/rm -fdr /usr/local/jamfps
exit 0" > /usr/local/jamfps/recon.sh

/usr/sbin/chown root:admin /usr/local/jamfps/recon.sh
/bin/chmod 755 /usr/local/jamfps/recon.sh

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# LAUNCH DAEMON
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

cat << EOF > /Library/LaunchDaemons/com.jamfps.reconNextBoot.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.jamfps.reconNextBoot</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>-c</string>
        <string>/usr/local/jamfps/recon.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.jamfps.reconNextBoot.plist
/bin/chmod 644 /Library/LaunchDaemons/com.jamfps.reconNextBoot.plist

RestoreMacOS.sh
Updated with a few tweaks and bug fixes to handle filesystems that don't have CoreStorage enabled.

#!/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.2-17C88.apfs.dmg"
HSIERRAHFS="osx-10.13.2-17C88.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"
    diskutil cs convert "$TARGET"
    diskutil cs resizeVolume "$TARGET" 0
    asr restore --source "${DP}/Packages/${SOURCE}" --target "$TARGET" --erase --noprompt --corestorageconvert

    #diskutil cs convert "$TARGET"
fi

NEWNAME=$( echo "$TARGET" | cut -d'/' -f3 )
diskutil rename /Volumes/Macintosh HD "$NEWNAME"

exit 0

ImagingPostInstall.sh

#!/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 -f /usr/local/scripts/NextBoot.sh

        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

View solution in original post

warrenmcall · ‎01-23-2018

Approximately how long does the restore take with Casper Imaging?

I'm looking for a fast way to do a re-image of High Sierra similar to DeployStudio for 10.12.6. Usually a I can get 10.12.6 reimaged in less than 5 minutes using DeployStudio.

PeterClarke · ‎01-24-2018

Hi el2493,

It's because "/" is the directory separator symbol - just replace it with an underscore _ character
or say ""Sierra or High Sierra Upgrader"

debrat · ‎01-30-2018

@cwaldrip we also image from a bootable USB drive with Casper Imaging on it. I am looking for ways to "image" the existing 10.11/1012 machines to 10.13. You mentioned a macosintall.sh script... is this what you use: https://github.com/gibiansky/IHaskell/blob/master/macos-install.sh?

cwaldrip · ‎01-31-2018

I'm using the above method, with only a few minor changes, with a local repository on a USB drive. We replicate the repository to the root level on our USB drives. And the drive name is CasperShare. Then we select the USB drive as usual for the repository to use when imaging.

The image configuration doesn't have an OS install for priority 1, but the RestoreMacOS.sh script. The script checks if the target machine is running 10.12 or earlier and uses ASR (Apple Software Restore, going old school!) to wipe the drive and put a clean 10.12 image on it, the imaging proceeds as normal, and the 10.13 installer is copied to /Library/Application Support/JAMF/Waiting Room/ from the USB drive. The script ImagingPostinstall.sh is also run and creates a launch daemon to run a new script on the next restart that will delete the launch daemon and run 10.13 as an update from Waiting Room. I have the install set NOT to convert the drive to APFS for now. And, Ta-Dah! Easy Peasy! (sigh).

chrisdaggett · ‎01-31-2018

@cwaldrip I don't really understand this. For sake of conversation, not argument, I'm really asking. If not upgrading to APFS anyway, wouldn't it have been easier (and faster) to just make an image of a 10.13 HFS+ Install and and imaged it to the machines via USB using Disk utility or any cloning/imaging software? It wouldn't matter at that point if it was already on 10.13 or 10.12, or if they had the firmware since you are booting HFS+ anyway. Or is this just a matter of trying to keep it "sort of Apple approved"?

Maybe its due to size of deployment but personally I don't have the time to wait for the 10.13 update to run on 950 machines (just in 1 building) and fully intend to image them (APFS) and have the FIrmware Update install before first boot. Still a work in progress for the "perfect" solution but APFS imaging does still work despite the naysayers word :).

@TSOAFTVPPC The answer to your question, was yes you could do that. You can also image using APFS although it is currently a hassle compared to HFS+ (and just script in installing the firmwarepackage before first boot).

cwaldrip · ‎01-31-2018

@chrisdaggett I understand. For me I've found that you can't reliably deploy a 10.13 base disk image. That's the rub. The most reliable method I've found so far is the method on this page - put a clean 10.12 on the machine and then update the machine to 10.13 so it gets the special sauce. There's more to the firmware than just the APFS boot loader too. There's the Touch Bar firmware too, and a machine won't boot if the TouchBar OS can't be loaded (in my experience it gets hung trying to fix it more often than not). And we'll eventually be moving to APFS (probably sooner rather than later - maybe by the time we start actually deploying 10.13, we're still testing).

TSOAFTVPPC · ‎02-01-2018

All of these convolutions seem to be to just get the firmware updated. I have multiple partitions one of which is a Restore partition. Why wouldn't I just upgrade the OS to HighSierra on the restore partition just to get the firmware updates, and image as previously on the other partitions?

allanp81 · ‎02-02-2018

I copy the firmware pkgs from my mac sus server and just add them to my imaging workflows so that the firmware updates match the version of the OS I'm deploying. I set it to install the firmware package right at the start and so far this seems to have worked fine for Sierra and my brief experience of imaging High Sierra.

dstranathan · ‎02-05-2018

@allanp81 Can you elaborate on this process please? I dont see specific firmware updates on my SUS. Im curious about the details on your process.

reddrop · ‎02-05-2018

@chrisdaggett You cant just restore a HFS+ version of 10.13 on a mac that has never run high sierra before. There is more to the firmware than just the boot loader for APFS. Once you have upgrade to high sierra there is no longer an issue in imaging directly to 10.13 and that is why my script will detect what the currently installed OS is and deploy a 10.13 image if the current OS is already 10.13, otherwise it will deploy 10.12.6.

Directly from the from the apple support article:

https://support.apple.com/en-us/HT208020

Monolithic system imaging can only be used to re-install macOS, not to upgrade to a new macOS version. If you try to use a monolithic system image, required firmware updates will be missing from the installation. This causes the Mac to operate in an unsupported and unstable state. You can use system images to re-install the existing operating system on a Mac.

dstranathan · ‎02-06-2018

Jamf: When is "soon"?

jmahlman · ‎02-07-2018

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

Chris_Hafner · ‎02-08-2018

@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.

CasperSally · ‎02-08-2018

@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.

dstranathan · ‎02-08-2018

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)?

CasperSally · ‎02-08-2018

@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.

jmahlman · ‎02-09-2018

@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?

jmahlman · ‎02-09-2018

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.

reddrop · ‎02-11-2018

@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 :)

allanp81 · ‎02-12-2018

@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.

Chubs · ‎02-13-2018

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!

I find your lack of faith disturbing

reddrop · ‎02-14-2018

@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"

Chubs · ‎02-14-2018

@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.

I find your lack of faith disturbing

reddrop · ‎02-14-2018

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

bsuggett · ‎02-14-2018

@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

Chubs · ‎02-16-2018

@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.

I find your lack of faith disturbing

bsuggett · ‎02-16-2018

@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...

bsuggett · ‎02-16-2018

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...

alexmcclements · ‎02-17-2018

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?

marklamont · ‎03-01-2018

@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)

jmahlman · ‎03-01-2018

@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.

hphan · ‎03-02-2018

@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.

cwaldrip · ‎03-07-2018

@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).

cwaldrip · ‎03-07-2018

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.

jesse_mcbrower · ‎04-24-2018

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??

allanp81 · ‎04-24-2018

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.

jesse_mcbrower · ‎04-26-2018

I rebuilt my process using the updated scripts posted above, and am having slightly better luck this time; my only problem now seems that the machines I image reboot to the recovery partition, and I have to manually reboot to the correct startup disk.

Anybody else experiencing this?

Kyuubi · ‎05-29-2018

bump

mchit · ‎05-30-2018

I am encountering the following error during thin provision method given by @reddrop on the first run every time.

After that, the JAMF Imaging app is quit and relaunched to start the process again. On the second run, it went well without any error. The nbi is based 10.13.4 macOS created by Autodmg and I am using JAMF Cloud 10.4.1. This is happening only for High Sierra thin provision config and previous configurations like Sierra Imaging Configuration are running fine without any error.

Anybody having the same issue?

russeller · ‎05-31-2018

@mchit i just had something similar happen to me. I had to launch Jamf Admin, create a new imaging configuration named slightly different than my current one, drag and drop all the same items from the old config into the new one. Then delete the old config and that fixed it. Basically duplicate the config. Dumb, I know. Hopefully that helps.

Jamf Nation Community

Deploying High Sierra 10.13 with Casper Imaging