Casper Imaging (Direct write or target mode) failing on Late 2016 MBPs w/touchbar.

DSItPurchasing
New Contributor

We're starting our rollout of JAMF (cloud hosteD) and alongside it significantly increasing our install base of Macs. Currently trying to get these things imaged. I'm a windows guy primarily trying to wrap my head around this and any advise or someone catching an obvious gotcha would be appreciated.

I have Casper suite and a network file share distribution point on the same subnet. Have tried imaging both directly selecting the drive in casper imaging and in target mode using apple branded USB-C > Thunderbolt2 dongle and apple branded thunderbolt2 cable. The drive is being erased by casper and its deploying a completely clean install of Sierra 10.12.5 with no other packages, and is forcing setup assistant.

The image completes successfully according JSS's logging and takes an appropriate amount of time based on the fact that its pulling down from a networked file share. After it 'completes' the drive unmounts from the box running casper imaging then remounts, and the machine sits on the target mode imaging screen. It shows 1 image completed in Casper Imaging. After we reboot the machine we get a rapid boot to a black screen with circle/slash symbol. Rebooting to recovery results in the same. Have tried clearing PRAM and SMC, no deal. Rebooting holding option lists both the EFI and recovery as options but neither is bootable. It happily goes back into target mode from that screen but trying to image it is unsuccessful.

This same setup/system works perfectly fine on older Mac models IT has lying around for testing or in storage (2011-2012 model MBs mostly, and a 2015 Macbook Air). Is there something different about this configuration that would cause this to be unsupported or is there an obvious mistake I've delineated?

Thanks! -Josh

18 REPLIES 18

donmontalvo
Esteemed Contributor III

(duplicate)

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

@DSItPurchasing wrote:

I'm a windows guy primarily trying to wrap my head around this and any advise or someone catching an obvious gotcha would be appreciated.

Rule #1...don't touch the OS.

Rule #2...Thin Provision (layer onto existing OS).

--
https://donmontalvo.com

milesleacy
Valued Contributor
is there an obvious mistake I've delineated?

In a word, imaging.

Imaging as a Mac deployment workflow has been dying for years. With recent versions of macOS, recent hardware releases, and this year's WWDC announcements and beta releases, even many of the head-in-the-sand, die-hard proponents of imaging are coming around to the fact.

Your best-case, best-practice workflow is to enroll a Mac (or better yet, let the user enroll it) and let policies, configuration profiles, MDM App Store installs, etc. install software and set settings on top of the factory macOS install to meet your organization's needs.

mpermann
Valued Contributor II

@DSItPurchasing it sounds to me like you are imaging MacBook Pro 2017 models. This model came with a special 10.12.5 build. If the base 10.12.5 your building isn't the specific build for the computer the system will not boot. You should try and build a new base image with 10.12.6 and try restoring it. That will likely fix your issue. The 10.12.6 installer from the Mac App Store unifies the OS and it's now universal and will work for the new models. If it doesn't, post back and I'll do my best to help you figure out what is going wrong.

DSItPurchasing
New Contributor
The 10.12.6 installer from the Mac App Store unifies the OS and it's now universal and will work for the new models. If it doesn't, post back and I'll do my best to help you figure out what is going wrong.

Oooh. Good to know, I'll give that a shot. We were using an 10.12.5 installed built during our JAMF onboarding from an older MBP. Downloading now, Finger's crossed. Thanks!

Rule #1...don't touch the OS. Rule #2...Thin Provision (layer onto existing OS).

Thats nice and all, but I need to at least be able to unbrick this one. Also we need some way to wipe and clean slate machines before redeployment. Until that functionality is hard unworkable we're going to be at least in part relying on imaging. Its just a thin OSx image, we're not baking installers or anything into it...everything else is being deployed by JAMF.

milesleacy
Valued Contributor
I need to at least be able to unbrick this one. Also we need some way to wipe and clean slate machines before redeployment.

Apple provides the recovery system for this.
About macOS Recovery (Apple support article)
Recovery systems are cacheable by the Apple caching service.

Until that functionality is hard unworkable we're going to be at least in part relying on imaging.

How do you define "hard unworkable"? It's pretty hard and unworkable already, especially as compared to the alternative.

Would you prefer to invest in familiar but bad processes that drain time and resources or embrace new, unfamiliar, but more efficient processes? It seems like you are starting a new Mac deployment and support discipline at your organization. Does it make sense to start with known-bad legacy processes or take the opportunity to build your discipline according to current best practices?

McAwesome
Valued Contributor

