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

(duplicate)

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

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.

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

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.

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?

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

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

@McAwesome

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

C

@gachowski wrote:

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

#runningForCover

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

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

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

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

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

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.

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

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