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.

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

One of the changes which came with macOS Catalina was the introduction of a read-only root volume for the OS. For users or environments which were used to using adding directories to the root level of the boot drive, this change meant they could no longer do that.

To address this need, Apple added a new method for creating directories at the root level which leverages Apple File System’s new firmlink functionality. Firmlinks are new in macOS Catalina and are similar in function to Unix symbolic links, but instead of only allowing travel one way (from source to destination) firmlinks allow bi-directional travel.

The use of firmlinks is exclusively reserved for the OS’s own use, but Apple has also made available what are called synthetic firmlinks. These synthetic firmlinks are how the OS enables folks to create directories and symbolic links on the read-only boot volume. For more details, please see below the jump.

To create a synthetic firmlink, you need to do the following:

1. Create a file in the /etc directory named synthetic.conf.
2. Make sure /etc/synthetic.conf has the following permissions:

• root: read, write
• wheel: read
• everyone: read

3. In /etc/synthetic.conf, define the name(s) of the empty directory or symbolic link you want to have appear at the root level.

4. After all desired entries have been made, save the /etc/synthetic.conf file.

5. Restart the Mac to apply the changes.

For example, /etc/synthetic.conf may look like this:

Note: In those cases where you’re creating a symbolic link and are including a path, the start point for the directory path is not /. Instead, it is the next directory level down.

To show how this works, I’ve created a directory containing installer packages located at /Users/Shared/installers.

To create a symbolic link at the root level named installers which points to /Users/Shared/installers, I would do the following:

1. Create the /etc/synthetic.conf file if it didn’t already exist.
2. Add the following entry to the /etc/synthetic.conf file:

installers	Users/Shared/installers

3. Reboot the Mac.

Note: Whomever designed this came down on the “tabs” side of the “tabs vs. spaces” debate. When creating the separation between installers and Users/Shared/installers in the /etc/synthetic.conf file, you need to use tabs. If you use spaces instead, the synthetic firmlink won’t be created.

After the reboot, you should see a symbolic link named installers at the root level of the boot volume. When you navigate to it, you should see the contents of /Users/Shared/installers.

To remove the symbolic link, remove the relevant entry from /etc/synthetic.conf and then restart. After the reboot, the installers symbolic link should be missing from the root level of the boot volume.

For more information, please see the synthetic.conf man page. This is available by entering the following command in Terminal on macOS Catalina:

man synthetic.conf

As part of some recent testing, I needed to install rsyslog and the instructions I had referenced using Homebrew to do it. I used the following procedure to do it:

1. Set up a new VM running macOS 10.15.3 in VMware Fusion.

2. Inside the VM, open Terminal and install Homebrew by running the following command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

3. Once Homebrew was installed, install rsyslog by running the following command:

brew install rsyslog

4. Copy a pre-configured rsyslog.conf file to /usr/local/etc/rsyslog.conf.

5. Set the following permissions on /usr/local/etc/rsyslog.conf:

File permissions

Owner: root - read, write
Group: wheel - read
Everyone: read

6. Start rsyslog by running the following command with root privileges:

brew services start rsyslog

When I checked on rsyslog though, it wasn’t running or accepting logs from remote Macs like it should be. What had happened?

For more details, please see below the jump.

When I checked the system log, I saw a number of entries which looked like this:

The rsyslogd process was starting and crashing almost immediately. To stop rsyslog from attempting to launch again, I ran the following commands with root privileges:

brew services stop rsyslog

After that, I started investigating to figure out what had gone wrong.. Since the problem happened almost immediately after launch, I suspected a problem with how rsyslog was being launched. The LaunchD item which starts rsyslog is /usr/local/Cellar/rsyslog/8.2001.0/homebrew.mxcl.rsyslog.plist and it looks like this:

From there, I was able to see the command that was being used to start rsyslog:

/usr/local/opt/rsyslog/sbin/rsyslogd -n -f /usr/local/etc/rsyslog.conf -i /usr/local/var/run/rsyslogd.pid

