So with macOS Mojave, is imaging dead?

[ooshnoo]

There's been talk for months about this, but I haven't seen anything anywhere regarding deployment options for Mojave. Maybe it's restricted by hardware and not so much the OS?

Thoughts?

[djdavetrouble]

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

[retroroscoe]

simple answer....

YES!!!!!

[donmontalvo]

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

[m_entholzner]

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.

[allanp81]

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.

[easyedc]

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.

[allanp81]

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.

[dgreening]

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

[allanp81]

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.

[dgreening]

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.

[allanp81]

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

[davidacland]

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.

[DanJ_LRSFC]

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?

[tjhall]

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

[john_bio]

Imaging's been dead for a long time

[donmontalvo]

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.

[wmateo]

@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

[davidacland]

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.

[wmateo]

@davidacland Thanks!

[rtrouton]

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

[wmateo]

@rtrouton Thanks Rich!

[sonis718]

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/

[defiler]

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.

[nkuhl30]

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.

[tnielsen]

Yes.

[mm2270]

@nkuhl30 I've become an advocate of moving away from imaging and full on to DEP myself now, but you are correct. I recently experimented with the new T2 Mac mini's to clone or image one from the build of another, and Carbon Copy Cloner was able to create an exact duplicate of the configured device onto the new one in TDM in about 15-20 minutes. Granted, these were 2 identically spec'ed systems, so there was no difference in the hardware, firmware or software OOB. I'm sure that makes all the difference. And that being said, I wouldn't exactly call that process "imaging" as we used to think of it. More like "cloning".
And I would probably not try that going from say, a Mac mini to a 15" MBP with Touchbar. Probably not going to end well in that case.

[scottb]

Unless one has a fast, local DP to place "images" on, the time it takes to build and maintain lawd knows how many images it might take (per @mm2270 above) would make it so much less appealing than having users (assuming no local IT to do such things) install a clean macOS (or open the box) and provision using whatever tools/processes you put in place.

What we used to do with images took tons of man-hours to build, test, maintain that I could never see going back to that now.
Being able to add new apps and get users up and running beats the heck outta having to build new images every x weeks/month and when new HDW comes out.

Listen to the folks above. It's different and can be painful to get a new process(es) in place, but I feel well worth doing.
2¢, probably inflated...

[nkuhl30]

scottb, you're absolutely right. My problem is with Apple's lack of interest in creating the tools necessary for businesses to move away from imaging. Yes, there's DEP but it doesn't look like anyone uses Profile Manager around here. And if they're not using Profile Manager, then we need to go to the 3rd-party market. Once you've settled on something, like JAMF, it doesn't seem to be enough. There are several components needed to do the exact same thing that imaging took care of. That's my biggest problem.

Yes change is hard, but it's even harder when the management process starts to look like it was designed by Microsoft.

[Hugonaut]

@nkuhl30 as much as I love Apple, Microsoft actually did a better job - they actually provided a first party solution "SCCM" - What I want to know is where is Apples 1st party solution?

[nkuhl30]

@Hugonaut I agree completely. That's my point. They don't have one, or even care to have one.

[gmorgan]

http://isimagingdead.com/

[itupshot]

@nkuhl30

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.

I agree 100%. This is the most frustrating thing about the new process. I don't mind so much installing everything from their own packages (including the OS), but the fact that it takes so long to complete (even when you have everything lined up) is ridiculous.

I don't think any of us are advocating a return to monolithic imaging (even though that took the least amount of time), but the new imaging process should take 30 mins. max.

Also the documentation around the new process is incomplete or all over the place. There's no definitive official document showing you how to put it together. One has to log into this forum, attend a webinar, read knowledge base articles and admin guides (that may be outdated) just to piece together how you're going to accomplish this. We're all here because we use JamfPro, so where's the definitive step by step guide?

[scottb]

There are a lot more variables today for sure. LDAP? SSO? AD? DEP vs no DEP? Does your org maintain new(er) hardware? Do you need to keep it all updated regularly? No or few IT staff to help?
How many macOS versions do you need to support?

There is no doubt that the tools we need have to grow to meet the complexity of our clients. But they're not, so we're doing a Lego job of building and hoping we meet their needs...sometimes.

[Chris_Hafner]

Like most of the rest of you, I've finally come around. The DEP process IS NOT perfect, but I'm finally on board but mostly because Apple has skewered NetInstall. They've done this in the name of security and I'm OK with that. The DEP process will get better over time, but it is frustrating that the process is highly inefficient for large scale, local re-deployments. I know the tools will get better yet we used to "image" 48 laptops at a time, in about 15 min, fully automated including inventory, assignment, and everything. Our DEP deployment averages twice that and requires a user to be interacting with each device during the process, how we've currently configured it. This assumes that we don't want the end user to have to wait for policies to finish after they get their machine. Still, we're going this way and have changed our own internal purchasing policies to (mostly) eliminate the need to re-provision devices. I think it will be a net win in the end, but the transition is taking time and effort. Such is the IT life.

@scottb I think the folks who got hit the hardest were those of us who did need to churn and burn hundreds of local, deployable Apple products at a time. Those of us who did have fast DPs and NetBoot services. DEP is horribly inefficient when it comes to re-provisioning devices or dealing with any device that's not brand new in the box. Managing the policies isn't really any different from where I sit so... meh. Patch management is doing a lot more for me on that side of things.

Anyways, yea, imaging is as close enough to dead to call it.

P.S... there is this https://twocanoes.com/products/mac/mac-deploy-stick/ for those who may need to reprovision and want to roll the latest macOS while still working within Apple's current framework. Mind you, I've not tried it but I will probably look at it for our helpdesk.

[d_mccullough]

Imaging has been dead for some time now, since APFS/10.13; past methods of preparation and provisioning are going to hit a brick wall sooner, rather than later, so it's time for holdouts to start adapting. That impact is not going to be pretty.

[scottb]

@Chris_Hafner - I get it - was there too. I was only clued in enough reading here and other places about what others were doing to see what was inevitable. I enjoyed the old ways too in a sense, but it became clear, Apple was moving to a new way(s).
I still feel the pain from the XSAN's and XServe's we put into place, only to be left on Gilligan's Island by Apple's "commitment" to Enterprise.
So I understand, I'm just too old to fight the waves that have become bigger than me. Much bigger...

[rambro]

https://isimagingdead.com/

[dlang]

if you're under the gun and need to send an image, you can create a bootable partition on the the client machines with the JAMF imaging app on it., boot from there and image the main partition.

not sure how long that will be viable though.

to expand on this,
you can have a policy to boot to that partition and if you have it set to auto image, you can retain some automation.

[d_mccullough]

I have to keep sounding the "this has been coming for years, people keep trying kludge solutions; adapt now, because shortly there will be no option" horn. At this point clinging to the old ways of doing things will just make the impact hurt more when the brick wall arrives (which, honestly, it did already.)