Not yet ready for macOS Catalina in your environment, but you’ve trained your folks to look at the Software Update preference pane to see if there’s available updates? One of the ways Apple is advertising the macOS Catalina upgrade is via the Software Update preference pane in System Preferences:

If you want to prevent that advertising banner from appearing, run the following command with root privileges:

softwareupdate --ignore "macOS Catalina"

You should see text appear which looks like this:

Ignored updates:
(
    "macOS Catalina"
)

The advertisement banner from the Software Update preference pane should now be removed.

A while back, I wrote a post on enabling automatic software updates on OS X Yosemite through macOS Mojave. As part of the post, I mentioned that it wasn’t possible to manage the options for automatic macOS and App Store updates using a profile. The reasons were the following:

• The App Store update options were managed by the com.apple.commerce preference domain, which isn’t manageable with a profile
• The AutomaticallyInstallMacOSUpdates setting in the com.apple.SoftwareUpdate preference domain should be manageable with a profile, but for unknown reasons, it couldn’t be.

As of macOS Catalina, I’m happy to say that this has changed. For more details, please see below the jump.

The changes are the following:

• The AutomaticallyInstallMacOSUpdates setting in the com.apple.SoftwareUpdate preference domain is now manageable with a profile.
• A new AutomaticallyInstallAppUpdates setting has been added to the com.apple.SoftwareUpdate preference domain and it is manageable with a profile.

With this in mind, the following profile can be installed on macOS Catalina to enable the following options:

• Automatic background check for macOS software updates
• Automatic download of macOS software updates
• Automatic download and installation of XProtect, MRT and Gatekeeper updates
• Automatic download and installation of automatic security updates
• Automatic installation of macOS updates
• Automatic installation of App Store updates

A sample profile is available below and also on GitHub at the following address:

https://github.com/rtrouton/profiles/tree/master/EnableAutomaticDownloadandInstallationofAppleSoftwareUpdates

Starting with Mac OS X 10.0.0, Mac apps have traditionally been installed into /Applications or /Applications/Utilities. It appears to be the same on macOS Catalina, but appearances can be deceiving.

As part of implementing a read-only volume for the OS, Apple has moved the apps it installs along with the OS from /Applications to a new location on the read-only volume: /System/Applications

For operations in the Finder, this move won’t make a lot of difference because Apple has made sure that the applications in question still appear in /Applications and /Applications/Utilities.

However, if a script or other command line tool is referencing an app in /Applications or /Applications/Utilities, the new /System/Applications and /System/Applications/Utilities path must be referenced. In my case, I ran across this as part of a script that as part of its work was referencing the Keychain Access app in the following location:

/Applications/Utilities/Keychain Access.app

The script failed because Keychain Access is no longer available at that location on macOS Catalina. To fix this, I updated the script to use the following location:

/System/Applications/Utilities/Keychain Access.app

Once that was done, the script ran without problems again.

This new location on the read-only volume only applies to apps which Apple installs as part of the OS or which are only updated by OS updates. For example, because Safari may be installed or updated separately, the Safari app is not located on the read-only volume in /System/Applications. Instead, Safari remains in /Applications as /Applications/Safari.app.

On certain occasions, it may be necessary to configure settings on a Mac which has not yet gone through Apple’s Setup Assistant. This process usually involves enabling the root account and setting a password for it, since no user accounts with admin rights exist yet. For more details on how to do this on macOS Catalina, please see below the jump.

To enable the root account and set a password for it, use the procedure described below:

1. Start up the Mac into single-user mode.
2. Mount the boot drive’s writable volume using the following command:

/sbin/mount -uw /System/Volumes/Data

3. Launch the opendirectoryd process using the following command:

launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist

4. Enable the root account using the following command:

passwd root

5. Set a password for the root account when prompted.

6. Reboot the Mac using the following command:

reboot

Once rebooted and back at Setup Assistant, you can open the Terminal by pressing the following keys on the keyboard:

CTL + OPTION + CMD + T

Once Terminal opens, run the following command to switch to using the root user account:

su root

When prompted, enter the password you had earlier set for the root account.

Once your need for using the root account has ended, I strongly recommend disabling the root user account. Apple has a KBase article which describes how to disable the root account, available via the link below:

https://support.apple.com/HT204012

New users on a Mac have a certain set of default settings which are copied into their user profiles the first time they log in. Starting with Mac OS X 10.0.0, these settings have been stored in the following location:

/System/Library/User Template

Inside the User Template directory are a number of language-specific directories where the default settings for various languages are stored. This allows the new user’s default settings to be appropriate for their language and keyboard configuration.