Next, I tried to run this command manually with root privileges:

/usr/local/opt/rsyslog/sbin/rsyslogd -n -f /usr/local/etc/rsyslog.conf -i /usr/local/var/run/rsyslogd.pid

When I did so, I got the following output:

When I checked on /usr/local/var/run, I discovered that the /usr/local/var/run directory didn’t exist. Since it didn’t exist, rsyslogd couldn’t write the following file to it:

/usr/local/var/run/rsyslogd.pid

To fix this, I ran the following command to create the directory:

mkdir -p /usr/local/var/run

Once the /usr/local/var/run directory existed, I ran the following command with root privileges:

brew services start rsyslog

This time, rsyslog started without a problem and I was able to continue with my testing.

All SSL certificates have a set amount of time which they’re good for, which means that at some point they expire. As an example, the SSL certificate currently used by www.apple.com has the following expiration date and time:

Friday, October 23, 2020 at 8:00:00 AM Eastern Daylight Time

As of today, March 5th 2020, the maximum lifetime for publicly trusted SSL certificates is 825 days, or roughly 27 months.

Apple has announced that, starting on September 1, 2020 at 00:00 GMT/UTC, all new SSL certificates being issued by specific Root Certificate Authorities (Root CAs) must not have a maximum lifetime longer than 398 days, or roughly 13 months, in order to be accepted as a valid certificate on Apple’s iOS, iPadOS, macOS, watchOS, and tvOS operating systems.

What certificates are affected?

This does not affect all SSL certificates. It will affect certificates issued on or after the September 1, 2020 start date by the Root CAs which are preinstalled with Apple’s iOS, iPadOS, macOS, watchOS, and tvOS operating systems.

Since these CAs are installed along with the OS, the certificates issued by these Root CAs are trusted by Apple’s OSs without any additional work needed by the end user. These Root CAs include commercial SSL vendors like Go Daddy, DigiCert and other companies.

What certificates are not affected?

Certificates issued by the specified preinstalled Root CAs before the September 1, 2020 start date are not affected. If they have a lifespan longer than 398 days, Apple will continue to accept them as valid until their set expiration date as long as they were issued prior to September 1, 2020 at 00:00 GMT/UTC.

Certificates issued by Root CAs which do not come with the operating system are also not affected. So if your company, school or institution has their own Root CAs , SSL certificates issued by those CAs are not affected by the new maximum lifetime restriction. Those CAs can continue to issue SSL certificates with lifetimes longer than 398 days.

Note: These Root CAs are not trusted by default by Apple’s operating systems. Instead, the Root CA’s root certificate would need to be installed and set as a trusted root by either the user or a system administrator.

Does this affect anyone other than Apple?

As of now, this is a unilateral move by Apple which hasn’t been adopted by other vendors. That said, Google had proposed something similar in September 2019 so it would not be surprising to see Google also adopt this at some point.

Will this affect only web browsers?

SSL certificates are used by a variety of applications and tools to help provide secure communication, so the effects of this change will not be restricted to web browsers like Safari. Non-compliant certificates may result in network services or applications failing to work properly.

As part of discussing the outcome of a troubleshooting session concerning Jamf Pro and profile deployment with a teammate, I learned that the two functions that Jamf Pro uses to update its computer inventory worked in a similar fashion, but they weren’t identical.

The differences turned out to be important for profile deployment. For more details, please see below the jump.

There’s a couple of ways that you can request a computer inventory using Jamf Pro:

1. Using the Jamf agent’s recon function

2. Using a Jamf policy’s Update Inventory function.

With regards to profiles, the two inventory update processes run the DeviceInformation MDM command at different times in the inventory gathering process, with relationship to when the inventory update process checks extension attributes.

When running an inventory update using the Update Inventory function in a Jamf Pro policy, the following items are run in this order:

1. The DeviceInformation MDM command is run.
2. Extension attributes are checked and updated.

When running an inventory update using the recon function of the Jamf agent, the following items are run in this order:

