Scripting OS X — Weekly News Summary for Admins — 2020-12-11

You might think that things are starting to quiet down as the holidays are approaching. But we got a “last minute before christmas” announcement from Apple: new over-ear headphones called AirPods Max.

Hidden in the announcement, you can see that the new AirPods Max require iOS 14.3 (and siblings) or macOS Big Sur 11.1. Sure enough, a few hours later iOS 14.3 Release Candidate (and siblings) was released to the beta channels, followed yesterday by macOS Big Sur 11.1 Release Candidate. The headphones will start shipping next week, so we can expect the updates to be released next week as well.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

macOS 11 Big Sur and Apple silicon Macs

MacAdmins on Twitter

  • Carl Ashley: “I don’t know if other macadmins knew this, but in macOS Big Sur, you can enable the SecureToken for an MDM created admin account by changing the password for that account as long as no other account has logged in first. It works in pre/postinstall scripts in packages too.”
  • Eric Holtam: “Password change isn’t even necessary. Any auth works. I use dscl . -authonly [username] [password] very early on to enable the ST on an admin account to escrow the BootstrapToken.”
  • Jason Meller: “I’ve been deeply disappointed by the state of endpoint security & mgmt. The industry has chosen a path where end-users are considered obstacles and their privacy is irrelevant. Today, Kolide is publishing a different vision. It’s called honestsecurity.” (Thread, Link)
  • Tim Perfitt: “That was easy. Signing Manager is totally made for EC2 Mac instances. Took about 2 minutes to set up. No private keys in the cloud. Used codesign to sign an app using our CTK extension connected to a remote API for signing operations.” (Thread, Image)

Bugs and Security

Support and HowTos

Scripting and Automation

Apple Support

Updates and Releases

To Listen

Just for Fun

Support

If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!

If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!

Update: desktoppr v0.4

I have posted an update for desktoppr. You can download it from the repository’s releases page.

This update adds no features. It does provide support for the Apple silicon Macs with a Univeral binary and installer pkg.

In my initial testing desktoppr v0.3 worked fine on Apple Silicon Macs even without re-compiling, so I didn’t feel pressure to build and provide a universal binary.

However, since then I have learned that the package installation might trigger Rosetta installation and fail if there is no UI at that point. Also, managing the Desktop picture might happen very early in your deployment workflow, so Rosetta might not be available at that time yet.

Either way, having a universal binary and a properly configured installer pkg will be helpful in either case. If you have to support Apple silicon Macs, be sure to use desktoppr v0.4.

Platform Support in macOS Installer Packages (pkg)

Mac users and admins find themselves in yet another major platform transistion. For the duration of the transition, developers and admins will have to deal with and support software and hardware for the Intel and Apple silicon Macs. With Universal applications and Rosetta 2, Apple is providing very efficient tools to dramatically reduce the friction and problems involved.

This post was inspired by comments from Josh Wisenbaker on MacAdmins Slack and Twitter. Thank you!

For most end user level tasks, these tools will provide seamless experience. Universal applications will run on either platform natively and Rosetta 2 will translate applications compiled for the legacy platform (Intel) so they can run on the new Apple silicon chips. There are only a few situations where these tools don’t work: virtualization solutions and Kernel extensions.

In most cases this tools will “just work.” But for MacAdmins there is one major issue that may throw a wrench in your well-oiled deployment workflows. Rosetta is not pre-installed on a fresh macOS installation.

We can only speculate why Apple chooses to deliver Rosetta this way. In “normal” unmanaged installations, this is not a big deal. The first time a user installs or launches a solution that requires Rosetta, they will be prompted to for installation and upon approval, the system will download and install Rosetta.

As a MacAdmin, however, you want your deployments to be uninterrupted by such dialogs. Not only are they confusing to end users, but the user might cancel out of them which will result in your workflow failing partially.