As of macOS Catalina 10.15.0, the location of the User Template directory has changed to the following:

/Library/User Template

The reason for the change is that the /System directory is now stored in Catalina’s read-only volume for the OS. By moving it to /Library, the User Template directory and its enclosed language-specific directories remain readable and writable for those folks who prefer to deploy settings by making changes to the user template directories.

On February 10, 2015, a number of Mac admins noticed that Apple was re-issuing a number of software updates. The updates themselves hadn’t changed, but were being reposted.

The reason was because part of the chain of certificates Apple was using to sign installers used by Apple’s software updates was expiring on February 14th, 2015.

The new expiration date was set as October 24, 2019 at 1:27 PM US Eastern Daylight Time, which is eight days from the date of this post.

Time marches on and once again, Apple is re-signing and re-issuing updates ahead of the October 24th 2019 expiration date.

It looks like the re-signed installers have an expiration date of April 14th, 2029 at 5:28 PM US Eastern Daylight Time.

The certificate expiration will also affect macOS installers or boot media that are signed with the certificates which expire on October 24th. In testing by @neilmartin83, these installers will not work properly following the certificate expiration.

Apple will also be re-signing these installers though, so the fix in most cases will be to download new copies of the relevant macOS installers from the Mac App Store or Software Update.

Since its initial release in OS X Mountain Lion 10.8.x, Apple’s main tool for managing FileVault 2 encryption has been fdesetup. With the transition from managing Core Storage-based encryption on HFS+ to managing the native encryption built into Apple File System completed, this well-developed toolset continues to be Apple’s go-to tool for enabling, configuring and managing FileVault 2 on macOS Catalina.

With its various functions, fdesetup gives Mac administrators the following options for managing FileVault:

• Enable or disable FileVault 2 encryption on a particular Mac
• Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
• Enable one or multiple user accounts at the time of encryption
• Get a list of FileVault 2-enabled users on a particular machine
• Add additional users after FileVault has been enabled
• Remove users from the list of FileVault enabled accounts
• Add, change or remove individual and institutional recovery keys
• Report which recovery keys are in use
• Perform a one-time reboot that bypasses the FileVault pre-boot login
• Report on the status of FileVault 2 encryption or decryption

For more details, please see below the jump.

Enabling Filevault 2 Encryption For One Or Multiple Users

fdesetup is versatile when it comes to enabling FileVault 2 encryption from the command-line. To start with the simplest method, run the following command with root privileges to enable FileVault 2 encryption:

fdesetup enable

You’ll be prompted for the username and password of the primary user, which is the account you will work with at the FileVault 2 pre-boot login screen once the encryption is turned on.

If everything’s working properly, FileVault will enable and you’ll be given an alphanumeric personal recovery.

VERY IMPORTANT: The fdesetup-generated personal recovery key is not saved anywhere outside the machine. Make a record of it or you will not have a recovery key available to help unlock your Mac’s encryption in case of a problem.

You can also enable additional user accounts at the time of encryption, as long as the accounts are either local or mobile accounts on the Mac being encrypted. Run the following command with root privileges to enable FileVault 2 and specify the accounts you want:

fdesetup enable -user username -usertoadd other_username -usertoadd yet_another_username

You’ll be prompted for the passwords of the accounts specified. After that, you’ll be given an alphanumeric personal recovery key and FileVault will turn on. All of the accounts specified should appear at the FileVault 2 pre-boot login screen.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

Additional users can be included as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to enable FileVault 2 encryption and reference the account information in the plist file:

fdesetup enable -inputplist < /path/to/filename.plist

Since the accounts and passwords are in the plist file, fdesetup does not need to prompt for passwords. Instead, the alphanumeric personal recovery key is displayed and FileVault turns on. All of the accounts specified in the plist file should appear at the FileVault 2 pre-boot login screen.

To avoid the need to enter a password, fdesetup also has a -defer flag that can be used with the enable command option to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.

The property list file will be created as a root-only readable file and contain information similar to what’s show below.

Note: For security reasons, the plist file with the recovery key information should not stay on the encrypted system. Please copy it to a safe location and then securely delete this plist file from the encrypted system.

Run the following command with root privileges to defer enabling FileVault 2 and specify the account you want:

fdesetup enable -user username -defer /path/to/filename.plist

If there is no user account specified with the -user option, then the current logged-in user will be enabled for FileVault 2. If there is no user specified and no users are logged in when the command is run, then the next user that logs in will be chosen and enabled.

If you don’t want to specify the account, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist

On logout, the user will be prompted to enter their account password.

Once entered, FileVault 2 will be enabled and the recovery information plist file will be created.

In addition to enabling FileVault 2 as part of the logout process, Apple added the ability to set a deferred enablement at login when they released OS X Yosemite. In macOS Catalina, this means that Mac admins can set a deferred enablement with the following options:

1. Enforce FileVault 2 enablement at logout
2. Enforce FileVault 2 enablement at login
3. Enforce FileVault 2 enablement at both login and logout

To set a deferred enablement at login, the following options may be added to fdesetup‘s -defer flag:

•  -forceatlogin max_cancel_attempts
•  -dontaskatlogout

These additional options allow a deferred FileVault 2 enablement to be enforced at the login window, rather than waiting for a logout or restart of the Mac in question.

The -forceatlogin option must be set with an accompanying numerical value. This numerical value governs how many times the account being enabled can choose to defer having the FileVault 2 encryption process begin. For example, running the following command with root privileges will set a maximum number of ten deferral opportunities:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 10

If the user chooses to defer, they will need to select the Don’t Enable button in the dialog window when it will appear. They will also be informed of how many more times they can log in before FileVault 2 encryption must be enabled.

If immediate enforcement is desired, setting a value of zero will enforce FileVault 2 encryption at the next login. To do this, run the following command with root privileges:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0

The fdesetup commands shown above will enforce FileVault 2 enablement at both login and logout. If only enforcement at login is desired, the -dontaskatlogout option can be used. This will prevent a deferred FileVault 2 enablement to be enforced at logout. For example, running the following command with root privileges will enforce FileVault 2 encryption at the next login but not prompt the user on logout:

fdesetup enable -defer /path/to/filename.plist -forceatlogin 0 –dontaskatlogout

An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.

Enabling Filevault 2 Encryption Using One Or Multiple Recovery Keys

Another capability of FileVault 2 in macOS Catalina is the ability to use the alphanumeric personal recovery key, an institutional recovery key using /Library/Keychains/FileVaultMaster.keychain, or both kinds of recovery key at the same time.

As seen in the earlier examples, fdesetup will provide the alphanumeric personal recovery key by default. To use the institutional recovery key, the -keychain flag needs to be used when enabling encryption:

fdesetup enable –keychain

The alphanumeric personal recovery key is displayed, but the encryption will also use the /Library/Keychains/FileVaultMaster.keychain institutional recovery key. In case recovery is needed, either recovery key will work to unlock or decrypt the encrypted drive.

If you want to specify that only the FileVaultMaster.keychain institutional recovery key be used, both the -keychain and -norecoverykey flags need to be used when enabling encryption:

fdesetup enable -keychain –norecoverykey

fdesetup is also capable of creating an institutional recovery key, using the -certificate flag to import an existing FileVault 2 public key. Once imported, fdesetup will automatically create a FileVaultMaster.keychain file to store the public key and save the keychain to /Library/Keychains.

The public key will need to be available as a DER encoded .cer certificate file. Once the certificate is available, the following command can be run with root privileges to enable FileVault 2, automatically create the institutional recovery key with the supplied public key and store it as /Library/Keychains/FileVaultMaster.keychain:

fdesetup enable -certificate /path/to/filename.cer

To specify that only the FileVaultMaster.keychain institutional recovery key be used, add the -norecoverykey flag to the command:

fdesetup enable -certificate /path/to/filename.cer -norecoverykey

It is also possible to include the public key data in a plist file, which allows the use of a plist to set up the institutional recovery key. The plist needs to follow the format below:

Using the public key’s DER encoded certificate file, the public key data for the plist can be obtained using the base64 tool by using the following command:

base64 /path/to/filename.cer > /path/to/filename.txt

At this point, you would copy the data string contained in the text file and place it into the Certificate value area of the plist file. You would store either the password of an existing FileVault 2-enabled user or (if available) an existing personal recovery key in the Password key in the plist.

Disabling Filevault 2 Encryption

In contrast to all of the various options available for enabling FileVault 2 using fdesetup, the command to turn off FileVault 2 encryption is the following:

fdesetup disable

Adding Additional Users After Filevault 2 Has Been Enabled

Once FileVault 2 has been enabled, you can add additional users using fdesetup. To do so, you will need to a) wait until the FileVault 2 encryption has completed and b) provide both the username and password of a previously enabled account as well as the password of the account you want to add. The following command run with root privileges will enable a user account named otheruser:

fdesetup add -usertoadd otheruser

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