1. Extension attributes are checked and updated.
2. The DeviceInformation MDM command is run.

Why is this important?

If you have profiles scoped to the results of an extension attribute, having that extension attribute checked and updated before profile assignments change will result in that profile being deployed correctly once.

If the extension attribute hasn’t been checked before profile assignments change, you may see that profile not deploy, deploy based on what is incorrect information, or even deploy multiple times as first incorrect and then correct data comes in from the extension attribute.

What to do?

If you have profiles scoped to extension attributes, my recommendation is to use the Jamf agent’s recon function to run inventory updates. If you need to run an inventory as part of a policy, you can use the Jamf agent’s recon function to run an inventory update by using the following process:

1. Select the policy in question.
2. Go to the Files and Processes section.
3. Go to the Execute Command blank.
4. Enter the following command:

/usr/local/jamf/bin/jamf recon

This will trigger the Jamf agent on the individual computers to run a recon using the Jamf agent.

Every so often, you may run across a Mac which is enrolled in an MDM server which is different from the one it should be. However, if you’re checking remotely, it may be difficult to identify which one it is.

To help with this task, there is a script available which will parse the MDM enrollment profile on your Mac and identify the DNS name of the MDM server. For more details, please see below the jump.

When run, the script should provide output similar to what’s shown below:

If enrolled with an MDM server:

username@computername ~ % sudo ./check_mdm_enrollment.sh
Password:
MDM server address: mdm.server.address.here
username@computername ~ %

If not enrolled with an MDM server:

username@computername ~ % sudo ./check_mdm_enrollment.sh
Password:
Not enrolled in an MDM server.
username@computername ~ %

The script is available below. It is also available from the following location on GitHub:

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

Recently, I was tasked with figuring out how to disable telemetry for Microsoft’s Visual Studio Code. Normally, you can disable telemetry in a Microsoft application through using a macOS configuration profile or by using a defaults command. In this case though, Microsoft bought Visual Studio Code along with the rest of Xamarin, and Xamarin had some different ideas on where and how to store settings.

In the case of Visual Studio Code, the command to disable telemetry is stored as a .json file in the following location:

/Users/username_here/Library/Application Support/Code/User/settings.json

After some research and some work with an open source tool named jq, I was able to figure out how to handle disabling the telemetry setting. For more details, please see below the jump.

The method I arrived at uses jq. This is a JSON manipulation tool which is not included with macOS, so I needed to install it separately before using it.

Once I had jq installed, I was able to write a script which did the following:

1. Checked to make sure the Mac in question was logged-in
2. Verified that the logged-in user was not the root user.
3. Verified that jq was installed at a location defined in the script and set as executable.
4. Checked for the existence of the settings.json file in /Users/username_here/Library/Application Support/Code/User.

If /Users/username_here/Library/Application Support/Code/User/settings.json is present, the script does the following:

A. Reads out the contents of the existing settings.json file.
B. Adds the following setting to the copied contents:

“telemetry.enableTelemetry”: false

C. Overwrites the existing settings.json file with the copied contents, which added the new telemetry setting.
D. Changes the ownership of the /Users/username_here/Library/Application Support/Code/User/settings.json file to that of the logged-in user.

If /Users/username_here/Library/Application Support/Code/User/settings.json is not present, the script does the following:

A. Creates the settings.json file in /Users/username_here/Library/Application Support/Code/User.
B. Adds the following setting to the newly-created file:

“telemetry.enableTelemetry”: false

C. Changes the ownership of the /Users/username_here/Library/Application Support/Code/User/settings.json file to that of the logged-in user.

5. Verifies that the telemetry.enableTelemetry setting is present and set to false.

The script is available below. It is also available from the following location on GitHub:

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

As part of macOS Catalina 10.15.4, Apple has begun displaying a new dialog window message concerning third-party kernel extensions. macOS Catalina is the last macOS to fully support the use of kernel extensions and these messages are meant to notify users of the following:

• macOS had detected that a third-party kernel extension had been loaded.
• The loaded kernel extension would be incompatible with an unspecified future version of macOS