There are two solutions. The first is to install Rosetta as early as possible in the deployment process. Apple provides a new option for the softwareupdate command to initiate the installation. Graham Gilbert and Rich Trouton have already published scripts around this. Have this script run early in your deployment workflow on Apple silicon and subsequent apps and tools that require Rosetta should be fine.

The other solution is to avoid requiring Rosetta and thus the prompt for Rosetta.

I mentioned earlier that we can only speculate as to why Apple has made Rosetta 2 an optional installation. One possible explanation is, that Apple believes Rosetta will not be a necessary installation for very long. An extra dialog and installation will make users and developers more aware of software that “needs an update” and motivate developers to provide Universal applications faster.

When a user opens an application that requires Rosetta for the first time, before Rosetta is installed, the system prompts to install. The same thing can happen with an installer package. The system might prompt to install Rosetta before a certain package is installed. However, not all packages trigger the dialog. I was curious what is required in the package to trigger or to avoid the prompt.

Aside from legacy formats, there are two types of packages. The first are “plain” packages, which are also called component packages. These packages have a payload and can have pre- and postinstall scripts, but other than that, there is little metadata you can add to influence the installation workflow.

This is where “distribution packages” come in. Distribution packages do not have a payload or installation scripts of their own, but contain one or more component packages. In addition, distribution packages can contain metadata that influences the installation workflow, such as customization of the Installer.app interface, system version checks, prompting the user to quit running applications before an installation and software requirements and a few more.

Note: learn more about the detailed differences between component and distribution packages in my book: “Packaging for Apple Administrators“

You can build a distribution package from a component package with the productbuild command:

> productbuild --package component.pkg distribution.pkg

Since most of the extra features of distribution packages are only effective when the installation package is launched manually in the Installer application, MacAdmins usually just build component pkgs.

The confusing part here is that both component pkgs and distribution pkgs have the same file extension. They are hard to distinguish even from the command line. To tell them apart, you can expand a pkg with the pkgutil command and look at the files in the expanded folder. Component pkgs have (among other files) a PackageInfo file and distribution pkgs have a Distribution file:

# component pkg
> pkgutil --expand component.pkg expanded_component_pkg
> ls expanded_component_pkg
Bom
Payload
Scripts
PackageInfo

# distribution pkg
> pkgutil --expand distribution.pkg expanded_distribution_pkg
> ls expanded_distribution_pkg
component.pkg
Distribution

For distribution pkgs, the Distribution file is an XML file which contains the configuration data for the package. One tag in this XML is the options tag which can have a hostArchitectures attribute. According to [Apple’s documentation on this tag](A comma-separated list of supported architecture codes), the hostArchitectures are a “comma-separated list of supported architecture codes.”

Apple documentation is a bit aged, so it gives i386, x86_64, and ppc as possible values. However, when you read the productbuild man page on macOS Big Sur you will see that arm64 is a new valid value. We will also find these extremely helpful note:

NOTE: On Apple Silicon, the macOS Installer will evaluate the product’s distribution under Rosetta 2 unless the arch key includes the arm64 architecture specifier. Some distribution properties may be evaluated differently between Rosetta 2 and native execution, such as the predicate specified by the sysctl-requirements key. If the distribution is evaluated under Rosetta 2, any package scripts inside of product will be executed with Rosetta 2 at install time.

When a distribution pkg has this attribute and it contains a value of arm64 then the installation process on an Apple silicon Mac will not check if Rosetta is installed. When arm64 is missing from the hostArchitectures, or the attribute or tag are missing entirely, the installation process on an Apple silicon Mac will asume the pkg requires Rosetta and prompt to install when necessary.

There is more good news in the next note in the man page:

NOTE: Starting on macOS 11.0 (Big Sur), productbuild will automatically specify support for both arm64 and x86_64 unless a custom value for arch is provided.

When you use productbuild to create a distribution pkg on Big Sur (Intel and Apple silicon) both arm64 and x86_64 will be added to the configuration by default.

