Need Some Guidance On Coming Up With An Imaging Process For High Sierra

We're in the same position. We're starting to have all newly purchased devices be DEP, but I still have 2000+ Mac's in the field that aren't. Until they phase out, need a process for them.

We're using the AutoDMG, but we boot to a NetBoot image that has Caper Imaging pre-installed that kicks off the standard image.

Looking for how others plan on doing this moving forward.

With the latest version of AutoDMG you can format a base image with either APFS or HFS+. I get error messages imaging with APFS but using HFS+ I do not have to change or imaging process which is similar to john.sherrod's method except our techs boot from a base OS x system and restore an image from a seperate DATA partition.
The techs then have to boot the finalized system in recovery mode and convert the drive to APFS.

Fortunately my organization will not rush to High Sierra anytime soon as I have already encountered issues with High Sierra that I will need to fix first and hopefully some one will come up with a better way to implement High Sierra.

I used System Image Utility to make a net restore image of a High Sierra machine in Target mode. After I can deploy using Netinstall from a server. Boot into Casper Imaging afterwards to name machine and install Quickadd package. machine reboots then gets a some default settings from a policy set to run on new machines with High Sierra installed

Part of my concern is that any day now new Macs are going to start requiring High Sierra, which means I can't simply wipe the drives and image with my current Sierra imaging process.

You could make an imaging configuration that leaves High Sierra on any computers that come with it. Just omit the OS from the configuration and don't erase the drive during imaging.

You can also manually enroll the devices with a quick add .pkg under "User-Initiated Enrollment" and start your configuration with the "Enrollment Complete" trigger.

I think the main issue with the netinstall, netrestore and any method that installs the OS beside running the OS Apple installer is that there are firmware updated that Apple would like to be installed on some machines that most install methods can't do.

So you have to be 100% sure that you are doing what Apple wants with High Sierra..

C

We do use DEP for all of our setups but when we need to wipe a machine we just use DeployStudio to lay down a base OS only image created from AutoDMG and then let DEP do the rest. We currently have it working with 10.13 and APFS base image made from AutoDMG. If Casper Imaging doesn't support laying down a block level image of an APFS volume, I'd just do that part with Deploy Studio and then use Casper imaging afterwords to do a non-wipe lay down of your packages or, for machines where we don't have them in DEP, we just enroll it into Casper with a QuickAdd then have a setup policy in self service a tech can trigger.

But outside of Casper Imaging you totally can deploy a block level APFS 10.13 image to a machine.

Is there a reason people always seem to use block level from AutoDMG files?
I mean other than speed?
I moved to simply having the macOS installer directly run some time back, just found it to be very reliable, given the size of our Configurations meant it was always kick off and walk away anyway I never found the extra 10 or so minutes it took to be an issue.

@Look Can you elaborate on how you are using the Installer?

@a.stonham Up until macOS 10.13 you could simply drop a macOS installer into Casper Admin and it would recognise it as such.
You can then just add it to a Configuration and it is run first before anything else automatically.
We have been using AutoCasperNBI netboot to run Casper Imaging and deploy like this for some time now. I also stopped compiling the images at this point as well as there didn't seem to be any huge advantages to it.
I have now moved to having Casper Imaging only install macOS and enroll the device and I have all the packages come down as policies instead.
I was just curious as to why people were doing it differently.
I am assuming JAMF will be bringing back this capability in a near future update once they work out the differences in the 10.13 installer.

@Look What version of 10.12 are you using? I think that stopped working in 10.12.4 and later when Apple removed the -volume argument from startosinstall

The two most promising methods of still relying on imaging i can see at the moment for High Sierra are.

1. Deploy the base image from the Rescue Partition then boot to casper imaging deploy your config without a base image or wiping the drive.
2. Using the script from here https://github.com/grahamgilbert/imagr/wiki/High-Sierra-Notes to create a firmware package.

You do not have to be enrolled in DEP to take advantage of the same methodologies, namely utilizing the factory OS during deployment. I am in the process of migrating close to 15K endpoints spread across 5 business units with disparate IP networks, disparate ADs, and multiple sub-business units. Because we're in the middle of migration we are not utilizing DEP, and I have conditioned the techs to not refer to it as imaging (that is a four letter word now) and instead refer to it as provisioning. I know many in the community view it this way as well.

Rather than NetBoot to Casper Imaging, we simply boot the factory OS, walk through Setup Assistant, use a QuickAdd from a USB stick or server share to enroll, and then use Self Service to kick off a provisioning policy that runs all of our policies. I am not using an @enrollment trigger right now, simply because I have a lot of pre-existing machines enrolling in our environment.

