Home > Apple File System, Mac administration, macOS > Imaging will be dead (soon-ish)

Imaging will be dead (soon-ish)

I don’t normally try to foretell the future but there is one change for Mac admins that I’m pretty sure will happen:

The coming of Apple File System (APFS) will mark the end of disk imaging on Macs.

For those not familiar with disk imaging, a disk image is a computer file containing the contents and structure of a disk volume. Mac disk images are applied to hard drives using the Apple Software Restore (asr) command line utility to erase the destination drive and then block-copy the data from the disk image onto the destination drive.

Mac deployment practices have generally fallen into one of three categories:

Monolithic imaging

Monolithic imaging is the practice of building a Mac with the desired operating system, desired software, and desired configuration settings, then creating a disk image which includes all the contents of that Mac’s boot drive, including the operating system, installed software, and settings.

Once that disk image is created, the image is then applied to multiple other Macs to make them just like the original Mac.

Modular imaging

Modular imaging is the practice of creating a disk image that contains only the base OS (as well as necessary OS updates from Apple).

Once that disk image is created, the image is applied to multiple other Macs. Desired software and desired configuration settings are then installed onto the newly-imaged Mac as post-imaging deployment tasks.

Thin imaging

Thin imaging is technically not an imaging practice, as no disk image is involved. Instead, the assumption is that Macs from Apple come with a pre-installed OS and that OS should be used instead of wiping it and replacing it with a new copy from a disk image.

In this scenario, a deployment workflow is run which installs the desired software and desired configuration settings onto the Mac. If a Mac needs to be wiped and re-setup, a fresh copy of the OS is installed via the Recovery environment or similar OS installation process and then the thin imaging deployment workflow is re-run.

Imaging using asr has been around for a long time (I first began using it back in the Mac OS X 10.2.x days) but there have been strong hints that those days are coming to an end. The most visible of these was this tweet from the makers of DeployStudio:

While the makers of DeployStudio don’t speak for Apple, a statement like this matches up with what I’ve heard from other Mac admins who have independently received similar messages as part of their communication with Apple. Apple hasn’t commented publicly one way or the other, so unfortunately I can’t be more specific than that.

If imaging isn’t available, what are the alternatives? Apple has been encouraging the use of Apple’s Device Enrollment Program, which leverages a company, school or institutions’ mobile device management (MDM) service. In this case, you would need to arrange with Apple or an Apple reseller to purchase Macs that are enrolled in your organization’s DEP.

When a DEP-enrolled Mac is started for the first time (or started after an OS reinstall), it is automatically configured to use your organizations’ MDM service and the device checks in with the MDM service. The MDM service then configures the Mac as desired with your organization’s software and configuration settings. A good example of what this process may look like can be seen here.

What if you don’t have DEP, or you don’t have MDM? In that case, you may still be able to leverage a thin imaging deployment workflow, which installs the desired software and desired configuration settings onto the Mac’s existing OS. To get an existing OS though, you would need to install it via the Recovery environment or a similar OS installation process.

Planning for the future

Today, imaging works and our deployment workflows are what they are. What should be done to prepare for the future?

If you’re already using DEP with MDM to set up your Macs:

  1. Congratulations! You’re good to go with a Apple-supported deployment workflow that should work fine for the foreseeable future.

If you’re not using DEP with MDM to set up your Macs:

  1. If DEP is an option for your organization and you have an existing MDM service, investigate using Apple’s DEP service to set up your Macs for deployment. You may find that DEP doesn’t work for you in its current form, but now is the time to find that out and work with Apple to get those parts fixed.
  2. If DEP isn’t an option for your organization (because you aren’t using MDM and/or you aren’t in a country where DEP is supported) and you aren’t using a thin imaging deployment workflow now, I recommend investing the time and effort to start using a thin imaging workflow. In particular, if you are using monolithic imaging to set up your Macs, it is time to stop and transition to an alternate way of deploying Macs before that imaging method abruptly stops working.