But, when you use productbuild on Catalina or earlier, the attribute will be lacking, when means that when someone installs that pkg on an Apple silicon Mac, it will assume it requires Rosetta and prompt for installation.

Adding both architectures by default is a useful default. But can we set the value explicitly when we build the distribution pkg? And can we do so on Catalina?

Yes, you can, of course. There are even two solutions. First, instead of letting productbuild generate the Distribution xml, you can build and provide a complete Distribution xml file with the --distribution option. That will give you full, fine-grained control over all the options.

The second solution is a bit easier. You can create a requirements.plist property plist file in the form:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>arch</key>
        <array>
                <string>x86_64</string>
                <string>arm64</string>
        </array>
</dict>
</plist>

Then you can provide this property list file to the productbuild command with the --product option.

> productbuild --package component.pkg --product requirements.plist distribution.pkg

This way, productbuild still generates the Distribution xml and merges in your choices from the requirements.plst. There are other options you can add which are documented in the productbuild man page.

Both of these approaches will work on Catalina as well. This way you can explicitly tell the installer system which architectures your packages will run with and not leave anything to chance.

In Whitebox Packages you can configure the hostArchitectures attribute under the “advanced options” for a distribution package.

As far as I can tell, when you install a component pkg, no checks for Rosetta are performed. Nevertheless, this is not something I would rely on. For packages that are crucial to the deployment workflow, I would recommend going the extra step and creating a distribution pkg from the component pkg with the proper flags set. This way you can ensure proper behavior.

Of course, if your package installer contains any form of Intel-only, not-universal binary, you should not abuse this just to skip the annoying Rosetta dialog, as it might lead to problems later. But, when the software you are installing is universal, you sould use this to tell the system which platforms your package supports.

Weekly News Summary for Admins — 2020-12-04

Many interesting posts this week that go in depth on Big Sur and Apple silicon topics.

We also got an announcement that you can new “rent” an Apple Mac mini from Amazon EC2. While this seems to be a fairly expensive choice, it should enable some really interesting solutions. When you need a less expensive solution for this, remember there is MacStadium.

We also got new betas for iOS 14.3 (and siblings) as well as macOS 11.1.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

News and Opinion

Apple Silicon M1 Macs

macOS 11 Big Sur

macOS and iOS Updates

MacAdmins on Twitter

  • Tim Perfitt: “So I have two 2020 MacBooks Airs, one intel and one M1. Trying to find a consistent way to install Big Sur on them. it has proven to be surprisingly difficult for both of them for different reasons.”
  • Jason Broccardo: “Pro Tip: If Do Not Disturb is enabled on Big Sur, the Menu Bar clock is dimmed. If you’d rather not drive yourself nuts trying to figure out why the clock is dimmed, turn off DND”
  • Wil Shipley: “Dear Apple security team: Please explain what we should tell our customers when they want to revert to a Time Machine backup for a sandboxed shoebox app.” (Thread)

Bugs and Security

Support and HowTos

Scripting and Automation

Apple Support

Updates and Releases

To Watch

To Listen

Support

If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!

If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!

Scripting OS X — Weekly News Summary for Admins — 2020-11-27

Much quieter week after the last two newsletters were loaded with many posts on Big Sur and the Apple silicon Macs. This week is Thanksgiving week in the US and many companies, including Apple, close offices for this holiday.

So, whether you are currently in a food-induced stupor, getting ready for some Black Friday shopping, or you are merely enjoying the peace and quiet because the Americans are distracted for a few days: Happy Thanksgiving!

At Thanksgving, it is traditional to state what you are grateful for. I am very grateful for all the readers. And also, for all the people who share their knowledge and experiences in posts and articles, so that I have intersting links to share!

Thank you, all! Stay Safe.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

On Scripting OS X

News and Opinion

Apple Silicon M1 Macs

macOS 11 Big Sur and iOS 14