@milesleacy I'd say we're still not at the point where we can completely disregard imaging even with the newest machines. If we have a need to do a full erase(common due to sensitive data on computers), our current options are image, dedicated "Install Sierra" drive, or Internet Recovery. In my environment, Internet Recovery would take about 10 hours to download to these machines. That's after we had Apple tell us exactly what to do to get things from them to download as fast as possible. Imaging took 20 minutes. While we could have a dedicated OS installer flashdrive, it makes no sense to use that when we already solved that problem with Casper Imaging.

milesleacy
Valued Contributor

@McAwesome If that's what you deal with in your environment, then you do what you have to do to make it work for you.

I don't understand why would it take 10 hours to download ~6GB over Gigabit Ethernet from your caching server. If it were me, I'd be solving for that problem.

gachowski
Valued Contributor II

@McAwesome

You could also set up macOS server and use netinstall. That is what we do and it is Apple recommend.

C

donmontalvo
Esteemed Contributor III

@gachowski wrote:

@McAwesome You could also set up macOS server and use netinstall. That is what we do and it is Apple recommend. C

c215eff5f1a14fbb8ce5bdfaf52503c5

#runningForCover

--
https://donmontalvo.com

McAwesome
Valued Contributor

@gachowski Our Apple Rep has never recommended that, and has actually told us it wouldn't really be worth setting up anything new just yet due to the big changes with 10.13. What we do now would work for 99% of our cases, and work well. Building/testing the cacheing server is a lot of work for a 1% case that's going away with 10.13's release anyway.

StoneMagnet
Contributor III

@McAwesome Caching Server is not going away with 10.13, Software Update Server is. You're going to need a functional Caching Server more than ever with 10.13 unless you want every Mac running it connecting to Apple's servers outside your network for app store updates. And setting up a Caching Server isn't a lot of work. The biggest issues are making sure it has access to Apple's servers through your firewall, it's properly configured for all the public IPs your organization uses, and your DNS has the proper _aaplcache._tcp entry (Server.app will generate that for you).

McAwesome
Valued Contributor

@StoneMagnet We have no issues whatsoever with our users using the App Store for App Store updates. We have an entire team here dedicated to making sure I never have to care about network access stuff. There is no benefit in my scenario to building a whole new server for a 1% problem, and no point building one to solve a non-issue.

gachowski
Valued Contributor II

I have been "mean" to all my limited number of Apple contacts, and nobody I know can say one way or another about netinstall going away in 10.13.x in fact the notes from WWDC are conflicting too. Based on that it's a reasonable guess that it's not going away or Apple would have had a replacement ready in the beta/seed programs.

C

sdagley
Esteemed Contributor II

@McAwesome Your "no issues whatsoever with our users using the App Store for App Store updates" doesn't really indicate how your update infrastructure is set up. Either you're running a local Caching Server to cache App Store updates, in which case you should also get automatic caching of the Internet Recovery installer (lack of fine grain control over what's cached/enabled is an annoyance for Caching Server), or your users are pulling App Store updates from servers outside your network. That is something a lot of us do care about, even if our organization's network isn't our responsibility, because having a local Caching Server benefits our users by making updates happen faster.

donmontalvo
Esteemed Contributor III

There's not much to setting up Caching Server. Check the box. Check another box if want to peer multiple Caching Servers. Its quite slick.

--
https://donmontalvo.com

McAwesome
Valued Contributor

@sdagley Again, we have no issues with it. There's no point setting all this stuff up for a 1% case. Our updates are absurdly fast as is(due to us being part of Internet2), and so there's not much of a benefit for the vast majority of updates. Literally the only thing that isn't insanely fast is internet recovery. There's no point jumping through all the hoops to set up and test the caching server when it is a non-issue 99% of the time. I have a lot more things I could be doing with my time that would actually address issues we see instead of ones other people have in their environments. It's just not worth it.

milesleacy
Valued Contributor

@McAwesome Again, your environment, you know what you're dealing with, but I find it hard to dismiss as a "1% case" the way things are now and Apple says will continue into the future in favor of viewing legacy processes put in place for legacy systems (perhaps before they were legacy) as the desirable majority. Legacy numbers will shrink and new computer numbers will grow, by definition.

I'd recommend taking advantage of the fact that the number of computers that require or prefer the new processes are small to allow you to gradually build in support for them and gradually shift your team(s) to the modern workflows. Waiting for Apple to flip the switch to kill a legacy technology that you're heavily invested in before you start exploring and building the modern alternative will just create unnecessary stress and problems for you, your team(s), and your users.

In the OP's case, unless I've misunderstood, the org is standing up a new Mac deployment and management discipline. Here, the answer isn't even a question to me. You build to the latest standards and processes. I can't help but call folly on introducing known-dead-or-dying processes in a new environment.