When adding additional users using a plist file, the top level Username key is ignored, and the Password key value should either be an existing FileVault user’s password or the recovery key. Additional users can be added as needed by adding additional user information under the AdditionalUsers plist key.

Note: All account passwords need to be supplied in cleartext.

Once the plist has been set up and properly formatted, run the following command with root privileges to add additional users by referencing the account information in the plist file:

fdesetup add -inputplist < /path/to/filename.plist

Listing Current Filevault 2 Users

To list all accounts enabled for FileVault 2, run the following command with root privileges:

fdesetup list

All accounts will be listed with both the accounts’ username and UUID

Removing Users From The List Of Filevault 2 Enabled Accounts

You can remove users from the list of FileVault enabled accounts by using either their username or the account’s UUID. To remove the account using the username, run the following command with root privileges:

fdesetup remove -user username_goes_here

To remove the account using the account’s UUID, run the following command with root privileges:

fdesetup remove -uuid UUID_here

In both cases, successful removal of the account will not produce any additional output. If the account being removed is not currently enabled for use with FileVault 2, an error message will be displayed.

Managing Individual And Institutional Recovery Keys

fdesetup in macOS Catalina includes the ability to change, add and remove both personal and institutional recovery keys. This gives Mac admins much greater ability to manage recovery keys, including the capability to quickly update or remove compromised personal and/or institutional recovery keys in the event of a data breach or other problem.

You can add or change recovery keys using fdesetup changerecovery. To change to a new personal key, run the following command with root privileges:

fdesetup changerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user. Once entered, a new personal recovery key will be generated and displayed. The former personal recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to change to a new personal recovery key and reference the password or recovery key in the plist file:

fdesetup changerecovery -personal -inputplist < /path/to/filename.plist

You can also export the recovery key to a plist file using the -outputplist verb. To use a plist to import a plist with authentication credentials and export the new recovery key to a separate plist, run the following command with root privileges to change to a new personal recovery key, reference the password or recovery key in the plist file and export the recovery key to a new plist file:

In the event that the Mac in question does not have a personal recovery key, running the commands above will add a personal recovery key instead of changing an existing one.

To change to a new institutional recovery key, you will need to have the new public key available. If you have a new institutional public key available as a DER encoded certificate file, you can run the following command with root privileges to replace the current institutional key:

fdesetup changerecovery -institutional -keychain -certificate /path/to/filename.cer

If an institutional keychain is being used on this Mac, you will see a message that an existing FileVault Master keychain was found and moved. The reason for this is that, as part of this process, the current institutional key’s /Library/Keychains/FileVaultMaster.keychain file is replaced with a new /Library/Keychains/FileVaultMaster.keychain file that includes the new institutional recovery key’s public key.

While the former institutional key’s /Library/Keychains/FileVaultMaster.keychain was moved and not deleted, the former institutional recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

fdesetup changerecovery -institutional -keychain -inputplist < /path/to/filename.plist

In the event that the Mac in question does not have an institutional recovery key, running the commands above will add an institutional recovery key instead of changing an existing one.

Removing Individual And Institutional Recovery Keys

You can remove recovery keys using fdesetup removerecovery. To remove the current personal recovery key, run the following command with root privileges:

fdesetup removerecovery -personal

You’ll be prompted for the password of an existing FileVault 2-enabled user. Once entered, the personal recovery key will be removed from the system. The former personal recovery key will no longer work.

For those who want to automate the process, fdesetup also supports importing a properly formatted plist via a standard input stream (stdin). The plist needs to follow the format below:

You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the current personal recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -personal -inputplist < /path/to/filename.plist

To remove institutional recovery keys, run the following command with root privileges:

fdesetup removerecovery -institutional

You’ll be prompted for the password of an existing FileVault 2-enabled user, or a personal recovery key if one is available. Once entered, the institutional recovery key will be removed from the system and will no longer work.

The removal of the institutional key can also be automated using a properly formatted plist via a standard input stream (stdin). The plist is the same as the one used for removing the personal key.

Once the plist has been set up and properly formatted, run the following command with root privileges to remove the institutional recovery key and reference the password or recovery key in the plist file:

fdesetup removerecovery -institutional -inputplist < /path/to/filename.plist

It is possible to use fdesetup removerecovery to remove one or both recovery keys on a particular Mac. Once the recovery keys are removed, the only way to unlock the FileVault 2 encryption is by using the password of an enabled account. That said, you could use fdesetup changerecovery to add one or both types of recovery keys back to the encrypted Mac.

Recovery Key Reporting