MacAdmins on Twitter

  • Hannes Juutilainen: “When you don’t know if you should write your log file into /Library/Logs or /var/log, you should definitely create a third dir and call it /var/logs“
  • William Smith:
    “Today, JamfSoftware releases Jamf Pro 10.26. My favorite new feature is a revamped Application & Custom Settings payload for macOS Configuration Profiles. It now supports editable plists within the GUI! And it makes uploaded plists editable too.”

Bugs and Security

Support and HowTos

Scripting and Automation

Apple Support

Updates and Releases

To Listen

Support

If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!

If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!

Ten Years of Scripting OS X

The oldest post on this weblog happened ten years ago. It makes me especially proud, that the first post has aged quite well. (The second post, not so much.)

This weblog was (quite obviously) inspired by the weblogs of Greg Neagle, Rich Trouton, Ben Toms, and many others. I wanted to share and give back to the MacAdmins community. I have always enjoyed scripting, in the sense of tinkering and combining tools in useful, or sometimes just funny ways and sharing that seemed like an obvious thing to do.

I wasn’t really planning on honing my writing skills for writing books later. As many of these personal weblogs go, I posted quite irregularly for the first few years. Still, I was often quite excited when a post got dozens of views.

As it turns out, a weblog is also a decent marketing platform for a self-published book (or two, or three, or four). When you are writing a book, there are always a few things that don’t quite “fit in” and that then get turned into a blog post. Once I got into the habit of posting regularly, the viewer numbers and the books sales increased. At some point, my ranking in the weird black magic that is the Google algorithm reached some critical point and the views from searches started pouring in.

Having posts being read and re-shared does give you a bit of a thrill. And I wanted to share that feeling. I started the weekly news summary to have a place where all the great work of fellow MacAdmins (and related experts) is gathered. I got requests to have an email newsletter fairly quickly. We passed 1000 subscribers on the email newsletter in October, and many more read it on the website.

Last week, according to the Jetpack metrics, this site had its millionth unique visitor overall and its 500.000th unique visitor in this calendar year. Yes, that means traffic is more than doubling year over year.

Back when a post would get hundreds of views that was exciting. The traffic now is still exciting, but also a bit humbling. So, thank you all for being here and reading and sharing my posts and books.

There was never a big strategy or plan. But I am very happy how everything worked out. Over the years, writing for the weblog gave me confidence to write and self-publish a book. The books and posts lead to conference presentations, which lead to more posts and books and the newsletter. And the best part is: I got to meet and befriend some pretty great people from all over the world.

And true to the spirit of how the last ten years turned out, I have no plans or strategies for major changes in the near future. I will keep the things that work and try new things as they occur to me. That doesn’t mean that there won’t be a few minor changes happening soon, though.

On to the next ten years!

Weekly News Summary for Admins — 2020-11-20

This summary isn’t quite as big as last week’s, but very close.

This week many people got their hands on the first Macs with Apple silicon M1 chips. The reviews and benchmarks are in and it looks as if Apple wasn’t over promising. Many software vendors are shipping updates for Big Sur and Universal app support. This is definitely an interesting and busy time.

Whether your organisation can dive head-first into Big Sur and Apple silicon deployment or you have to (or want to) hold back for a while, there will be articles in here to help you.

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

💻Apple Silicon M1 Macs

🌅macOS 11 Big Sur

⚙️macOS and iOS Updates

🐦MacAdmins on Twitter

  • Laura Rösler: “Every fifth Mac is on Big Sur. After 5 days (including initial crash of Apple services, weekend and issues with macOS 11 Internet Recovery) we’re up to more than 5800 Macs with macOS 11.”
  • macshome: “Remember that if you don’t have installer packages that declare arm64 support then the Installer will trigger the Rosetta 2 install as well. Even if the contents are universal.”
  • Rich Trouton: “Need the model numbers for the new Apple Silicon Macs? Mac Mini: Macmini9,1 MacBook Pro: MacBookPro17,1 MacBook Air: MacBookAir10,1 Developer Transition Kit: ADP3,2”
  • Nathaniel Strauss: “‘If upgrading from macOS Sierra or later, macOS Big Sur requires 35.5GB of available storage to upgrade. If upgrading from an earlier release, macOS Big Sur requires up to 44.5GB of available storage.’ Nearly 1/3 of a 120 GB SSD. “

