Critical update won't install after imaging

@AVmcclint TouchBar Macs? I think you're seeing this

Yep. TouchBar Macs. that is exactly what we're seeing! The problem is our internet is highly restricted via Proxy server. Absolutely no data flows in or out without going through the proxy. But there is never even an option given to enter the proxy info or choose an unsecured wifi. It doesn't look like anyone has found an actual fix.

If you have a developer account please file a radar on this behavior. I've opened an enterprise case. Unless Apple gets a lot of guff about this I don't think they will consider it as "needing fixed". I'm all about the new imagingless order but our environment is such that devices are frequently "nuked and paved". In the apple future there still needs to be a process for quickly wiping and redeploying devices en masse. Internet Recovery quickly breaks down at scale.

Done. Unfortunately it doesn't look like any traction has happened since the guy wrote that blog entry in November. I suspect I may have to take each Mac home with me and plug into my home network via ethernet adapter to get these Macs working.

If I understand what's happening it's that when a hard drive is completely wiped clean and partitioned, the EFI volume is also deleted and that means the Embedded OS is deleted. Upon first boot after imaging, the Mac tries to reinstall the Embedded OS via the internet. There are lots of problems with this scenario in a highly restricted corporate network that Apple needs to address.

My question for JAMF is: Is it possible to include the EFI partition with the Embedded OS when we create images with Composer? If it isn't currently possible with the version available now, is it something that we can request for future versions? Would the inclusion of such a partition cause problems if installed on non-TouchBar Macs?

It seems this post got posted twice, minutes apart.. so I'll update this thread with what I wrote in the other one since this one seems to have more traction:

@AVmcclint So we've ran into this recently and have an open ticket with Apple about it. Couple of gotchas with these touchbar Macs:

• In addition to the blog post that @Kaltsas mentioned (which is a great read btw), Apple has confirmed to me that if you touch the EFI partition in any way, you get that prompt.
• Apple confirmed OS updates, right now just 10.12.2, also tie into these touchbar updates. When you download the update from softwareupdate or the App Store, it also downloads the firmware in the background from Apple into the following directory for reference later during the restart for the 10.12.2 update:

/usr/standalone/firmware

• If, for some reason like at my company, the places it goes to get those updates for the touchbar are blocked on your network, it can't download them and therefore, when you restart you get the screen you provided.

• Also, if you do get that prompt for any reason, you essentially have to have an open network to get them.. meaning, no fancy authentication as it is not supported from the Mini-setup assistant that pops up for this update. At my company, we used certificate based authentication to get on both internal wired and wireless (not supported). Also, our guest networks require authentication through a web portal/web page (also not supported). Apple has told me this is a bug and have submitted to product engineering for review.

In the meantime, the Macs are essentially bricked until they can get that update, as the blog posts states. Apple also told me as long as you don't destroy the hard disk when re-imaging, the EFI partition should remain. However, that has not been my experience and even with a brand new Mac, using the OS it comes with (meaning, no erasing, no re-imaging, just configured).. after rebooting for the 10.12.2 update, I get that prompt for a "critical software update".

I've received the following possible URLs from Apple that need to be open for this:

gs.apple.com
gg.apple.com
gnf-mdn.apple.com
sk1.apple.com

I know at least gs.apple.com is mentioned in the blog post about this. As far as I know, there is no official KB about this from Apple, nor a mention of it anywhere by them. That blog post was really the only thing I could find about this topic.

I can update this thread as I get more information.

My original post was accidentally posted twice. Comments are building on both posts. Here is the link to the other post.

@AVmcclint ,@perrycj

May I ask why Nuke and Pave?

@LSinNY No nuke and paving here. This happens with a brand new Mac, using the OS it comes with after doing an OS update.. in this case, 10.12.1 to 10.12.2.

yep @perrycj missed the section in your post about reimaging.Please keep us updated

I do a nuke & pave because I want to make absolutely certain that all the Macs were setup the exact same way. It is very rare but I have seen brand new Macs right out of the box with slightly different partitioning... a few GB of unpartitioned space sometimes. Nuke & pave is also applicable for replacement hard drives.