When will we know how long imaging has left? My recommendation will be to watch what Apple reveals at this summer’s WWDC 2017 conference and pay particular attention to any device management or APFS developments that are being announced, as those announcements should likely provide the best information.

  1. dgreening
    January 10, 2017 at 7:52 pm

  2. January 10, 2017 at 10:58 pm

    If only internal infra could keep up with Apple’s OS development. I’d be thin as thin can be, but can’t use Sierra, yet 😦

    • DrChuTang
      February 9, 2017 at 8:21 pm

      It’s impossible for me to keep up with “current os’s” when I manage over 10,000 macs of all different flavors and we’re short staffed!! ugh..

      • February 10, 2017 at 3:09 pm

        Ahem… so where is this magical land full of Macs in need of staff to support them? ;^)

  3. Bob Gendler
    January 11, 2017 at 3:11 pm

    We recently met with our Apple Systems Engineer and he mentioned basically this same thing, that there will be a time in the near future when imaging is dead. He seemed to think that the MacOS will be going to more of an iOS model where you really cant change much of the system. He also seemed to hint that all configuration would be done through Configuration Profiles.

  4. cashxx
    January 11, 2017 at 8:08 pm

    We kinda already see that it is going to an iOS model. Implementing rootless mode, etc. The writing is on the wall and just a matter of time and it makes sense that it would happen with the new file system. I personally disagree with it because I edit all kinds of files and stuff and would probably have a 100 packages to make and keep up to date if I kept everything separate. I’d rather have the golden image monolithic way personally.

  5. ooshnoo
    January 12, 2017 at 4:47 pm

    What about when you have to repurpose a Mac for another employee? If this required around here, image it with a fresh copy of OS X. Not sure at this time how it would be quickly accomplished if imaging is dead.

    • dgreening
      January 12, 2017 at 5:25 pm

      Seems Internet Recovery based restore (stinks that you cant choose OS) leveraging Caching Server and then putting the machine through DEP based enrollment into Jamf with prestages is going to be the only path… What do we do in countries which don’t support DEP though… Don’t like to have different processes to accomplish the same goal.

    • January 16, 2017 at 2:51 am

      The magic sauce of APFS is snapshotting. Imagine an iOS style Settings > Reset > Erase All Content and Settings for you Mac.

      On macOS that potentially looks like reverting to the factory installed snapshot, all user data gone, ready to go OOTB Mac in a matter of seconds.

      No need for even an internet recovery (apart from baremetal new disks — which are less of a thing in future macs anyway).

      • January 9, 2018 at 2:21 am

        If imaging goes back to factory then what about installing applications? If you have 5 or 10 custom apps that take an hour each and 1000 Macs (eg school lab or developer environments) does that mean I need 100 technicians and 40000 hours of time to do the installs? SO I now need a Week per machine and at least one tech to start finish each install. and do that 1000 times? seriously?

  6. Zan Lynx
    January 13, 2017 at 1:14 am

    Any information on WHY imaging doesn’t work?

    After 60 years of filesystem development we’ve determined that writing hardware details into the structure is a failed idea. Abstract all the things and let blocks be blocks.

    I am betting that it’s some interaction of encryption keys and system TPM, which should be solvable by regenerating those after the mirror. But I don’t know and I am curious.

  7. cashxx
    January 13, 2017 at 2:05 am

    It’s a shame….isn’t this stuff supposed to get easier as time moves on?….lol. Things are getting far more complex and harder!

  8. January 14, 2017 at 5:32 pm

    Great article as always. We’ve been calling it Thin Provisioning, since, well, our process doesn’t include an image.

  9. January 14, 2017 at 5:33 pm

    [image]http://donmontalvo.com/jamf/jamfnation/its-called-thin-provisioning/Its-called-thin-provisioning-got.png[/image]

  10. Gurduv
    January 15, 2017 at 8:14 am

    What about createOSXinstallPkg?
    It’s still a solution that save at least download time of the full OS.

  11. January 16, 2017 at 4:27 pm

    “Imaging using asr has been around for a long time (I first began using it back in the Mac OS X 10.2.x days)…”

    I must be old… we were using ASR from boot CDs to image via AppleShare Server using Mac OS 8, way back in the 1900s. Such fun! ;^)

    • cashxx
      January 17, 2017 at 6:44 pm

      lol….used ASR as well then with OS 8 and OS 9. We used a program called Assimilator to put it back on the Mac from a network share. On my “internship” for college I showed my boss how to do this and blew his mind away. He was a Windows guy and would hand reload the Mac and take hours to do when one would mess up. I think they were LC 580 models or something like that running iOS 7 for those.

  12. January 17, 2017 at 3:55 pm

    Ugh…so, then, that brings up some more questions and concerns…

    1. According to Apple’s faq(https://support.apple.com/en-us/HT204142) machines purchased after March 1, 2011 can be enrolled in DEP. There are currently a limited number of systems that are compatible with Sierra and still would not qualify to work with DEP. We still have about 40 of those systems in operation. If we see this year where APFS is required with the new OS and imaging is no more, I would guess Apple drops those models from being compatible with the new OS. This does not bode well and could mean PC’s replacing them. I don’t see our campus here in Illinois ponying up the dollars to replace 40+ systems this next year. The money situation is bad in this state for schools.

    2. What about Macs purchased through other vendors like Best Buy? Last I knew there was not a way to enroll them in DEP. We have had certain people on campus who didn’t follow IT’s system of purchasing and would go out and buy their own hardware so they can get what they want or at a cheaper price. This process should now be addressed that we have a real CIO but it doesn’t change older systems that we’re currently managing.

    3. If imaging is dead, would that kill off the ability in Casper/Jamf Pro to use dmg’s to distribute files and settings?

    Gotta love technology!

  13. Bert C
    March 13, 2017 at 11:47 pm

    Does 10.13 with APFS marks the end of Deploy Studio?
    I hope not. Will DS be incompatible with APFS?

    I know it only takes 5-9 minutes to image our 42GB fully configured and updated student master image to an SSD equipped Macintosh.

    I am curious to see how much time it takes for Apple’s over the internet thin or modular imaging combined w/ scripting to install Adobe and Office (with or w/o JAMF) on each machine. Will Apple insure that the macOS will always be updated on each image? What about iLife and iWorks Suite, are they part of the macOS base image and will they be fully updated or do we still have to run softwareupdate? I know these can be scripted that can be pushed during log-in in via Profile Manager or JAMF but it adds time.

    AFAIK, thin imaging are for new machines w/ base OSX system already installed. On machines that needs to be wiped and system installed, how long does modular imaging via macOS recovery take?

    I have yet to see how this would save time when you compare to monolithic imaging via DS then run update scripts.

    Not having an easy solution, like what we’re used to*, to connect a Retina Macbook or 2016 Macbook Pro to ethernet, could slow down imaging as each will take over an hour to image via cobbled together USB-C to USB then USB to ethernet**. Thin or modular imaging a base macOS could be faster on these models.

    From APFS Guide Frequently Asked Questions:
    Can I use Apple File System with my existing hard disk drive?
    Yes. Apple File System is optimized for Flash/SSD storage, but can also be used with traditional hard disk drives (HDD) and external, direct-attached storage.

    “can also be used”… can you imagine how long the internet imaging into HDD is going to be? How many students will be able to buy new computers or upgrade their non-retina MBP to SSD?

    What happens when this becomes a high bar to some schools? What are the other options?
    I’m sure Chromebooks could be an option to some schools…
    http://kstp.com/technology/google-chromebook-rise-us-schools/4396479/
    http://www.voanews.com/a/google-chromebooks-on-rise/3718334.html
    https://www.fredericknewspost.com/news/education/funding/chromebooks-in-the-classroom-the-rise-of-chromebooks-at-frederick/article_c1f7d9dd-504f-54bb-a3f5-07be09f50bf1.html

    *Thunderbolt to gigabit ethernet imaging to an SSD via Deploy Studio takes around 5-9 minutes to image a 42GB master image.

    **On the six 3rd party USB-C to ethernet adapters that I have tested. Most only works on 2016 MacBook Pro w/ Touchbar, there are no known USB-C to ethernet adapter that works on a 2015/2016 Retina Macbook. I have not tested a non-touchbar 2016 Macbook Pro.

    • Bert C
      March 13, 2017 at 11:55 pm

      Edits:

      replace “to connect…” to “to netboot a Retina Macbook or 2016 Macbook Pro via ethernet”

      and

      replace “Most only works on 2016 MacBook Pro…” with “Most can only netboot 2016 MacBook Pro…”

    • tbridge
      March 14, 2017 at 12:26 am

      As someone who manages a deployment structure of around 40GB per workstation, we’re quite happy deploying OS + Management Agent and letting the Management Agent do the rest. We get repeatable systems without cruft, and without issue, and we’re ready for a future where ASR isn’t an option.

      Sure, you could opt for Chromebooks as a replacement, and that’s a choice that some environments may find advantageous. We should always be looking for technology that best suits our requirements.

      But overall, I think there’s a substantial benefit to APFS, and I look forward to no longer imaging.

  14. Karl Kuehn
    March 16, 2017 at 10:21 pm

    I don’t think that this articles central premise is true at all. There is noting in AFPS that precludes imaging. It certainly will break the current tools, but at a technical details level, not at a fundamental concept one. At worst it would break the current `asr` tool’s method of block-by-block restore, require it to fallback to the file-by-file method (slower, but still faster than running installers).

    I have good (and unfortunately NDAed) knowledge that Apple internally uses `asr` in the manufacturing process, meaning that it will have to be updated before it ships on new MacOS computers (or a new method of imaging computers be brought in to replace it). Plus there is a lot of internal testing groups at Apple that are absolutely dependent on quick restores of various images, and nothing beats a block-by-block copy.

    So there may be some period of time where DeployStudio and Imgr are broken, then they will adapt to the new tools or changes needed, and we will be back to where we are now.

    • NightFlight
      June 27, 2017 at 1:35 pm

      Its been said before that there’s an advantage to what is essentially this proprietary copy of ZFS. Snapshots preclude the requirement for erase, not that quick erase is a big deal. However what if you require a N-pass erase for decommission or hardware testing processes? It will have to be made available in the disk utility. There’s nothing stopping these developments other than laziness on the developers part. We’ve made some (historically based?) assumptions that the developer is lazy.

      All it takes is for Apple to code APFS into ASR. Give it an update. I don’t think that’s much to ask. Alternately a third party can capitalize on it and create a block copy tool that writes out APFS (with IP support please). Look at this way. Every time Apple drops the ball – there’s money to be made in the niche market created.

      • NightFlight
        June 27, 2017 at 1:51 pm

        Okay, maybe APFS is not a copy of ZFS – that was going a bit far.

  15. Steve Paquette
    November 15, 2017 at 3:50 pm

    not having luck building an out of box image for high sierra, we have hundreds of deployed mac book airs that were deployed prior to our DEP/ASM/Jamf rollout, looking to do a quick image from thunderbolt SSD to wipe so it comes up out of the box and grabs our profiles.
    Not looking for anything custom just current- too many updates, it takes an hour to get current.

  16. nifty
    January 17, 2018 at 8:50 pm

    foresight that is proving true.

  17. June 11, 2018 at 9:05 pm

    Ugh, I only just finished building out a monolithic imaging process and then I read this article from over a year ago.

    Does DerFlounder have any recommendations or articles on MDM solutions? I don’t really know anything about MDM solutions. My requirements are really just to manage Macbooks, though. (i.e. no handheld devices or tablets)

  1. No trackbacks yet.

Leave a comment