For a re-deploy, we utilize the Restore partition to put the same factory OS back on the machine and follow the same steps as above.

I am seeing an average time of about 15 minutes for a light loadout (Office, Chrome, Firefox) and around 30 minutes for a larger loadout (Adobe Apps, some other apps).

I made the design decision that we would not be supporting NetBoot anymore, over 300 locations just in North America could mean hundreds of NetBoot servers to manage, and instead utilize this method. It works, and in most cases the local techs have liked the new process.

While I'm not saying this workflow fits every situation, it is the one that works for us and is the most flexible (aside from DEP) to what Apple is going to do in the future.

Here's what I'm toying with at the moment, and would love some feedback. Boot to Setup Assistant and create our standard administrator account. Enroll in Jamf. Add computer to a "standard configuration" policy I've created which will install our standard apps, bind to the domain, etc. Does that sound reasonable/efficient?

@john.sherrod That is pretty close to what I have working, I have the add to deployment group as a Self Service policy and the deployment itself set for on startup.
So the process is currently:
Go through Apple Setup.
DEP or Quickadd.pkg
Run Self Service for auto image.
Restart - Deployment aoocurs automatically.

I acutlaly have DEP machines go straight into autodeployment, but I was too scared to have quickadd ones do this as then if someone manually re-enrolls the device to fix another issue (which sometimes happens) the deployment process would kick in again.

Prior to 10.13 I was installing macOS and binding to Casper out of Casper Imaging and having the auto deplyment kick in on first reboot, hope to get back to this once JAMF updates again.

@a.stonham Pretty sure we have 10.12.6 in there and it seems to be working, we are on JSS 9.100. so not sure if they patched and I just never had it not working or what.

@john.sherrod rather than having to jump into the JSS to assign a machine to a policy, you can use a Smart Group that is scoped to "Last Enrollmemt Less Than 1 day" and then limit the Self Service policy to asked LDAP user or group. So after enrolling the device, open Self Service, login with an LDAP account that is authorized, click install on your provisioning policy.

@stevewood Ooh! Great idea!

I use a similar method to the OP's. We boot a machine that needs to be imaged to an external boot drive or to a secondary partition and use Casper Imaging. Many of our computers can't use netboot (a bureau in Lagos Nigeria with five people and 1Mbps download speed for example), so Net-anything is problematic. In fact in many cases we usually ship an external boot drive with a copy of the repository on it.

I've built a base OS image with the latest version of AutoDMG which supports APFS and I'm ignoring the firmware issues for the moment. When I go to image a machine using our previous workflow, and Jamf 9.101, the OS package barely registers in the imaging process before it moves to the next package and eventually fails before completing.

At this point I don't know what I'm going to do. DEP is great, if your clients are in the 1st world with real broadband. Our users in Lagos, or Johannesburg, or Jakarta, or even Denver and Dallas, are not going to have great experiences with reimaging when needed. We'll be able to use DEP in the office when we prep machines for initial deployment, but that's probably the only time we'll really use DEP.

@cwaldrip

What OS are you using on the external boot? in my testing I went 10.13 on external boot/netboot. IIRC 10.12.6 is the earliest to recognize apfs..just a thought

@stevewood We've been leaning this route, but the problem we're running into is that for some reason VPP locks to our local admin account instead of the end users' account and forces us to break enrollment in order to get anything from the app store to install. What's your route for avoiding that issue?

@McAwesome Device Based VPP. We don't tie VPP to a user but to the device. Then it doesn't matter who is logged in.

Have you tried re-doing the MDM without breaking enrollment?

sudo jamf removeMDMProfile && jamf mdm –userLevelMdm

Might be able to do that after you've finished to get the proper user recognized.

@stevewood Same. Removing the profile caused a lot of issues due to us enforcing the MDM profile being present. That's why we had to choose between allowing the user to remove it(not gonna happen) or having to break enrollment every time a machine gets redone (not gonna happen). We're currently holding off on 10.13 as a result of that choice with no good options.

@Nix4Life The imaging drive and the restore partition i'm using in my testing are running 10.12.6.

If monolith imaging is not going to be supported by Apple, then what is JAMF's option for us? I use to create an OS package installer from Composer and upload it to Casper Imaging for deployment. I guess that does not work anymore. I hope JAMF has an alternative for us for High Sierra, since not everyone has DPP.