ARD 3.8.5 Screen Sharing Broken by Sierra 10.12.2 Update

I manage multiple iMac labs from an iMac (27-inch, Late 2013) 3.5 GHz Intel Core i7 32 GB 1600 MHz DDR3. All my iMacs (iMac (21.5-inch, Late 2015 -1.6 GHz Intel Core i5 - 2.7 GHz Intel Core i5 8 GB 1600 MHz DDR3) which are kept updated to the latest OS and Security patches.

Every functioned perfectly when on ARD 3.8.5 Sierra 10.12.1 .

I didn't notice any issues on my test machine before running the update on an entire lab. After a few remote tests, all seemed good. I didn't test screen sharing (I will add that to tests in the future).

After I updated I began a screen share session to share my screen with 28 iMacs running Sierra 10.12.2 from ARD 3.8.5 Admin to 3.8.5 Clients for demonstrating how to perform tasks in a review of a lesson and discovered that they had all been displaying a crash notice:

Shared Screen Viewer quit unexpectedly Click Reopen to open the application again. Click Report to see more detailed information and send a report to Apple.

My Active Share Screen Tasks box was still running as if nothing went wrong. This is an essential tool for instruction in my labs. Presenting students with live demonstrations right on there on screen is a significant feature that eliminates the issues associated with workstations being to far from the projected screen at the end of the room.

Trouble shooting with Apple was unsuccessful on every level. They could not remote in to any machine to view and test themselves. No one has offered any solutions.

I tested creation of a new user login on the chance that it was an issue within the users accounts after testing both the Administrator and Student accounts with no improvement. Permission/Disk utility repairs had no effect. Out of desperation I ran restore/reinstall which is a long and painful process but if it was also unsuccessful.

I've experimented with running screen shares to other macs running earlier ARD and OS installs: iMac on 10.7.5 , another iMac on 10.10.5 and most significantly, 10.12.1, using a backup partition of my test machine from before this update.

Toggling settings in Remote Management in every way imaginable did not resolve the issue. Sharing a target with other targets alternatively did not work either.

I later discovered that I could not use keystroke command combinations when controlling an individual target computer but that is really the least of the issues at this point.

I attempted to run this screen share test from a MacBook pro 2010 running 10.12.2 once again on the test machine that reinstall/restore was just run and for one attempt it seemed to work. I quickly attempted to run the screen share on another machine in the lab and it failed. I returned to attempt the screen share again on the one that just worked and it went back to failing. :-(

One call back when I was teaching and then no there has been no other communication attempts from or messages of any kind were back from Apple engineers on this issue. Very frustrating!

Restore/Repair didn't help because it automatically updated back to 10.12.2 and that is the problem. If I could just roll back to 10.12.0 and run 10.12.1, that would have solved the issue but that did not turn out to be the case.

No other choice but to SOLVE by Going Nuclear!

How to Go Nuclear?

Create a partition by going to Disk Utility and clicking on the plus and naming the new partition Macintosh HD 2 (Makes restoring later less complicated)

Make a disk image of a computer that has the correct version and settings. (I had my original backup partition on a late 2012 iMac 2.7 Quad but the new 1.6 hardware kernel Panicked with that image so I ran ran the Recover Reinstaller and that fixed the issue after another few hours.)

I cloned the new image to an SD card thinking I would use that method but later decided to take the clone on the SD card and save it as a Disk Image and send that to the targets desktop over night.

Came in this morning and opened up disk utility after having created the new partitions yesterday during lunch, I was ready to restore the image on the desktop to the new Macintosh HD2. 45 Minutes later, booted the macs into that new image and transferred the Shared folder contents and the Documents folder contents. (The only reason I did the transfers this way is the size of the Shared folder was over 20gigs and that exceeded the SD card size for my backup image and I use alias's copied to the desktop that point to the shared folder which are specially setup to prevent students from saving to the shared folder or changing the file samples). It also kept the restore time to under 10 minutes but it took me the full 40 to get to every machine physically.

Once all the transfers were done the last steps needed were to rename the partitions to keep my shortcuts and copy to targets functioning which required quite a bit of authentication but changing the Macintosh HD2 to Macintosh HD and Macintosh HD to Macintosh HD2 now allows me to have at least a backup partition to run any maintenance or repairs internally.

The last two steps to ending this nightmare require renaming the shared names of the lab to match the actual workstation and setting the startup partition back to Macintosh HD.

What have we learned? Don't run software updates unless you have no choice or enough time has gone by to be sure that the update doesn't create more problems than it solves and always try an update on one or a few machines before rolling it out to a large number of machines.

Hope that helps.

Jeff