To further reinforce the message that kernel extensions are going away, Apple refers to them in the message window as “legacy system extensions”. System extensions were introduced as part of macOS Catalina and are Apple’s replacement for kernel extensions.

As of macOS 10.15.4, these messages are informational only and do not indicate that anything is wrong with the referenced third-party kernel extension. For more information, please see the link below:

https://support.apple.com/HT210999

Blocking the messages

For a number of managed environments, these messages can be prevented from appearing. As long as a third-party kernel extension is whitelisted using an appropriate configuration profile, the message for it should not appear.

For more information about whitelisting kernel extensions using a configuration profile, please see the links below:

https://derflounder.wordpress.com/2018/04/12/whitelisting-third-party-kernel-extensions-using-profiles/
https://support.fleetsmith.com/hc/en-us/articles/360037495013-What-is-a-kernel-extension-
https://support.apple.com/guide/mdm/kernel-extension-policy-mdm88f99b98a/web

Every so often, I need to use Safari to access something which is using a self-signed certificate. When I do so, Safari now walks you through the following procedure:

1. Warns you something’s not right and give you the option of either going back or seeing the details.
2. If you choose to see the details, Safari will let you view the certificate.

Safari will also give you the option of proceeding anyway.

If you choose to proceed anyway, Safari will store the self-signed certificate in your login keychain and mark it as trusted.

With this certificate now marked as trusted, Safari will allow you to visit the website.

However, what happens when the SSL certificate changes but keeps the same subject name? At this point, connections from Safari to the site will fail with an error message similar to the one described below:

Safari Can’t Open the Page
Safari can’t open the page because Safari can’t establish a secure connection to the server “server.name.here”.

The reason that this message appears is because Safari is using HTTP Strict Transport Security, otherwise known as HSTS. One of the requirements of HSTS as implemented by Safari is that if the security of the connection cannot be ensured, Safari must terminate the connection and should not allow the user to access the web application.

Since the self-signed certificate stored in your login keychain and the SSL certificate being received don’t match each other, that tells Safari that the certificate being received can’t be trusted. The result is Safari immediately terminates the connection and displays an error message like the one shown above.

However, what if the certificate changing is known behavior and you know that proceeding is safe? It’s possible to re-set Safari’s behavior, but it’s not intuitive. For more details, please see below the jump.

In my case, the certificate change is because I was switching between test instances of VMware’s ESXi hypervisor, which includes a web admin console which by default is protected by a self-signed certificate which is generated when you install ESXi. Because I had multiple ESXi test instances and wanted to use the same domain name for each, I had multiple unique self-signed SSL certificates which all happened to share the same DNS name: esxi.demo.com

What that meant is that for the first instance, I was given the option of storing the SSL certificate in my login keychain and I could thereafter connect to the first instance. But after doing that for first instance, I couldn’t then connect to the others because of HSTS.

To fix this, I used the following procedure:

1. Quit Safari

2. Open /Applications/Utilities and launch Keychain Access.app

3. Select the login keychain.

4. Identify the self-signed certificate which Safari stored in the keychain.

5. Delete the self-signed certificate.

Note: If you are running macOS Mojave or macOS Catalina, you will also need to run steps 6 through 13 to enable Terminal to have Full Disk Access. Otherwise, skip to step 14.

6. Open System Preferences.

7. Choose the Security & Privacy preference pane.

8. Select the Privacy tab.

9. Click the lock icon in the lower left corner of the preference panel and authenticate with an admin account’s credentials.

10. Select Full Disk Access.

11. Click the [+] plus button.

12. Select /Applications/Utilities/Terminal.app.

13. If needed, quit and relaunch Terminal.

Note: All of the commands referenced below should be run as the logged-in user. Do not run them as root.

14. Open Terminal

15. Run the following command to stop Safari’s HTTP Storage Manager.

killall nsurlstoraged

16. Run a command similar to the one shown below to remove the server address from the Safari’s list of accepted self-signed sites:

/usr/libexec/PlistBuddy -c "Delete :com.apple.CFNetwork.defaultStorageSession:server.name.goes.here" $HOME/Library/Cookies/HSTS.plist

For example, if the server name is esxi.demo.com, the command would look like this:

/usr/libexec/PlistBuddy -c "Delete :com.apple.CFNetwork.defaultStorageSession:esxi.demo.com" $HOME/Library/Cookies/HSTS.plist

17. Run the following command to start Safari’s HTTP Storage Manager again:

launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist

To test this, open Safari and try connecting again to your site. It should now walk you through the procedure of storing the self-signed certificate and allowing you to connect again.

I recently saw an issue where several computers in Jamf Pro were showing up with the same serial number listed in their inventory records. This made it difficult to work with this serial number using the API because Jamf Pro Classic API calls may fail if we’re referencing the serial number in the API call and more than one inventory record exists with that serial number.

First off, how can this happen? Aren’t serial numbers supposed to be unique? They are, but there’s two instances where serial numbers may unfortunately be associated with more than one Mac.

Hardware repair:

When you send a Mac out for repair and the logic board is replaced as part of the repair, the Mac’s existing serial number is flashed onto the replacement logic board.

However, both the old and new logic boards have separate Unique Device Identifiers (UDID) associated with them. When enrolling a device into Jamf Pro, it is possible for a new inventory record to be set up if a device has:

• The same serial number listed in as an existing inventory record
• A UDID not found in other inventory records

Parallels macOS virtual machine:

macOS virtual machines set up by Parallels Desktop and other Parallels hypervisor products use the same serial number as the Mac which is running the Parallels hypervisor software. These VMs will likewise have separate Hardware UDIDs associated with them.

So what to do with these duplicate records? My recommendation is to delete them from your Jamf Pro server when you find them, especially if you do a lot of work using the API. To help with this task, a script has been developed to identify and delete unwanted duplicates. For more details, please see below the jump.

This script downloads all computer inventory records from a Jamf Pro server. The list of records is then parsed for inventory records with the same Apple serial number as at least one other record.

Once the duplicate serial numbers are identified, the script takes the following actions:

1. Loop through the duplicate serial number list and get all of the associated Jamf Pro computer IDs
2. Loop through the Jamf Pro IDs and identify the IDs with the most recent enrollment dates.
3. Verify that the individual Jamf Pro IDs are associated with Macs, as opposed to virtual machines running macOS.
4. Loop through the list of identified Macs with Jamf Pro IDs and delete all Macs except for the one with the most recent enrollment date.
5. Create a report in tab-separated value (.tsv) format which contains the following information about the deleted Macs.

• Jamf Pro ID
• Manufacturer
• Model
• Serial Number
• Hardware UDID

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 which looks similar to this.

The report generated in tab-separated value (.tsv) format should be openable natively by both Microsoft Excel and Apple Numbers.

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

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

In my career, I’ve run across a lot of terrible installers in a variety of forms. The one I ran across today though is noteworthy enough that I want to point it out because of the following reasons:

1. It’s an installer application. I have opinions on those.
2. It’s for a security product where, as part of the installation, you need to provide the username and password for an account on the Mac which has:

• Administrator privileges
• Secure Token

Note: I have no interest in talking to the vendor’s legal department, so I will not be identifying the vendor or product by name in this post. Instead, I will refer to the product and vendor in this post as “ComputerBoat” and leave discovery of the company’s identity to interested researchers.

For more details, please see below the jump.

To install ComputerBoat, you will need the following:

1. The ComputerBoat installer application.
2. A configuration file for the ComputerBoat software.
3. The username and password of an account with the following characteristics:

• Administrator privileges
• Secure Token

Once you have those, you can run the following command to install ComputerBoat:

Why it necessary to provide the username and password of an account with admin and secure token? So this product can set up its own account with admin privileges and a Secure Token!