Followup: I took the Mac home with me and plugged it in to my home network via Ethernet and when I powered it on, it instantly connected and downloaded the EmbeddedOS. I could tell the exact moment it finished because the TouchBar lit up and came to life. Obviously I can't do this for every new Mac I image. I'm trying to work with our infosec/network folks to give me just one network port that doesn't need the proxy. I have a feeling that ain't happening in my lifetime though. :(

My second blog post on this should help lead you in the right direction:

Offline Activation with a purged disk

Since you are wiping a factory configured device it won't be encrypted. You could write a script that extracts the activation data and lay it back on the new EFI volume.

I think I've found a solution to this that doesn't involve external network access!

I created a package that contains /usr/standalone/firmware/iBridge1_1Customer.bundle (pulled from a 2016 MacBook Pro with 10.12.3), and then added that as a before-reboot package in Casper Imaging. Even after wiping the whole partition map, that package seems to allow a normal, non-Setup Assistant boot post-imaging.

@bvrooman That sounds like a possible workaround, but 'solution' seems excessive. ;) I also expect that when new models come out, we may need different packages for each model. However, I will say congrats if it works! I'll give it a try now.

EDIT: yes, this process works for me. I'm worried about it long-term, but at least it works for now.

@bvrooman Does the presence of that package on a non-TouchBar Mac affect it at all?

@AVmcclint No, it does not appear to cause a problem. Machine appears to have booted fine and ignored that /usr/standalone/firmware directory...

Looks like that package (of the /usr/standalone/firmware) directory is unique for different model touchbar macs. This solution may work, but does require I build a unique package for each unique Mac model.

@thoule It appears to be the same on two slightly-different 15" models and a 13" model in my lab, all on 10.12.3 (the iBridge1_1Customer.bundle is version 502, and a diff doesn't find anything). I also built the package on my 15" and used it during imaging on another 13" with no issues.

Perhaps there's a difference between different OS updates?

@bvrooman What do you have in that package? Just the iBridge bundle? Mine isn't working- even on the machine I pulled the file from...

I packaged /usr/standalone/firmware/iBridge1_1Customer.bundle with its original permissions (owned by root, 755 on folders, 644 on files).

I also added a preinstall script that will stop the install if that bundle already exists on the target drive and the CFBundleShortVersionString in the existing file is greater than the same key in the bundle to be installed. I'm not sure that matters, but I wanted to avoid unintentional downgrades in case that would cause an issue.

I tried this solution as well. Both just packaging the: (1) iBridge1_1Customer.bundle, and (2) everything in the /usr/standalone directory.

Set up a workflow to install after DeployStudio wiped the drive, laid down a base image, and then ran the installer (prior to reboot).

Both runs still yielded the same critical update issue.

Perhaps it's something in DeployStudio doing it? We're using Casper Imaging, and just imaged more machines today with no issues.

The bundle in question is also the only thing Apple ships in its EmbeddedOSFirmware.pkg that comes along with 10.12.3:

I have been unable to verify @bvrooman 's findings. My findings are more in line with Erik Gomez's work.

http://blog.eriknicolasgomez.com/2016/11/27/the-untouchables-apples-new-os-activation-for-touch-bar-macbook-pros/
http://blog.eriknicolasgomez.com/2016/11/30/the-untouchables-pt-2-offline-touchbar-activation-with-a-purged-disk/

In short, if you wipe the EFI partition, you can only get the mac online again if you connect to Apple over a network or you had previously backed up the EFI partition and the FDRData from preflight.

I guess it's possible that our Macs are reaching out during their first boot and getting the software they need from Apple, and that the package I'm deploying is useless, but it seems unlikely given that our proxy settings would be nowhere on the machine at that point. It also doesn't explain our 100% success rate with the package being installed and 0% without. It was really that consistent for us, which is great since it worked and not great since apparently no one can reproduce it.

I'm not saying anyone else is wrong (obviously I can't argue with results) - just that it doesn't match what I'm seeing. It would be great to know more about what's going on before 10.12.4 breaks what we're all doing and requires some other unknown workflow.