To go along with the ability to manage recovery keys, fdesetup in macOS Catalina enables Mac admins to detect which types of recovery keys are in use on a particular Mac. To check if a personal recovery key is in use, run the following command with root privileges:

fdesetup haspersonalrecoverykey

If FileVault 2 is using a personal recovery key, this command will return true. Otherwise it will return false.

To check if an institutional recovery key is in use, run the following command with root privileges:

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an institutional recovery key, this command will return true. Otherwise it will return false.

One-Time Filevault 2 Encryption Bypass

fdesetup in macOS Catalina has the authrestart verb, which allows a FileVault 2-encrypted Mac to restart, bypass the FileVault 2 pre-boot login screen, and goes straight to the OS login window. To restart and bypass the FileVault 2 pre-boot login screen, run the following command with root privileges:

fdesetup authrestart

When you run the fdesetup authrestart command, it asks for the password of an existing FileVault 2-enabled user.

Once authenticated, the authrestart process puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.

It’s also possible to automate this process by importing the authentication via a properly formatted plist. The plist needs to follow the format below:

You would store either the password of an existing FileVault 2-enabled user or a personal recovery key in the Password key in the plist.

Once the plist has been set up and properly formatted, use the following command with root privileges to run the authrestart process and reference the password or recovery key in the plist file for authentication:

fdesetup authrestart -inputplist < /path/to/filename.plist

fdesetup authrestart is not supported by all Macs. To verify if a specific Mac supports authrestart, run the following command with root privileges:

fdesetup supportsauthrestart

If the Mac supports fdesetup authrestart, this command will return true. Otherwise it will return false.

Reporting On Filevault 2 Encryption Or Decryption Status

fdesetup can report on FileVault 2 encryption or decryption status. Running the following command with root privileges will display the current state:

fdesetup status

Apple has introduced a number of pop-up windows in various OS versions, which appear the first time you log into a Mac and sometimes also after OS updates. For macOS Catalina, Apple has introduced one for Screen Time.

To stop the Screen Time pop-up window from appearing for your home folder, run the command shown below:

defaults write com.apple.SetupAssistant DidSeeScreenTime -bool TRUE

Since you normally will be able to run this command only after you’ve seen the Screen Time pop-up window, I’ve posted a profile for suppressing it. For more details, please see below the jump.

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/master/SkipScreenTimeSetup

I’ve also updated my script for suppressing the various pop-up windows to now also suppress the Screen Time pop-up window. It’s available on GitHub via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/disable_apple_icloud_data_privacy_diagnostic_touch_id_siri_activation_lock_and_screentime_pop_ups

For information on other pop-up windows, please see the links below:

• Suppressing the Data & Privacy pop-up window on macOS High Sierra
• Suppressing Siri pop-up windows on macOS Sierra
• Disabling the iCloud and Diagnostics pop-up windows in Yosemite
• Disabling the iCloud sign-in pop-up message on Lion and later

I recently got an email from a former colleague, requesting assistance with a problem they were seeing. They were cloning drives with macOS Catalina, but their cloning process was not including the Recovery volume. Was there a way to create a new Recovery volume on a macOS Catalina boot drive that didn’t have one?

I did some research on this and found that there was a script to do this on High Sierra and Mojave, but it didn’t appear to work anymore.

With some more digging, I was able to figure out why. The script was downloading and expanding a macOSUpd10.13.6.RecoveryHDUpdate.pkg installer package from Apple’s Software Update service in order to get access to a dm tool included with the installer package. This installer package was no longer available from the Software Update service, but a similar package named SecUpd2019-005HighSierra.RecoveryHDUpdate.pkg with the same dm tool was available.

Once I verified that I could get the same results using the SecUpd2019-005HighSierra.RecoveryHDUpdate.pkg installer package, I wrote a script (based on the original one I had found) to help automate the process of rebuilding a macOS Recovery volume or partition. For more details, please see below the jump.

Downloading the script

The create_macos_recovery script is available from the following location:

https://github.com/rtrouton/create_macos_recovery

Once you have the script downloaded, run the create_macos_recovery script using root privileges with one argument:

• The path to an Install macOS.app

Using the script

If you have a macOS Catalina 10.15.0 installer application available in your Mac’s /Applications directory, run this command with root privileges:

/path/to/create_macos_recovery.sh "/Applications/Install macOS Catalina.app"

If successful, you should see output like this appear:

Once the script has finished running, you should be able to verify that you can boot into Recovery.

Testing notes

Before any use in production, I strongly recommend testing this script on test systems and verifying that this also works for you. Please see below for what I have tested this script with:

OS versions:

• macOS 10.13.6
• macOS 10.14.6
• macOS 10.15.0

OS installers:

• Install macOS High Sierra.app (for 10.13.6)
• Install macOS Mojave.app (for 10.14.6)
• Install macOS Catalina.app (for 10.15.0)

Test systems:

• Virtual machines running in VMware Fusion 11.5.0

Note: I have only tested on systems where FileVault encryption has not been enabled.

Apple has introduced a number of pop-up windows over the years, which appear the first time you log into a Mac and sometimes also after OS updates. In 2016, Apple introduced one for Touch ID as part of introducing the Touch Bar.

For a long time, the only way to suppress this window from appearing was by using the command shown below:

defaults write com.apple.SetupAssistant DidSeeTouchIDSetup -bool TRUE

However, as of macOS Catalina, it is possible to suppress the Touch ID pop up window using a profile. For more details, please see below the jump.

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/master/SkipTouchIDSetup

I also have a script for suppressing the various pop-up windows, which includes suppressing the Touch ID pop-up window. It’s available on GitHub via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/disable_apple_icloud_data_privacy_diagnostic_touch_id_siri_activation_lock_and_screentime_pop_ups

For information on other pop-up windows, please see the links below:

• Suppressing the Screen Time pop-up window with a profile on macOS Catalina
• Suppressing the Data & Privacy pop-up window on macOS High Sierra
• Suppressing Siri pop-up windows on macOS Sierra
• Disabling the iCloud and Diagnostics pop-up windows in Yosemite
• Disabling the iCloud sign-in pop-up message on Lion and later

As a follow-up to last week’s expiration of the certificate used to sign previously-released macOS installers, Apple has released re-signed macOS installers with the new certificate which is good until April 2029.

For those who archive older macOS installers, this means that the macOS installers in question will need to be re-downloaded. macOS Catalina has added some new functionality to the softwareupdate tool which can assist with this. For more details, please see below the jump.

To download the latest installer for macOS Catalina, which is currently at version 10.15.0, please run the command below with root privileges:

softwareupdate --fetch-full-installer --full-installer-version 10.15

Note: Normally the version is specified as 10.x.x, but Apple has historically listed a .0 release as 10.x. So in this case, the softwareupdate command uses 10.15 for macOS 10.15.0.

You should receive a message that the the installer is downloading and installing. In this context, the message refers to installing the macOS Installer app into the /Applications directory on the Mac.

Once the process has completed, you should receive a message that installation has completed successfully.

To verify, check to make sure there is now an Install macOS Catalina app in the /Applications directory.

To download the latest installer for macOS Mojave, please run the command below with root privileges:

softwareupdate --fetch-full-installer --full-installer-version 10.14.6

To download the latest installer for macOS High Sierra, please run the command below with root privileges:

softwareupdate --fetch-full-installer --full-installer-version 10.13.6

macOS Sierra is not available for download via the softwareupdate tool, but it is available via the Mac App Store (MAS). Apple has a KBase article, available via the link below, which shows how to access the macOS Sierra page in the MAS:

https://support.apple.com/HT208202

Update 10-28-2019:

Mike Brogan correctly points out that the KBase article is no longer linking to the MAS, but instead provides a download link to a disk image file which contains the Sierra installer.

It also appears the Apple KBase article for upgrading to OS X El Capitan and the Apple KBase article for upgrading to OS X Yosemite have similar download links to a disk image file which contains the OS X installer.

To access the macOS Sierra page directly, please click on the link below:

https://itunes.apple.com/us/app/macos-sierra/id1127487414?ls=1&mt=12

That link should open the MAS and take you to the macOS Sierra download page.

Apple has started making the following macOS installers available outside of the Mac App Store (MAS).

• macOS Sierra
• OS X El Capitan
• OS X Yosemite

For each listed OS installer, Apple has direct download links via their relevant KBase article for InstallOS.dmg or InstallMacOSX.dmg disk images.

In turn, these disk images contain installers named InstallOS.pkg or InstallMacOSX.pkg.

These installers do not themselves install the relevant version of macOS or OS X. Instead, they install the Install.app for that macOS or OS X version into the /Applications directory.

Once the relevant Install macOS or OS X app is available, it can be used to install that OS.

The installers for the following macOS versions are still available via the MAS.

• macOS Catalina
• macOS Mojave
• macOS High Sierra

They can also be downloaded on macOS Catalina using the softwareupdate tool.

Now that Apple has made direct download links available for older OS installers, I’ve written AutoPkg .download and .pkg recipes for the following macOS installers:

• macOS Sierra
• OS X El Capitan
• OS X Yosemite

These recipes will download the disk images linked to the relevant KBase articles, extract the installer packages stored inside the disk images and rename the disk images and installer packages with the OS name and version number.

One thing to be aware of is that the downloaded installers do not themselves install the relevant version of macOS or OS X. Instead, they install the Install.app for that version of macOS or OS X into the /Applications directory.

The AutoPkg recipes are available via the links below:

• macOS Sierra: https://github.com/autopkg/rtrouton-recipes/tree/master/macOSSierra
• OS X El Capitan: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXElCapitan
• OS X Yosemite: https://github.com/autopkg/rtrouton-recipes/tree/master/OSXYosemite

For those who wanted a copy of my MDM talk at Jamf Nation User Conference 2019, here are links to the slides in PDF and Keynote format.

• PDF – https://tinyurl.com/JNUC2019PDF
• Keynote – https://tinyurl.com/JNUC2019Keynote

For those folks at the talk who were interested in Privileges and ProfileCreator, please see the links below:

• Privileges: https://github.com/SAP/macOS-enterprise-privileges
• ProfileCreator: https://github.com/ProfileCreator/ProfileCreator

Since Oracle’s license change for Java 11 and later took effect in October 2018, where Oracle announced that they would now be charging for the production use of Oracle’s Java 11 and later, the number of open source (and free) OpenJDK distributions has increased dramatically.

Before the license change, most Mac admins would only install Oracle Java on those Macs which needed Java. Now, the list of available vendors has broadened to include the following:

• AdoptOpenJDK
• Amazon
• Azul
• OpenJDK
• Oracle
• SAP

Note: There may be even more OpenJDK distributions available for macOS, but these are the ones I know of.

To help Jamf Pro admins keep track of which vendors’ Java distributions are installed on their Macs, I’ve written a Jamf Pro Extension Attribute to help identify them. For more details, please see below the jump.

This Jamf Pro Extension Attribute verifies if a Java JDK is installed. Once the presence of an installed JDK has been verified by checking the java_home environment variable, the JDK is checked for the vendor information. The EA will return one of the following values:

• None
• AdoptOpenJDK
• Amazon
• Apple
• Azul
• OpenJDK
• Oracle
• SAP
• Unknown

The returned values indicate the following:

None = No Java JDK is installed.
AdoptOpenJDK = AdoptOpenJDK is the Java JDK vendor.
Amazon = Amazon is the Java JDK vendor.
Apple = Apple is the Java JDK vendor.
Azul = Azul is the Java JDK vendor.
OpenJDK = OpenJDK is the Java JDK vendor.
Oracle = Oracle is the Java JDK vendor.
SAP = SAP is the Java JDK vendor.
Unknown = There is a Java JDK installed, but it is not from one of the listed vendors.

The Extension Attribute is available below, and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/java_jdk_vendor

As part of setting up Self Service policies in Jamf Pro, the usual practice is to include an icon to help the user distinguish between various Self Service policies.

However, when copying policy information via the API, a Self Service policy’s icon is sometimes not copied along with the rest of the policy. When this happens, it can be hard to figure this out later which ones were missed.

To help with situations like this, I have a script which does the following:

1. Checks all policies on a Jamf Pro server.
2. Identifies which ones are Self Service policies which do not have icons
3. Displays a list of the relevant policies

For more details, please see below the jump.

The script is named Jamf_Pro_Detect_Self_Service_Policies_Without_Icons.sh. For authentication, the script can accept hard-coded values in the script, manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

defaults write com.github.jamfpro-info jamfpro_url https://jamf.pro.server.goes.here:port_number_goes_here

To store the account username in the plist file:

defaults write com.github.jamfpro-info jamfpro_user account_username_goes_here

To store the account password in the plist file:

defaults write com.github.jamfpro-info jamfpro_password account_password_goes_here

When the script is run, you should see output similar to that shown below.

The script is available below, and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf_Pro_Detect_Self_Service_Policies_Without_Icons

Jamf has posted the session videos for from Jamf Nation User Conference 2019, including the video for my “MDM: From Nice-To-Have to Necessity” session.

For those interested, all of the the JNUC 2019 session videos are available on YouTube. For convenience, I’ve linked my session here.

Every so often, it may be useful to be able to enable or disable all of your current Jamf Pro policies. In those cases, depending on how many policies you have, it can be tedious to have to do them one at a time using the admin console.

However, with the right API calls in a script, it’s straightforward to perform these tasks using the Jamf Pro API. For more information, please see below the jump.

