All of that said, today I pushed an update for my other two books to the iBooks Store! The main motivation was to update the “More Books” section in both with a link to the new book. But along with came a bunch of small fixes, corrections and even new subsections that have accumulated since the last update. (These are the eighth update for “Packaging” and the third update for “PR3”) You can see the details in the version history section in the iBooks Store and in each book.
If you have already bought the books, just go to your iBooks app and download the updated versions. If you have not bought them yet, you can get them here:
There is one more thought I want to add: I don’t consider this book complete yet.
This doesn’t sound like the best endorsement, so let me explain:
Apple is not only deprecating technologies for macOS deployments (imaging, NetBoot), but the pace for macOS releases is changing as well. I started writing this book in October, shortly after the release of High Sierra. However, with every update to 10.13 it became clear that Apple was not standing still. They kept iterating, sometimes quite drastically.
The iMac Pro introduced Secure Boot and we realized that NetBoot-based workflows would need to be retired much faster than initially assumed. Secure Boot also makes booting off external drives quite inconvenient. While this is great from a security standpoint, it removes yet another option for installation workflows.
Not even the proofreaders have seen the final version. (Can’t blame the remaining typos on them.) Existing workflows (or planned workflows) had to be adapted for the new hardware and updates.
I don’t expect this will stop at 10.13.4, or 10.13.5 or any time soon. We will have to update our practices to be more adaptable, and that includes writing books. I expect that 10.13.5 and future updates, new hardware with new features, and then 10.14 (whatever Apple will call it) will bring more changes.
Digital books are software, and can be treated as such. I wanted to “release early and often.”
When you buy the book now, you will receive new versions from the iBooks Store when I publish updates with new information, workflows and solutions. I plan to keep this up with the remaining 10.13 updates and all the way to the 10.14 release (presumably this fall). So by the end of this year, you should have a book with great information on how to install High Sierra and how to upgrade to and install 10.14.
Like for an app in the App Store, I have to consider how long it makes fiscal sense to maintain free updates. After the 10.14 release, I will evaluate the effort spent and make new plans from there. I will certainly write about that here.
There are also some parts of the book that I would have liked to have a bit more detail. I had set the myself the goal to get the book out before WWDC and 10.13.5, so some things had to put on the ‘later’ list. So, in addition to new content forced on us by updates and upgrades, I will keep improving, fixing, and adding to useful content as well.
I believe that “macOS Installation for Apple Administrators,” as it is now, already has a lot of great information and is well worth buying and reading. It will get even better.
At the end, a short request for help: The book is self-published. There is no big marketing machine behind this. If you like the book, then please leave a review on the iBooks Store. Apple’s stores segregate reviews by region, so every single review makes a big difference.
You can also help by recommending the book to another MacAdmin or presenting it at your local MacAdmins meeting, or just by simply sharing or re-tweeting my posts on social media.
Some interesting releases this week. Otherwise, you can tell that WWDC is approaching as the macOS/iOS wish lists are appearing.
In other news: I finished the first draft my next book “macOS Installation for Apple Administrators” and have sent it out the test-readers (thank you!). I posted an excerpt on my blog last week: macOS Installation: Strange New World
This topic has proven to be very volatile with Apple changing important parts of the workflows in nearly every update to 10.13. I don’t think this new book completely does the topic justice yet. There are many sections where I’d like to add more detail and depth.
However, I also believe it is already very useful in its current form, especially as ‘deployment season’ is approaching for education administrators, more secure boot Macs are likely to be announced at WWDC and the next macOS (10.14 or whatever) is looming on the horizon.
Like my other books, I plan to regularly update this book at least until the macOS 10.14 (or what ever it ill be called) release. When you purchase the book you will get the updates pushed from the iBooks Store for free.
Yesterday marked the day where Mac OS X has been available to the public longer than the previous Macintosh operating system (known as ‘Mac OS’ [with a space] or ‘Classic’ towards the end of its lifetime).
I do think it is a milestone worth noting. Darwin/Mac OS X/OS X/macOS has served as a stable foundation not just for the Mac but also for the iPhone, iPad, Apple TV, Apple Watch and now even the HomePod.
However, I have also seen comments that the “next age of the Mac” will have to happen soon, because Mac OS X/macOS is so old now. That statement really bugs me.
Mac OS X was not Apple’s first attempt at an operating system to replace ‘Classic.’ In the late 80s and early 90s it was already obvious that the Macintosh System architecture would not scale to modern CPUs and work requirements. An application that crashed would normally take down the entire OS. You had to assign memory to an application manually. System Extensions would frequently conflict with each other and also crash the entire system. There was no concept protected memory or segregating processes from each other. There were no multiple users with access privileges in the file system.
The operating system had been designed for a 8MHz 16-bit CPU with 128KiloByte of RAM where every cycle and every byte had to count! Apple was now in the PowerPC era and the requirements for the system were vastly different.
Taligent, Copland and Gershwin were successive efforts and promises for a better system that each failed for various reasons. Some of the parts of each did find their way into Mac OS. Then Apple bought NeXT (and Steve Jobs) and the rest is history.
So, for most of the nineties, it was obvious that the classic Macintosh system needed replacement something newer. Microsoft had Windows NT and alternative operating systems like BeOS and NeXTStep were showing the way. By the time Mac OS X arrived, classic Mac OS was old, but users needed to hang on to it because of critical applications and workflows.
Now, in 2018, macOS might be as old as Classic was in 2001, but it doesn’t feel as old. Like the original system for the Macintosh 128K, Mac OS X 10.0 was designed for entirely different hardware and use cases. In 2001 only the high-end PowerMacs had two CPUs. Mac OS X required at least 64MB of RAM (a 500 fold increase over the original Macintosh). Laptop batteries would last for three to four hours under the most ideal circumstances. Digital photography and video was still vastly inferior to analog. Music came from CDs. Screens had far lower resolutions and security meant requiring a password to login. Wifi was new, and hardly ubiquitous. Bluetooth was brand new and used in expensive cell phones which where used for talking, not data. There was no App Store.
All of this would change, sometimes quickly, over the next years.
Mac OS X and Apple as a whole were able to adapt to these changes. Hardware and software were optimized to deal with video and media. Multi-tasking and threading were improved as multiple CPUs and cores became cheaper and common, even in laptops, tablets and phones. As mobility and power consumption got more important the hardware and software was adapted to take that into account. Security and privacy became more and more important and integrated in the operating systems and file systems.
Apple used Mac OS X as the basis for iPhone OS, porting a Unix system to a phone. There has also been much back and forth of software and technology between the two systems (or three or four). macOS and iOS have evolved, changed and adapted in a way that the classic Mac OS in the 80s and 90s did not.
I am not claiming that macOS in its current form is perfect and cannot or should not be improved. In a few days at WWDC Apple will show us how they plan to further evolve macOS and iOS to adapt further to the future and I am looking forward to it.
When you wonder ‘what is next for the Mac’ you are ignoring that in 2018, the Mac and macOS are not an isolated platform any more.
All my Apple devices talk with each other and exchange data. My Mac shows me which website I am reading on the phone. My phone unlocks my watch and my watch can unlock my Mac. I can create a note on my tablet, add pictures from the phone and finish it on my Mac. I can read messages on my Mac or have them read to me by the phone through my headphones. When I say ‘Hey Siri’ the devices that can hear me decide among themselves which should answer.
macOS and the Mac are now just a part of larger ‘system.’ This system runs on different devices: from my headphones to the iMac on my desk to servers on Apple’s data centers. It includes custom silicone, software, and data stores and relies on communication and local cached data and protocols to communicate locally and all around the world.
The digital hub has grown to the ‘digital net’, where everything is connected and (ideally) everything is available everywhere.
Not all of this works all the time yet. Why the iPhone still cannot pickup a playlist from where I paused it on the Mac is still an absolute mystery to me.
When this new system fails, we get very frustrated, there is no ‘shell’ we can drop down to, to fix a thing. It is often quite impossible to even figure out in which part of this net of devices and services the problem is occuring.
macOS, iOS, iCloud, Siri, HomeKit, Bluetooth and Wifi, Messaging, email, App Stores and third party apps, devices and services like Google, Office 365, 1Password, etc.
Hardware, software and services. All have to work together in the digital net.
When Apple introduced Mac OS X one of the main benefits was that you could easily manage multiple users on one device.
Now, 17 years later, we have multiple devices per user.
I want is the Mac to keep evolving and adapting with my digital net, so I can continue to use its strengths (large screen, CPU/GPU power, storage, high throughput I/O) and supplement its weaknesses (not mobile, few sensors) with the other devices and services. I don’t want the Mac to fall behind or out of the digital net.
I want to stop having to think about whether something I want to do is a “Mac” task or a “phone” task, but whether I’d rather have a keyboard and a large screen or maybe prefer to do it in a chair in the backyard or by talking with Siri, while walking somewhere. Not all those options will work for every task, but I’d like the options to increase. And I want the Mac to be part of that.
I don’t expect a new age for the Mac. I don’t want a new age for the Mac. That would be too small, too myopic, too limiting.
The next age of the Mac is with the digital net and it has already begun.
I am not shy that BBEdit is my favorite text editor. I don’t remember when exactly I got my first copy, but it must have soon after it came out. I have been using it one form or another since then.
It is usually the first application I install on a new Mac. I don’t bother to add the icon to my dock because it is open all the time. (and it doesn’t hog memory)
Recently, someone asked me why I prefer BBEdit. I was caught a bit off-guard but gave my honest answer: habit.
However, this answer doesn’t really do BBEdit much justice. Now I realize it is a habit formed over two-and-a-half decades. When BBEdit came out I was a student and used it for LaTeX documents, shell scripts and Fortran code on my PowerBook 160.
Back then Mac text files preferred a different line break character (carriage return: \r) than Unix (line feed: \n) and Windows (line feed and carriage return: \r\n). BBEdit was able to read, convert and write all of them.
BBEdit transitioned to PowerPC. It was one of the first applications to have a native Mac OS X version (the Mac/Unix text file compatibility was really valuable then). BBEdit made the Intel transition and is ready for the 64-bit only future of macOS.
All along the way, BBEdit has always stayed true to the Mac environment, however the Mac changed. When you expect native ‘Mac-like’ behavior that’s how BBEdit behaves. It supports AppleScript, but also has powerful command line tools. It will parse a binary property list to XML and it will ask for authorization to read and edit root-owned files.
But, BBEdit also has always been a great way to talk with things outside of the Mac.
When I have to edit files over ssh I will grudgingly use nano or (in desperate situations) vi, but then I remember that BBEdit has direct editing over sftp.
BBEdit has supported three version control systems I have used over the years and (so far) survived two.
I have built web pages in BBEdit, trawled through truly gigantic log files, written code in secveral languages, and documents in LaTeX, Markdown and various other file formats. Some of the files were even just plain text.
If you have read anything I have written on this website, or my books, it very likely started out as a draft in BBEdit.
Right now I am writing a book with the experimental Markua language on LeanPub. In BBEdit, of course.
The advantage of text files is that they can be opened everywhere. Trying out a new text editor has virtually no barrier. Over the years I have used and tried out uncountable different editors and many of them had some features I liked. Right now I have Atom and Sublime Text on my Mac, as well. Those are great tools with some wonderful features. However, they are not native to the Mac and that often adds friction to the workflow.
Now that I have thought about it, habit is only part of the answer. It is not just habit, it is a trust they have built and earned over more than two decades.
When Apple does their next transition, I can expect BBEdit to be right there with me, still not sucking. As long as there is still a need to edit text files on Macintosh/Mac OS/Mac OS X/OS X/macOS or whatever it is going to be called, I am looking forward to the next 25 years of working with BBEdit.
I do not have any ads on my webpage or this newsletter. However, if you want to support me and this website, then please consider buying one (or both) of my books. (Imagine it’s like a subscription fee, but you also get one or two useful books on top!)
If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!
While APFS has certainly come with some challenges, mainly for managed FileVault users, it was not the “Macnarök” that we were expecting.
I am not including these links to make fun of the authors – quite the opposite. At the time there was justified anxiety about the future of macOS adminstration and these posts (and many others) put this into words. I believe that because of MacAdmins blogging and presenting about their concerns and anxiety, talking with Apple Reps and filing bugs, as a community, were able to influence the course Apple is taking. It is definitely a slow, frustrating and opaque process, but not entirely fruitless.
However, other new “features” of High Sierra such as UAKEL and, later with 10.13.4, UAMDM provide their own set of hurdles administrators have to clear.
These are the main challenges for macOS deployment:
Imaging is Dead, Long Live the Installer
MDM is Essential
Let’s look at these challenges and some solutions to them in detail.
Imaging is Dead, Long Live the Installer
Imaging has been the means to quickly and reliably install macOS to clients. It could scale from an external drive for a few clients to a NetBoot infrastructure for large deployments.
In the early days imaging meant building a ‘Golden Master’ image with all configuration and software ‘baked in,’ which then would be deployed to all the Macs. Creating this ‘Golden Master’ image was a lot of work and the result quite fragile and error-prone. Macs would usually be kept on a specific version of ‘the image’ for months or a year without updates.
Since the process of manually building the Golden Master was tedious and error-prone, administrators started to automate the process. Tool chains of packages, scripts and other tools could build the master image (or most of it) automatedly.
InstaDMG was one of the first tools to do this. AutoDMG is a direct successor of this approach and still useful for many tasks today.
The same packages and scripts that automated the configuration of the master image could be used to install and update software on ‘live’ Macs. Management tools, like Munki, Casper (now Jamf Pro) and Filewave, can deploy updates to clients automatically without user interaction. As work was moved from preparing the master image to maintaining the live system, the master image became thinner and thinner.
This resulted in the ‘thin imaging’ approach, where the image only had the minimal ‘base OS’ plus enough configuration to connect it to the management system. Once the Mac booted the management system takes over. Imaging would only be used to wipe a Mac and lay down a ‘base image.’
While this approach is slower than monolithic imaging, it is more flexible and allows to keep the system and software on the client continually updated, without having to re-image.
Some workflows even skipped the imaging entirely. When you get a Mac out of the box it already has macOS installed, all you need is to configure it to connect to your management system, which will take care of the rest.
Some administrators had already moved to ‘thin’ imaging or ‘no-imaging’ workflows before High Sierra and pronouncements that ‘Imaging is Dead!’ have been made years ago. Administrators using thin imaging or no-imaging workflows will find they are better prepared for the High Sierra installation workflows.
Mac administrators now have to build new workflows based on the Apple’s supported installation methods for High Sierra. These all rely on the macOS Installer application in one form or another.
The supported means of installing macOS High Sierra are:
the macOS Installer application
a bootable installer on an external drive
the macOS Recovery System
a NetInstall image built with Apple’s System Image Utility
Using the macOS installer application to upgrade a system from 10.12 is straightforward enough and similar to what was possible with the startosinstall command since OS X El Capitan 10.11.
The main challenge are ‘nuke-n pave’ workflows, where the system on a Mac is erased and overwritten with a new system.
This workflow is easy with traditional imaging. In fact, it was easier and faster to just image over a system, rather than upgrade.
The startosinstall --eraseinstall option added in 10.13.4 makes an installer based ‘nuke’n pave’ workflow possible with the macOS Installer application.
In the new High Sierra world of Mac deployment, we face the same challenge: how do you connect an ‘out-of-the-box’ macOS to your management system.
Apple’s answer to that is clearly DEP.
MDM is Essential
DEP will tell a freshly installed Mac which MDM server is ‘responsible’ for it. The MDM server can then use the InstallApplication MDM command to install and configure a management agent, which together with the mdmclient performs the remaining configuration and software installation.
Up until 10.13 Mac administrators could ignore and not use an MDM for Mac deployment and management. There were a few useful features, but there are also many tasks an MDM cannot do or that a local agent can do better.
With High Sierra MDM became essential to manage and support UAKEL. In the early versions of High Sierra, merely being connected to an MDM would disable UAKEL, starting with 10.13.4 UAKEL can be managed with a configuration profile which has to be pushed from a user approved MDM.
Like supervison for iOS devices, UAMDM adds an extra level of approval and provides an additional level of control over the macOS client device. UAMDM will be required for more and more essential functionality going forward.
However, as the name implies, a ‘user approved’ MDM needs to be interactively approved by a user at some time during deployment which creates an enormous challenge for automated workflows.
Apple claims that DEP enrolled devices are automatically user-approved. However, even the DEP enrollment still requires user interaction in the Setup Assistant.
Also DEP is not available in all regions and it may not be possible for organizations to add all existing Macs to their DEP account. DEP also requires Apple DEP servers to be accessible. So during this transition phase and for some other situations, Mac administrators have to have a non-DEP workflow solution to get a UAMDM enrolled device.
Finally the iMac Pro introduces a new system controller with secure boot. By default all external means of booting an iMac Pro are disabled.
NetBoot/NetInstall is not supported on the iMac Pro at all. You can enable booting off external drives, but the process to do so is quite convoluted and cannot be automated. So for administrators, the option is fairly useless.
With the startosinstall command administrators can achieve the necessary management steps from within the local system. You can either upgrade the existing system or ‘nuke’n pave’ with the eraseinstall option.
However, the eraseinstall option is limited to systems that are already on 10.13 with an APFS file system. On the iMac Pro you can safely make that assumption, but for ‘older’ Macs and systems you usually cannot.
So administrators need a second workflow for systems and hardware that cannot run the eraseinstall option (yet).
The Recovery system, external installer volume or NetInstall are the Apple Supported means which can ‘nuke’n pave’ a Mac. NetInstall is the only means that can be automated.
However, there are other solutions such as Imagr or a modified DeployStudio workflow which can achieve the same goal using the macOS Installer application and startosinstall.
The New macOS Deployment Workflow
Deployment strategies and workflows are as varied and individual as the organizations that use them. But with the challenges listed above, I believe we can state a few pieces that are necessary for a new deployment workflow for High Sierra and hopefully going forward.
Enrolling a ‘new’ Mac
First, any deployment workflow should be designed to start with a clean ‘out-of-box’ macOS. This way the same workflow can be applied to new Macs and to Macs that were just re-installed.
At the end of the installation workflow the Mac is enrolled and user-approved with your management system, so that it can take over and perform the remaining configuration and installation. All configuration steps should be controlled from the management system and be executed independently of which deployment workflow was used.
DEP is the Apple-preferred means of connecting a new device to your MDM. Even when you require a non-DEP workflow for older Macs you should implement a DEP workflow. It is likely that Apple may make DEP enrollment mandatory in the future.
However, right now in the transition phase, you will need a second workflow for machines that cannot be registered with DEP.
For the non-DEP workflow, you can choose between manual enrollment, which happens after the user has booted and logged in for first time, or some sort of ‘side-loading’ where you add the MDM and management system configuration to a system, before it even boots for the first time.
For sideloading you can boot to Recovery and install software on the system volume. (Bootstrappr)
On Macs that still support NetBoot, you can also use tools like NetInstall, Imagr or DeployStudio. Either way you should do this before first boot of the system.
UAMDM requires user interaction to approve the management in some form or another. This is a change from previous deployment workflows which could be ‘fully automated.’
You will have to plan for this user interaction. In some cases, such as individual-use devices, the approval of the management will be part of standard first setup and will be done by the end user. In other situations such as classroom setups, it will be harder to make this part of the workflow.
Some management systems let you scope software installations and configurations depending on criteria reported from the device. In this case you can set up your workflow so that installations that rely on UAMDM (third party kernel extensions) are deferred until the MDM is approved.
Either way, the end-result of each of these paths should be a Mac that is enrolled (user-approved) with your MDM where the management system is installing, configuring, maintaining the system and software.
Restoring a Mac to ‘new’
You will also need a second set of workflows that bring a Mac from any state (even a broken one) back to the ‘out-of-box’ state so that you can start over (or retire it).
The first option uses the startosinstall --eraseinstall command. This is easiest to automate and works on new hardware like the iMac Pro. However, it will not work on Macs without APFS systems and older versions of macOS.
The Macs that cannot use the eraseinstall option, however, can use NetInstall or a similar NetBoot based tool. You can use the macOS Install application and startosinstall with Imagr and DeployStudio, so this combination will run the installer and can make sure the firmware is up to date as well.
Note that the workflows and tools for restoring a Mac are also used to ‘sideload’ the agent configuration on to a Mac. You can add the MDM/agent configuration to the restore workflow to save some steps here. However, since NetBoot based workflows are transition solutions to support ‘old’ Macs and systems, your deployment workflows need to work with ‘out-of-box’ systems as well as pre-configured systems.
In the transition phase until all hardware supports eraseinstall you will need both workflows available.
You should also have documentation, training, and support articles to instruct administrators, techs, and users to restore a Mac to ‘out-of-box’ state with (Internet) Recovery or an external boot drive. While this should be an option of last resort, it will be necessary in situations where a Mac cannot boot otherwise.
Obviously, these are very high level views of the workflow and the devil is very much in the details of the implementation. Even a book can only skim the surface of any implementation. Nevertheless, once you understand and accept this framework, the necessary detailed steps become obvious, though not necessarily easy.
I have added two more conferences to the list. X world in Sydney and MacTech in Los Angeles. I put up this list because there were quite a few announcements and schedules published in the last two weeks. I do not plan to make this a permanent section as the MacAdmins Podcast team already has a great list of events nearly every week.