🐞Bugs and Security

🔨Support and HowTos

🍏Apple Support

♻️Updates and Releases

🎧To Listen

🎈Just for Fun

📚 Support

If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!

If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!

Deploying the Big Sur Installer Application

When you want to provide automated workflows to upgrade to or erase-install macOS Big Sur, you can use the startosinstall tool. You can find this tool inside the “Install macOS Big Sur” application at:

/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall

Note: Apple calls the “Install macOS *” application “InstallAssistant.” I find this a useful shorthand and will use it.

Before you can use startosinstall, you need to somehow deploy the InstallAssitant on the client system. And since the “Install macOS Big Sur” application is huge (>12GB) it poses its own set of challenges.

Different management systems have different means of deploying software. If you are using Munki (or one of the management systems that has integrated Munki, like SimpleMDM or Workspace One) you can wrap the application in a dmg. Unfortunately, even though “app in a dmg” has been a means of distributing software on macOS for nearly 20 years, most management systems cannot deal with this and expect an installer package (pkg).

You can use pkgbuild to build an installer package from an application, like this:

pkgbuild --component "/Applications/Install macOS Catalina.app" InstallCatalina-10.15.7.pkg

This works for all InstallAssistants up to and including Catalina. With a Big Sur installer application this command will start working, but then fail:

% pkgbuild --component "/Applications/Install macOS Big Sur.app/" InstallBigSur20B29.pkg
pkgbuild: Adding component at /Applications/Install macOS Big Sur.app/
pkgbuild: Inferred install-location of /Applications
pkgbuild: error: Cannot write package to "InstallBigSur20B29.pkg". (The operation couldn’t be completed. File too large)

The reason for this failure is that the Big Sur installer application contains a single file Contents/SharedSupport/SharedSupport.dmg which is larger than 8GB. While a pkg file can be larger than 8GB, there are limitations in the installer package format which preclude individual files in the pkg payload to be larger than that.

When you want to distribute the “Install macOS Big Sur” application to the clients in your fleet, either to upgrade or for an erase-and-install workflow, this limitation introduces some challenges.

You can use Composer with Jamf to create a Jamf dmg style deployment, but that will only work with Jamf Pro. You could further wrap and split the application in different containers, but that will increase the creation and deployment time.

There are a number of solutions. Each with their own advantages and downsides, some supported and recommended by Apple and some… less so. Different management and deployment styles will require different solutions and approaches.

App Deployment with MDM/VPP