To disable a Jamf Pro policy, you can use curl to send an API call similar to the one shown below:

As an example, here’s how the API call would look if using the following information to disable a specified Jamf Pro policy:

• Jamf Pro server: https://jamfpro.demo.com
• Jamf Pro username: jpadmin
• Jamf Pro username’s password: Password1234
• Jamf Pro policy ID number: 27

To enable a Jamf Pro policy, you can use curl to send an API call similar to the one shown below:

If using the same information as the example above, here’s how the API call would look when enabling the specified Jamf Pro policy

Since running the API calls individually may get tedious, I’ve written a couple of scripts to assist with these tasks:

• Jamf-Pro-Disable-All-Policies.sh
• Jamf-Pro-Enable-All-Policies.sh

These scripts are designed to use the Jamf Pro API to do the following:

• Identify the individual IDs of the computer policies stored on a Jamf Pro server
• If running Jamf-Pro-Disable-All-Policies.sh, disable the policy using its policy ID
• If running Jamf-Pro-Enable-All-Policies.sh, enable the policy using its policy ID
• Display HTTP return code and API output

When the script is run, you should see output similar to that shown below. Because these scripts affect all policies on the Jamf Pro server, the scripts will ask you to confirm that you want to do this by typing the following when prompted:

YES

Any other input will cause the scripts to exit.

If the script is successful, you should see output like this for each policy. In this case, this is output from Jamf-Pro-Disable-All-Policies.sh:

The policy enabling and disabling scripts are available from following addresses on GitHub:

• Jamf-Pro-Disable-All-Policies.sh: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf-Pro-Disable-All-Policies
• Jamf-Pro-Enable-All-Policies.sh: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf-Pro-Enable-All-Policies

A number of Mac admins have their Terminal appearance settings configured just the way they like them, but it can be a bit of manual work to export and import them. After having to manually configure and export these settings more than a few times, I wanted to see if it was possible to export these settings in a way to make it easy to convert into a configuration profile.

With a little work and research, I was able to write a script which handled exporting the Terminal profile I wanted into a properly formatted plist file. For more details, please see below the jump.

The script I wrote is named Export_Mac_Terminal_Profiles and it is a .command file, which means it can be run by double-clicking on it. To use it, please use the following procedure:

1. Identify the name of the Terminal profile you want to export.
2. Double-click on the Export_Mac_Terminal_Profiles.command script.
3. Enter the name of the Terminal profile you want to export.
4. Decide if you want the exported Terminal profile to be set up as a default profile. By specifying it as a default profile, the exported Terminal profile will be configured as both a startup profile and as a default profile.

In this example, I’ve configured a custom Terminal profile named Documentation in my account’s Terminal settings and want to export it for use with a configuration profile.

To export it, I followed the procedure described above and entered the following when prompted:

Name: Documentation
Default profile: 1 (which configures the exported profile to be set as both a startup profile and as a default profile.)

When the script finished running, it opened a Finder window showing me a com.apple.Terminal.plist file.

This plist file contained all of the settings needed to create a configuration profile which did the following:

1. Install the Documentation Terminal profile
2. Configure the Documentation Terminal profile as both a startup profile and as a default profile.

From there, I used Tim Sutton‘s mcxToProfile tool to create a configuration profile from the exported com.apple.Terminal.plist file.

Once I had the configuration profile, I verified that I was able to install it and that the Documentation Terminal profile was now installed and set as the default profile.

However, one side effect I noticed was that installing a Terminal profile using a configuration profile resulted in all other Terminal profiles vanishing from the Terminal preferences.

To restore copies of the OS-provided Terminal profiles, click on the Profiles window’s cog wheel and select Restore Default Profiles.

This will restore the OS-installed Terminal profiles in their default configuration. This restore process will not affect the Terminal profile installed by the configuration profile.

The Export_Mac_Terminal_Profiles script is available below and also on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Export_Mac_Terminal_Profiles

The example configuration profile for the Documentation Terminal profile is also available below.

I’ve been working on a new book with my colleague Charles Edge and I’m delighted to announce it’s now available for regular sale from both Amazon and Apress, our publisher!

Amazon: https://www.amazon.com/Apple-Device-Management-Managing-AppleTVs/dp/1484253876

Apress: https://www.apress.com/us/book/9781484253878

This quality item is suitable for any gift-giving occasion (including the ones occurring this week!) in addition to being the perfect something for yourself. For those who have asked about it being available in electronic format, it’s available in the following formats depending on the seller:

• Amazon: Available for the Kindle
• Apress: Available in PDF and ePub format