Why is it necessary for this product to set up its own account with admin privileges and a Secure Token? I have no idea. Even if it is absolutely necessary for that service account to exist, there is no sane reason why an application’s service account needs a Secure Token. In my opinion, there are only three reasons why a service account may need to have Secure Token.

1. To add the service account to the list of FileVault-enabled users.
2. To enable the service account to create other accounts which have Secure Tokens themselves.
3. To enable the service account to rotate FileVault recovery keys.

All of those reasons have serious security implications. Even more serious security implications are brought up by the fact that this vendor thought requesting the username and password of an account with admin and secure token was an acceptable part of an installation workflow. To further illustrate this, here’s a sample script which the vendor provided for installation using Jamf Pro:

Here, the installation workflow is as follows:

1. Use curl to download a compressed copy of the ComputerBoat installer’s configuration file in .zip format.
2. Use ditto to unzip the dowloaded configuration file into a defined location on your Mac.
3. Use ditto to unzip the downloaded installer into the same defined location on this Mac.
4. Run a directory listing of the defined location.
5. Remove extended attributes from the uncompressed ComputerBoat installer application.
6. Using credentials for an admin account with Secure Token, install the ComputerBoat software and set up a new account with a Secure Token to act as the application’s service account.
7. Checks to see if it can run a command to get the newly-installed application’s version number.

• A. If the version number comes back, the install succeeded. 
• B. If nothing comes back, the installation is reported as having failed.

The only defense I can think of for the vendor is that it says “Sample” in the description. That may imply that the vendor built this as a proof of concept and may be trying to subtly encourage their customer base to develop better solutions for deploying the ComputerBoat software on Macs. On the other hand, I received this script on the customer end of the transaction. That meant that someone at the vendor thought this was good enough to give to a customer. Either way, it’s not a good look.

Why is this script problematic?

Security problems

1. You need to supply the username and password on an account on the Mac with admin privileges and Secure Token using a method that other processes on the computer can read. This leaves open the possibility that a malicious process will see and steal that username and password for its own ends.
2. The script is set to run in debug mode, thanks to the set -x setting near the top of the script. While this may be helpful in figuring out why the installation process isn’t working, the verbose output provided by debug mode will include the username and password of the account on the Mac with admin privileges and Secure Token.

Installation problems

1. Without supplying the username and password on an account on the Mac with admin privileges and Secure Token, the installation process does not work.

If you’re deploying this security application to your fleet of Macs, that means that the vendor has made the following assumptions:

• You have an account with admin privileges and Secure Token on all of your Macs which share the same username and password.
• You’re OK with providing these credentials in plaintext, either embedded in the script or provided by a Jamf Pro script parameter in a policy.

2. Without providing a separate server to host the ComputerBoat installer’s configuration file, the installation process does not work.

• If you’re deploying this software, the vendor apparently did not think of using Jamf Pro itself as the delivery mechanism for this configuration file. Hopefully you’ve got a separate web server or online file service which allows for anonymous downloading of a file via curl.

3. Without figuring out a way to get the installer into the same location as the downloaded configuration file, the installation process does not work.

• Overlooked by the installation script is this question: How does the installer get to the location defined in the script as $COMPUTERBOATEPM_INSTALL_TMP ? The script assumes it’ll be there without including any actions to get it there or checking that it is there.

There are further issues with this script, but they fall into the category of quirks rather than actual problems. For example, I can’t figure out the purpose of the following lines:

ls -al $COMPUTERBOATEPM_INSTALL_TMP
xattr -d $COMPUTERBOATEPM_INSTALL_TMP/Install\ ComputerBoat\ EPM.app

Neither command seems to do something useful. The first one will list the contents of the directory with the configuration file and the installer application, but then that information isn’t captured or used anywhere. The second removes extended attributes from the ComputerBoat installer application, but the reason for this removal isn’t explained in any way.

You can draw conclusions about a vendor and their product quality by looking at how that vendor makes it possible to install their product. In examining this installation process, especially considering this is for a product intended to improve security in some way, I have drawn the following conclusions:

1. The vendor has not invested resources in building macOS development or deployment expertise.
2. The vendor is unwilling or unable to avoid compromising your security with their product’s installation process.
3. The vendor is not serious about developing or maintaining a quality product for macOS.

When you see installation practices like this, I recommend that you draw your own conclusions on whether this is a vendor or a product you should be using.

With WWDC 2020 only a couple of weeks away, a number of folks are preparing to run the new beta version of macOS. While some will choose to go all-in and run the new OS on their main boot drive, others will prefer to install the new OS onto an external drive. However, for Macs equipped with T2 chips, there’s an extra step involved with allowing your Mac to boot from an external drive. For more details, please see below the jump.

Apple has a KBase article describing how to use the Startup Security Utility in macOS Recovery [] to allow booting from external media (AKA an external drive.) This KBase article is available via the link below:

About Startup Security Utility: https://support.apple.com/HT208198

To open Startup Security Utility:

1. Boot to macOS Recovery
2. Authenticate if requested.

3. Under the Utilities menu, select Startup Security Utility.

4. If requested to authenticate, click the Enter macOS Password button.

5. Choose an administrator account and provide the account’s password.

Once authenticated, select the Allow booting from external or removable media option.

To illustrate, I’ve made a video showing the described process.

I was recently asked for assistance with a way to enable diagnostic logging for Microsoft Outlook 2019 for macOS:

I had seen Microsoft’s KBase article on how to do it, where it references enabling logging via the Outlook preferences:

https://support.microsoft.com/en-us/help/2872257/how-to-enable-logging-in-outlook-for-mac

However, the KBase article only references how to enable this logging via the GUI and does not show how to do this via the command line. Fortunately my colleague @golby knew which settings could enabled from the command line to produce the requested logging. For more details, please see below the jump:

The following defaults command can be run to enable Outlook’s diagnostic logging for the logged-in user:

defaults write com.microsoft.Outlook LogForTroubleshooting -bool TRUE

The following defaults command can be run to disable Outlook’s diagnostic logging for the logged-in user:

defaults write com.microsoft.Outlook LogForTroubleshooting -bool FALSE

Once the logging is enabled, the logs are stored in the following location:

/Users/username_goes_here/Library/Containers/com.microsoft.Outlook/Data/Library/Logs/

To help with enabling the logging, I’ve built a configuration profile to enable the logging. It’s available via the link below:

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

Most Mac admins, especially those who file bug reports or who work with AppleCare Enterprise, are familiar with running the sysdiagnose tool to gather diagnostic information about a Mac they’re working on. Running sysdiagnose will trigger a large number of macOS’s performance and problem tracing tools and use their reports to assemble what amounts to a snapshot of your Mac’s complete state at the time you ran the sysdiagnose tool, which can be very useful to developers trying to trace down why a particular problem is occurring.

However, this tool only applies to a Mac’s regular OS. What if the problem you’re seeing is in the macOS Recovery environment? In that case, you can run the recoverydiagnose tool in macOS Recovery to gather similar data specifically for macOS Recovery-related problems. For more details, please see below the jump.

Note: macOS Recovery uses read-only storage and you won’t be able to save anything to it. As a consequence, you will need to have writable storage available to store the data which is being assembled and stored by the recoverydiagnose tool. This can be an external USB or Thunderbolt drive or even network storage, depending on what’s available.

Running recoverydiagnose

1. Boot to macOS Recovery

2. Connect storage that you can read and write to.

3. Open Terminal.

4. Run the recoverydiagnose tool and specify where you want to store the assembled data.

Normally, you would run a command similar to the one below:

recoverydiagnose -f /path/to/logging/directory

For example, if you have an attached USB drive named Data and want to store the data there, the command would look like this:

recoverydiagnose -f /Volumes/Data

Information about what data is being gathered will be displayed and give you the chance to opt out.

If you choose to continue, recoverydiagnose will gather its data and store it in the specified destination.

For more information about this tool, run the recoverydiagnose command without specifying any options. This will trigger the recoverydiagnose documentation to be displayed.