So with macOS Mojave, is imaging dead?

Secure Enclave on all hardware will mark the end of imaging.

simple answer....

YES!!!!!

I wonder if Secure Enclave will mean we lose this option too?

Imaging is already dead with 10.13 and APFS. All imaging solutions that exist for 10.13 are based on workarounds. I'd highly recommend to stay away from imaging.

I'm imaging using AutoDMG and HFS+ with 10.13.x and apart from the user approval for MDM and securetoken (not a problem unless you want to filevault), I'm not actually seeing any issues.

not a problem unless you want to filevault

So yeah, if you ignore security, then it works. Unfortunately Filevault is an enterprise requirement. TBH the writing has been on the wall for a few years. We were slow to recognize the future needs and are now paying catch up.

We use filevault on our devices that go offsite, ie. laptops but we don't "image" those as such anyway, we just run a policy that installs all of the software etc. so the accounts get a secure token without any issues.

This? Again? It is/was dead in macOS High Sierra. Get your procedures in line with thin provisioning or pay the price down the road. If the new workflows are not ideal for your org, perhaps the time spent on asking this question / trying to hack around what has been the "writing on the wall" for quite a while now would be better spent in contributing to testing the early beta seeds and submitting feedback / bug reports to Apple. I would hate to be in the position of needing to implement FileVault in an org which has deployed 10.13+ in a hacked manner...

Sadly we don't have a choice. We've been trying to implement VPP/DEP for at least a year but trying to get any action from those that have the power is proving to be almost impossible. That's coupled with the fact that for the majority of our configurations DEP just isn't a suitable solution.

Agreed that DEP can be a long slog, especially in a global organization. It is not strictly necessary though. USB boot media / Internet Recovery / Recovery Drive / 10.13.4+ policy/app based restore -> set up a standard temp admin account in Setup Assistant -> enroll via the Jamf User Initiated Enrollment portal -> policy based provisioning takes over. More touches, yes, but it works. If we can do it for thousands and thousands of Macs globally (including fully automated secureToken based FileVault enablement), it CAN be done.

I feel like being 100% straight-forward (as much as that is a thing with the info Apple trickles out) with leadership on the need to align processes with Apple, despite the loss of full automation will be your best course of action. There is going to come a point (secureboot) where hacking around "the writing on the wall" is going to go down in flames, and I would not want to be on that plane when it impacts.

Moral of the story: if you have not yet started aligning your workflows to the post 10.13 world of Apple provisioning, you are going to be in the hot seat when there is no other way to accomplish things on newly purchased Macs. Don't keep delaying the inevitable. Adapt. Evolve.

@dgreening That will be our method in the long run, I've already experimented with doing it that way so I know it will work for us. Lack of staff (or more precisely capable staff) is a hindrance to the semi-manual method so for my sanity we will carry on the old fashioned way for as long as we can. We don't currently filevault desktop macs with no mention of this happening in the near future. We will note the lack of secure token as risk on risk register but that's all we can do for now.

I haven't seen anything specific, but we have definitely moved our deployment workflows to DEP / VPP / Policy based processes some time ago.

We were long time users of NetRestore, ASR, DeployStudio and then Casper Imaging, but 10.12 really was the point where we moved away from those methods.

Secure boot / secure enclave does put a stop to it officially, and Apple may (or are likely to) implement that across their product range, but until they do, there isn't really a restriction in block copying to a disk, other than the usual catches that go along with it.

So wait if I've got software configurations set up in Jamf Admin, is there a way to "apply" the applications contained in those to a Mac without imaging, if you folks are saying imaging is now dead?

@DanJ_LRSFC You could easily automate application installs based on smart groups (For example; install if app doesn't exist). As long as the Mac is enrolled via Jamf you can set up a a chain of smart groups (which could be dependent of each other) to get it to the state you want (including bind and admin account creation)
.

Imaging's been dead for a long time

10.13.4 went a long way in turning bible thumping, soap box "The sky is falling" preaching into a practical opportunity to finally shift gears...

Firmware is one reason...a pretty big one...

How to install macOS at your organization https://support.apple.com/en-us/HT208020 "Apple doesn't recommend or support monolithic system imaging as an installation method, because the system image might not include model-specific information such as firmware updates."

Workflow is another reason...finally...

About the macOS High Sierra 10.13.4 Update https://support.apple.com/en-us/HT208533 "Adds the --eraseinstall flag to the startosinstall command in the macOS Installer app at Contents/Resources/startosinstall. Use this flag to erase and install macOS on a disk. For details, run startosinstall with the --usage flag."

Guessing some folks are going down the convoluted/inefficient road...IMHO...

How to reinstall macOS https://support.apple.com/en-us/HT204904 Command (⌘)-R Install the latest macOS that was installed on your Mac, without upgrading to a later version. Option-Command-R Upgrade to the latest macOS that is compatible with your Mac. Shift-Option-Command-R Requires macOS Sierra 10.12.4 or later. Install the macOS that came with your Mac, or the version closest to it that is still available.

No way to audit/manage the Startup Security Utility settings, pretty sure Jamf won't be able to gather the status until Apple provides criteria somewhere/somehow to hook into. Feature request submitted to Apple.

@davidacland we are going the same direction. My question is how to you "reimage" those older models that when going to Internet Restore only provide you the OS the machine was shipped with. I have already implemented thin imaging but this remains the only challenge

We've found that 10.13 netinstall images work fine for that purpose, and you can set them to automatically erase and install.

NetBoot is definitely an issue, with very long boot times and lots of failures, but a netinstall image on the same netboot server works really well.

@davidacland Thanks!

NetBoot-based workflows are also on the way out, as the T2 chip-equipped Macs can't NetBoot. I have a post discussing that, available via the link below:

https://derflounder.wordpress.com/2018/08/15/the-t2-macs-the-end-of-netboot-and-deploying-from-macos-recovery/

@rtrouton Thanks Rich!

In Jamf 200 Training we had detailed imaging training.
The Trainer was amazing, he was able to condense all the imaging material into 5 seconds:

https://isimagingdead.com/

DEP is not available in our country, so we wrote a tool very similar to https://github.com/google/restor. So if you still need to image things, there are definitely options around.

Imaging isn't necessarily dead, however, NetInstall may be. As long as the machine has the correct firmware, then you can image using Carbon Copy Cloner without a problem. For those machines with SIP enabled, you can disable it.

The problem is that Apple hasn't replaced the full functionality of an image with anything just as good. Instead of an image, they want you to use DEP, and MDM, and packages, and scripts, and, and, and, and. They took something that used to be so simple and over complicated it with a reliance on 3rd-party software. I could image a machine in 10 minutes. Now, Apple wants you to download and reinstall from scratch, then push out your policies, then reinstall all software. It's not efficient.

Yes.