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 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 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 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:
- 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:
- 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.
- 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.
Providing new installs of macOS, or upgrading to newer versions, can be a challenge in many Mac environments. Apple’s OS distribution model is focused around the Mac App Store (MAS), which may not be an option for a number of managed Mac environments. The MAS-distributed OS installer also does not include the option of adding additional third-party packages to the OS installation process; it only installs the software that Apple itself includes in the OS installer.
To address these needs, an open-source tool named createOSXinstallPkg is available. createOSXinstallPkg allows you to create an Apple installer package from an “Install macOS.app”. You can use this package for the following:
- Installing OS X or macOS onto an empty drive
- Upgrading existing OS X or macOS installations to a newer version of the operating system
The advantage of using this tool is that a number of system deployment tools for Macs can deploy the installers created by this tool, allowing OS installations or upgrades to be performed by the system management tool already in use by a particular IT shop. One great thing about using this tool is that createOSXinstallPkg will create an installer package that either installs a stock copy of either OS X or macOS, or you can add additional packages to the stock OS install.
When adding packages, there are a couple of guidelines to keep in mind:
- There is about 350 megabytes of free space available in the OS installer. This is sufficient space for configuration or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers.
- The limitations of the OS install environment mean that there are a number of installers that won’t install correctly.
In particular, packages that use pre-installation or post-installation scripts may fail to run properly when those packages are run as part of the OS installation process. To help work around this limitation, I’ve developed a solution which I’ll be discussing later in the post. For more details, see below the jump.
As previously discussed, a number of folks in my shop use Clarivate Analytics’s EndNote bibliography software. Clarivate Analytics provides EndNote X8 with an installer application, but I need an installer package in order to easily deploy it to my customers. EndNote X8 was initially problematic in that regard, but I was able to write AutoPkg recipes for EndNote X8 to handle converting Clarivate Analytics’s installer application into a deployable installer package, including a recipe that would automate uploading the latest EndNote installers to my Casper server.
Once AutoPkg was able to provide an EndNote X8 installer package for deployment, the remaining hurdle was that the EndNote X8 installer from AutoPkg installs an unlicensed copy of EndNote and I needed to have installed copies of EndNote automatically use my shop’s EndNote site license.
Fortunately, EndNote X8’s volume license can be deployed just like EndNote X7’s volume license. The volume license is stored in as an invisible file named .license.dat in /Applications/EndNote X8 and it has a format that looks like this:
Company Name 1234567890 V2ZMQT6556P8WMH38MTQ6YSM8UXCCRYQ5MDS4WJGLKMP7RGSWECBCMT77556P8WCE8KMTQ6YSMNXJCCRYQ59MD9WJGLKMCSESSWECBCMB76556P8WCU3NMTQ6YSMLUYCCRYQ5MET8WJGLKMPSMJSWECBCM57F556P8WCU3CMTQ6YSM9DECCRYQ59XSCWJGLKMPNE9SWECBCMB79556P8WCH8KMTQ6YSMDXECCRYQ5MTSMWJGLKMPYRMSWECBCB7W7556P8W
Note: The Company Name part may show up twice in your .license.dat file.
With some additional testing, I found that I could remove an existing .license.dat file (if one was present) and replace it with my shop’s site license’s .license.dat file. That allowed me to use the EndNote X8 installer produced by AutoPkg by having Casper install it, then apply our site license file as a post-installation action. For more details, see below the jump.
Recently, EndNote X8 was released. When the new version’s installer was downloaded, it was discovered to be an installer application, which can pose problems for deployment.
By itself, the change to an installer application may not have been a huge problem as long as it had options for running the installation process from the command line. However, when I checked with EndNote support about the new installer, I was told that there was no option for installing EndNote X8 on a Mac using the command line.
Since the EndNote X8 installer does not have the option of command line installation, the only real option I thought I had was to install EndNote X8, then re-package it as either a drag-and-drop install or an installer package. However, when I dug deeper into the installer, I discovered a .zip file buried inside the installer.
When expanded, this .zip file proved to be a complete install of EndNote X8.
When I ran the EndNote X8 installer, it appeared to be performing the following functions:
1. Checking for Endnote updates
2. Extracting the .zip file into a new EndNote X8 folder
3. Moving the new EndNote X8 folder into /Applications
4. Launching the EndNote X8 application, which automatically loads the EndNote X8 Customizer screen if EndNote hasn’t been configured.
For more details, see below the jump.
It’s often useful to provide a way for everyone in your shop to be able to look up commonly used websites. Methods I’ve seen of doing this include:
- Wiki pages
- Bookmarks deployed to browsers
- Browser extensions
Another method is to use Casper’s Self Service plug-ins feature.
This makes it easy to set up website bookmarks, which then appear in a sidebar of Self Service.
The main drawback to this method is you can’t scope these bookmarks to appear only to certain users or computers. These will appear on on all managed computers and to all users. If you need to have one set of bookmarks available to Group A in your organization, and a different set of bookmarks appearing to Group B, the Self Service plug-ins feature may not be the best solution.
Fortunately, you can solve this scoping issue using Casper policies and Self Service. For more details, see below the jump.
Recently, I was alerted by Todd Houle that his infosec folks had identified an vulnerability with CasperCheck that should be addressed.
CasperCheck downloads a QuickAdd installer from a web server inside a .zip file and initially stores it in the /tmp directory. All users on the system have access to /tmp, so it was possible for an malicious unprivileged user to leverage a race condition to replace the downloaded .zip file with another .zip file with the same name.
Assuming that the replaced .zip file was valid and passed the check for being a valid .zip file, CasperCheck would then expand the contents of the replaced .zip file into the /var/root/quickadd directory. Assuming that the malicious unprivileged user had their own installer package stored inside the replaced .zip file, the next time that CasperCheck would determine that it needs to install the Casper agent via its cached QuickAdd installer, it would instead install that installer package in place of the expected QuickAdd package.
The vulnerability assumes that the QuickAdd package is being downloaded to a place where an unprivileged user can access it, so the implemented fix to this problem is to download it to a place where only root has access. Todd fixed the issue by changing the designated download location to the following:
To: $quickadd_dir/quickadd.zip, where the value of $quickadd_dir is /var/root/quickadd
Moving the download location to /var/root/quickadd means that the download is going to a location inside the root account’s home directory. Only root has write access to its home directory, which stops an account which doesn’t have root privileges from being able to swap out the .zip file.
Changes to CasperCheck:
Fortunately, the changes needed to implement this fix are minor and are in two places:
The quickadd_zip variable has changed:
To: $quickadd_dir/quickadd.zip, where the value of $quickadd_dir is /var/root/quickadd
The update_quickadd function has been updated, to move the following actions to be first:
- The creation of the /var/root/quickadd directory, if that directory is not already present
- The removal of existing files from the /var/root/quickadd directory
I’ve posted an updated CasperCheck script with the described changes to the following location:
If you’re a CasperCheck user, I recommend updating to the latest version at your earliest convenience.
The changes to the script can be seen here:
Hat tip: Thanks to Todd to alerting me to this issue and providing help to fix it.
Recently, one of my customers had a problem with the font he needed not showing up in all applications. In this particular case, he wanted to use the Symbol font as part of a Keynote presentation he was preparing but it did not appear in Keynote’s font list.
Meanwhile, the Symbol font did appear in PowerPoint 2016’s font list.
Meanwhile, it was possible to copy and paste text using that font from PowerPoint and into Keynote, but then the font list in Keynote showed a blank entry in place of the name of the font.
What was going on? For more details, see below the jump.