When you have your MDM hooked up to Apple Business Manager or Apple School Manager, you can push applications “purchased” in the “Apps and Books” area with MDM commands. This was formerly known as “VPP” (Volume Purchase Program and I will continue to use that name, because “deploy with Apps and Books from Apple Business Manager or Apple School Manager” is just unwieldly and I don’t care what Apple Marketing wants us to call it.

Since the “Install macOS Big Sur” application is available for free on the Mac App Store, you can use VPP to push it to a client from your MDM/management system.

When you do this, the client will not get the full InstallAssistant application, but a ‘stub’ InstallAssistant. This stub is small in size (20-40MB).

The additional resouces required for the actual system upgrade or installation which are GigaBytes worth of data will be loaded when they are needed. It doesn’t matter whether the process is triggered by the user after opeing the application or by using the startosinstall or createinstallmedia tool. Either workflow will trigger the download of the additional resources.

This has the advantage of being a fast initial installation of the InstallAssistant, but then the actual upgrade or re-installation process will take so much longer, because of the large extra download before the actual installation can even begin. For certain deployment workflows, this is an acceptable or maybe even desireable trade-off.

The extra download will use a Caching Server. This approach is recommended and supported by Apple.

Mac App Store and/or System Preferences

For some user-driven deployment styles, having the user download the InstallAssistant themselves can be part of the workflow. This way, the user can control the timing of the large download and make sure they are on a “good” network and the download will not interfere with video conferences or other work.

You can direct then to the Big Sur entry in the Mac App Store with a link. You cannot search for older versions of macOS Installers in the Mac App Store, but Apple has a kbase article with direct links.

You can also use a link that leads a user directly to the Software Update pane in System Preferences and prompts the user to start the download:

# Big Sur
x-apple.systempreferences:com.apple.preferences.softwareupdate?client=bau&installMajorOSBundle=com.apple.InstallAssistant.macOSBigSur

# Catalina
x-apple.systempreferences:com.apple.preferences.softwareupdate?client=bau&installMajorOSBundle=com.apple.InstallAssistant.Catalina

When the InstallAssistant is already installed, this link will open the application. When the Mac is already running a newer version of macOS or doesn’t support the version given, it will display an error.

You can use these links from a script with the open command:

open 'x-apple.systempreferences:com.apple.preferences.softwareupdate?client=bau&installMajorOSBundle=com.apple.InstallAssistant.macOSBigSur'

The downloads initiated this way will use a Caching Server. Linking to the Mac App Store is supported and recommended by Apple. The x-apple.systempreferences links are undocumented.

softwareupdate command

Catalina introduced the --fetch-full-installer option for the softwareupdate command. You can add the --full-installer-version option to get a specific version of the installer, for example 10.15.7.

You can run this command from a managed script on the clients to install the application. The download will use a Caching Server.

This would be a really useful method to automate deployment the InstallAssistant on a client, if it were reliable. However, in my experience and that of many MacAdmins, this command is very fragile and will fail in many circumstances. As of this writing, I have not been able to reliably download a Big Sur InstallAssistant with this command. Most of the time I get

Install failed with error: Update not found

This approach is often recommended by Apple employees, however it will have to be much more reliable before I will join their recommendation.

Please, use Feedback Assistant, preferably with an AppleSeed for IT account, to communicate your experience with this tool with Apple. If this command were reliable, then it would be my recommended solution for nearly all kinds of deployments.

InstallAssistant pkg

With these solutions so far, we have actually avoided creating an installer package, because we moved the download of the InstallAssistant to the client. A caching server can help with the network load. Nevertheless for some styles of deployments, like schools and universities, using the local management infrastucture (like repositories or distribution points) has great advantages. For this, we need a package installer for the InstallAssistant.

A “magic” download link has been shared frequently in the MacAdmins Slack that downloads an installation package from an Apple URL which installs the Big Sur InstallAssistant.

This pkg from Apple avoids the file size limit for the package payload by not having the big file in the payload and then moving it in the postinstall script. Smart hack.. er… solution!

The URL is a download link from a software update catalog. You can easily find the link for the current version with the SUS Inspector tool.

But it would be really tedious to do this on every update. You, the regular reader, know the “tedious” is a trigger word for me to write a script. In this case it was less writing a script than looting one. Greg Neagle’s installinstallmacos.py had most of the pieces needed to find the InstallAssistant.pkg in the software update catalog and download it. I merely had to put the pieces together somewhat differently.

Nevertheless, I “made” a script that downloads the latest InstallAssistant.pkg for macOS Big Sur. You can then upload this pkg to your management system and distribute it like any other installation package.

It works very much like installinstallmacos.py.

./fetch-installer-pkg.py

When you start the script it will download a lot of data into a content folder in the current working directory, parse through it and determine the Big Sur Installers in the catalog. When it finds more than one installers, it will list them and you can choose one. When it finds only one Installer, it will start downloading that immediately.

You can add the --help option for some extra options (all inherited from installinstallmacos.py.

We will have to wait for the 11.1 release to be sure this actually works as expected, but I am confident we can make it work.

This approach is very likely not supported by Apple. But neither was re-packaging the InstallAssitant from disk in Catalina. This deployment method is likely closer to the supported deployment workflows than some common existing methods.

The download does not use a Caching Server, but since the goal is to obtain a pkg that you can upload to your management server, this is not a big downside.

Big Sur signature verification check

You may have noticed that when you launch the Big Sur InstallAssistant on Big Sur for the first time, it will take a long time to “think” before it actually launches. This is due to a new security feature in Big Sur that verifies the application signature and integrity on first launch. Since this is a “big” application this check takes a while. Unfortunately Big Sur shows no progress bar or other indication. This check occurs when the user double-clicks the app to open it and when you start an upgrade or installation with the startosinstall command.

There does not seem to be a way to skip or bypass this check. You can run startosinstall --usage from a script right after installing the InstallAssistant. This will do nothing really, but force the check to happen. Subsequent launches, either from Finder or with startosinstall will be immediate.

Weekly News Summary for Admins — 2020-11-13

Usually, I gather 30-40 links a week, which I then curate into this newsletter. This week I had more than a hundred links to work through, and discovered a few more posts and articles while I put everything together. What a week!

Macs with M1

New Macs with Apple Silicon M1 chips were introduced at the “One more thing” event on Tuesday. The MacBook Air, two-port MacBook Pro 13″ and the Mac mini are now available to order with the Apple Silicon M1 chip.

While the performance numbers look really exciting, there are a few interesting caveats, mostly with regards to external displays.All Macs with the M1 chip could drive a 6K display, the MacBooks can only drive a single external display and the Mac mini can only connect two external displays (a 6K and a 4K). External GPUs are not supported. (yet?)

The four port 13″ MacBook Pro and the 16″ MacBook Pro are still availble with Intel chips, as well as a Mac mini Intel configuration, which can have more RAM than the M1 Mac mini and optional 10Gig ethernet.

The M1 Macs cap out at 16GB RAM. This is a concern for many technical minded people. However, I would remind that the iPad Pro seems to fine with even less RAM, and that the fast SSD storage used in Macs these days make the penalty for paging to “disk” much less painful than it used to be.

Big Sur

And then we got Big Sur. Apple published macOS Big Sur 11.0.1 yesterday. And then a weird thing happened. We can only guess details, but it seems that the massive 12GB download overwhelmed Apple’s distribution network, but also took down other parts of Apple’s server network. (Then again, cause end effect might be the other way around. We don’t know.) One of the servers that was not reachable for a while was the OCSP server which macOS uses to verify the developer signatures of applications. Because of this app launches were slow on Macs everywhere. Issues were resolved within a few hours.

I would just love to be a fly on the wall in this post-mortem meeting at Apple. The chain of events that must have happened to cause this must be very strange, indeed.

Nevertheless, we got Big Sur.. eventually. And with Big Sur come lots of reviews, app updates (some universal), support articles, blog post.

Enjoy this “extra big” Big Sur edition of the news!

(If I missed something, please let me know. I will add it next week!)

If you would rather get the weekly newsletter by email, you can subscribe to the Scripting OS X Weekly Newsletter here!! (Same content, delivered to your Inbox once a week.)

#! On Scripting OS X

📰News and Opinion

💻Apple Silicon M1 Macs

🌅 macOS 11 Big Sur and iOS 14

👩‍💻MacAdmins and Users on Big Sur

MDM vendors on Big Sur

Apple on Big Sur

Apple Developer

What’s new for Enterprise

⚙️macOS Catalina 10.15 and iOS 14 Updates

🐦MacAdmins on Twitter

  • Thomas Reed: “Scam sites that call just about everything a “virus,” and that promote junk apps to “remove” the “virus,” have become a plague. Consider macsecurity dot net, which scares people with things like a “DuckDuckGo virus” as a means for promoting ComboCleaner.” (Thread)
  • Camille Fournier: “Screw “choose boring technology,” today’s mantra is “make boring plans.” AKA, if you can break a problem down well enough that the plans look to an outsider like they are mostly boring and rote, you are probably a damn fine platform engineer.”
  • Bombich Software: “Apple fixed some of the APFS replication issues in the Big Sur 11.0.1 update, and CCC 5.1.23-b1 includes support for making bootable backups on Big Sur. To participate in this beta cycle, go to CCC’s Preferences > Software Update and check the box to be informed of beta releases.”
  • Panic: “Transmit 5.7 is ALSO now Apple silicon native on Mac, which is kind of a beautiful thing: this means that our little truck has run natively on every single Mac architecture in history, from 68k, to PPC, to Intel, now to M1. It just keeps on going!”
  • Longhorn: “So… I heard a lot of people asking: “can you run Windows on Apple M1 Macs?”( Thread)
  • Victor: “You thought kernel extensions on Apple Silicone were dead, but you were wrong.”
  • Adam C. Engst: “Apple has apparently resolved the problem with the certificate revocation server that was timing out and causing apps to open very slowly. Make sure to remove the workaround line from /etc/hosts if you added it!”
  • Carl Ashley: “Real talk @Apple @AppleSupport – the mechanisms available to #macadmins to withold OS updates and new OS releases is absolutely awful. We absolutely need the flexibility of being able to permanently block releases.”
  • Jeff Johnson: “Don’t confuse Developer ID certificate status (/usr/libexec/trustd to ocsp . apple . com) with notarization (/usr/libexec/syspolicyd to api . apple-cloudkit . com). Notarization check only occurs on first launch. Online Certificate Status Protocol can occur on any launch.” (Thread)
  • Keir Thomas: “Nice little Big Sur tweak for Disk Utility. When you click to use First Aid on a disk – which typically locks-up the Mac for a few seconds – it takes away the desktop and your apps temporarily so you CAN’T do anything.”

🐞Bugs and Security

🔨Support and HowTos

– Wrangling file paths in Catalina and Big Sur – Howard Oakley

🤖Scripting and Automation

🍏Apple Support

♻️Updates and Releases

📺To Watch

🎧To Listen

📚 Support

If you are enjoying what you are reading here, please spread the word and recommend it to another Mac Admin!

If you want to support me and this website even further, then consider buying one (or all) of my books. It’s like a subscription fee, but you also get a useful book or two extra!

Book Update for Big Sur – Moving to zsh v4

I have pushed an update for the “Moving to zsh” book.

Big Sur is such an important update that gave it the long-awaited version number ’11.’ Thankfully, it did not bring many changes to the way the Terminal and zsh work.

zsh is still the (new) default shell for new users. bash v3 is (so far) still present on macOS Big Sur, but when you use it as your shell, you will get the warning to switch in Terminal. While Big Sur updates zsh to version 5.8 this doesn’t change any major behavior compared to zsh 5.7.1 in zsh.

Because of all this, I only had to do a few minor updates to the book.

I do anticipate that many user who have been holding off from upgrading to Catalina (or older versions of macOS), will now either upgrade to Catalina or leap frog directly to Big Sur. For those users, this book is ready to help them “Move to zsh.” Please, recommend this book when you encounter one of these users.

As usual, the update is free if you have already purchased the book. You should get a notification from the Books application to update. (On macOS, I have seen that it can help to delete the local download of the book to force the update. It might still take a few hours for the change to propagate through Apple’s server network. Even when you get the older version now, you can re-download the update when it is available.)

When you haven’t gotten the book yet, you can purchase it on the Apple Books store.

If you are enjoying the book, please rate it on the Books store, or even leave a review. These really help, thank you!

The changes are listed here. This list is also in the ‘Version History’ section in the book. There, you will get links to the relevant section of the book, so you can find the changes quickly.

  • Description of the new zsh session restore feature in Big Sur Terminal
  • Updated some images and text with macOS Big Sur information
  • Added a link to a post with instructions to install shellcheck on macOS