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.

Every so often, I need to delete a bunch of Jamf Pro policies at once. One convenient way I’ve found to do this is to assign all the policies I want to delete to one category which doesn’t have any other policies assigned to it. Once assigned, I can then use the API to delete them all at once.

To assist with this task, I’ve been using a script written by Jeffrey Compton but over time I found that I wanted more functionality. To meet my own needs, I took Jeffery’s original idea and written my own script to target the policies in a particular Jamf Pro category. For more details, please see below the jump.

This script is designed to do the following:

1. List all categories on a Jamf Pro server.
2. Allow a category to be specified.
3. List all policies (if any) associated with that category.
4. Confirm that all policies in that category should be deleted.
5. Delete all policies in that category.

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.

You’ll be requested to enter the name of a category.

You’ll be asked to confirm that you want to delete the relevant policies.

Once confirmed, the policies will be deleted.

The script is available from following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf-Pro-Delete-All-Policies-In-Specified-Category

The good folks at Penn State have begun posting session videos from the Penn State MacAdmins Campfire Sessions to YouTube. As they become available, you should be able to access them via the link below:

https://www.youtube.com/user/psumacconf/videos

I’ve linked my “Introduction to MDM and Configuration Profiles” session here:

My colleague Anthony Reimer’s “Things I Learned from the Autopkg Maintainers” session is likewise available here:

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.

As part of macOS Catalina, Apple introduced Activation Lock for Macs. As on iOS, Activation Lock is an anti-theft feature designed to prevent activation of a Mac if it’s lost or stolen.

Activation Lock on Macs does have some requirements in order for it to work. The Mac must:

• Run macOS Catalina or later
• Use the Apple T2 Security chip
• Two-factor authentication must be enabled on the Apple ID used for enable Activation Lock.
• Secure Boot must be enabled with Full Security settings and Disallow booting from external media selected.

Once these requirements are satisfied, Activation Lock is automatically enabled when Apple’s Find My service is enabled.

However, having Activation Lock turn on when Find My is enabled can lead to situations where it’s enabled by an employee on company-owned equipment. When this happens, companies, schools or institutions need a way to bypass Activation Lock without needing to know anything about the Apple ID used by the employee.

To provide this bypass, Apple has made it possible for companies, schools and institutions to use their MDM solution to clear Activation Lock. For more details, please see below the jump:

In order to clear Activation Lock using a MDM, the Mac in question needs to be supervised, which has the following requirements. The Mac must:

• Use macOS Catalina or later
• Be enrolled with an MDM
• MDM must be using Apple’s Automated Device Enrollment service via Apple Business Manager or Apple School Manager.

If a Mac is supervised and managed via Jamf Pro 10.20.0 or later, an Activation Lock bypass code is automatically generated and stored as part of the computer’s inventory. It’s available in the computer’s inventory listing, under the Management section.

Note: This Activation Lock bypass code capability is not exclusive to Jamf Pro; it’s available to all MDM solutions. If your MDM solution does not yet support it, ask your vendor to add this support.

To use the Activation Lock bypass code, please use the following procedure:

1. Get the bypass code from Jamf Pro.

2. Boot to macOS Recovery or Internet Recovery .
3. Make sure your Mac is able to communicate with the Internet and the required Apple services.
3. At the Activation Lock screen, go to the Recovery Assistant menu and select Activate with MDM key…

4. Enter the bypass code and click the Next button.

Once the bypass code has been accepted, the Mac should clear the activation lock and activate.

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

This week, I’m attending Apple’s WWDC 2020 conference from the comforts of home. As part of this, I’m taking notes during the labs and session videos. Due to wanting to stay on the right side of Apple’s NDA, I’ve been posting my notes to Apple’s developer forums rather than to here.

To make it easier for Mac admins to access them, I’ve set up a post in the forums where I’ve linking the various forum posts with my notes. It’s available via the link below:

https://developer.apple.com/forums/thread/650135

As part of testing macOS Big Sur 11.0.0, I’ve updated my create_macos_vm_install_dmg script. For more details, please see below the jump.

Downloading the script:

The create_macos_vm_install_dmg script is available from the following location:

https://github.com/rtrouton/create_macos_vm_install_dmg

Using the script:

Once you have the script downloaded, run the create_macos_vm_install_dmg script with two arguments:

1. The path to an Install macOS.app.
2. An directory to store the completed disk image in.

Example usage:

If you have a macOS Big Sur Beta installer available, run this command:

/path/to/create_macos_vm_install_dmg.sh "/Applications/Install macOS Beta.app" /path/to/output_directory

If you had chosen to not create the .iso file, this should produce a .dmg file inside output_directory that’s named something similar to macOS_1100_installer.dmg.

(Note: the WWDC beta identifies itself as 10.16, so a disk image of Big Sur’s WWDC beta will be named macOS_1016_installer.dmg.)

If you chose to create the .iso disk image, you should have two files inside the chosen directory: macOS_1100_installer.dmg and macOS_1100_installer.iso

Creating a VM with the OS installer disk image using VMware Fusion 11.x

1. Launch VMWare Fusion 11.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select your macOS installer disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

• Operating System: Apple OS X
• Version: macOS 10.15

7. In the Finish window, select Customize Settings if desired. Otherwise, click Finish.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the macOS installer disk image. To install macOS, start the VM and then run through the normal installation process when prompted.

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

A while back, I discussed how to incorporate installer package signing into AutoPkg workflows. The PkgSigner processor used in this workflow was originally written by Paul Suh and it uses Apple’s productsign tool to access a Developer ID Installer certificate stored in the login keychain.

Like other processors and AutoPkg itself, PkgSigner needed updating to Python 3 when Python 2 reached end-of-life in April 2020. This updating process has been completed, thanks to Nick McDonald. To make sure PkgSigner is consistently using the same Python environment across machines, PkgSigner has also been set to use the Python 3 install bundled with AutoPkg.

For those who need it, I have a copy of the PkgSigner processor available via the link below:

https://github.com/rtrouton/AutoPkg_Processors/tree/master/PkgSigner

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.

I’ll be speaking about how SAP transitioned to an at-home workforce this year at Jamf Nation User Conference 2020, which is being held online from September 29th – October 1st, 2020. For those interested, my talk will be on Tuesday, September 29th from 12:30pm – 1:00pm CDT.

For a description of what I’ll be talking about, please see the SAP in the Haus – How SAP transitioned its global workforce to working from home session description. You can see the whole list of JNUC sessions here on the Sessions page.

If you haven’t already signed up, the conference is free and there’s still time to register. You can do that via the link below:

https://www.jamf.com/events/jamf-nation-user-conference/2020/registration/

With the ongoing change from kernel extensions to system extensions, one new thing Mac admins will need to learn is how to uninstall system extensions. Fortunately, Apple has provided a tool as of macOS Catalina that assists with this: systemextensionsctl

If you run the systemextensionsctl command by itself, you should get the following information about usage:

systemextensionsctl: usage:
	systemextensionsctl developer [on|off]
	systemextensionsctl list [category]
	systemextensionsctl reset  - reset all System Extensions state
	systemextensionsctl uninstall  ; can also accept '-' for teamID

The last verb, uninstall, is what allows us to remove system extensions. For more details, please see below the jump.

To uninstall a system extension using systemextensionsctl, you need to provide the following:

• Team identifier of the certificate used to sign the system extension
• Bundle identifier for the system extension

Locating Team and bundle identifiers

You can identify team and bundle identifiers by locating the system extension in question inside the application and running the following commands:

To identify the Team identifier:

codesign -dvvv /path/to/name_goes_here.systemextension 2>&1 | awk -F= '/^TeamIdentifier/ {print $NF}'

To identify the bundle identifier:

codesign -dvvv /path/to/name_goes_here.systemextension 2>&1 | awk -F= '/^Identifier/ {print $NF}'

For example, Microsoft Defender ATP currently has several system extensions within its application bundle:

• /Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.epsext.systemextension
• /Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.netext.systemextension
• /Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.tunnelext.systemextension

To find the bundle identifier for the com.microsoft.wdav.epsext.systemextension system extension, run the command shown below:

codesign -dvvv "/Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.epsext.systemextension" 2>&1 | awk -F= '/^Identifier/ {print $NF}'

That should give you the following output:

username@computername ~ % codesign -dvvv "/Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.epsext.systemextension" 2>&1 | awk -F= '/^Identifier/ {print $NF}'
com.microsoft.wdav.epsext
username@computername ~ %

To find the Team identifier for the com.microsoft.wdav.epsext.systemextension system extension, run the command shown below:

codesign -dvvv "/Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.epsext.systemextension" 2>&1 | awk -F= '/^TeamIdentifier/ {print $NF}'

That should give you the following output:

username@computername ~ % codesign -dvvv "/Applications/Microsoft Defender ATP.app/Contents/Library/SystemExtensions/com.microsoft.wdav.epsext.systemextension" 2>&1 | awk -F= '/^TeamIdentifier/ {print $NF}'
UBF8T346G9
username@computername ~ %

Uninstalling a system extension

Once you have both, you can run the following command with root privileges to uninstall a system extension:

systemextensionsctl uninstall Team_Identifier_Goes_Here Bundle_Identifier_Goes_Here

For example, if you wanted to uninstall Microsoft Defender’s com.microsoft.wdav.epsext.systemextension system extension, you would run the following command with root privileges:

systemextensionsctl uninstall UBF8T346G9 com.microsoft.wdav.epsext

Note: As of September 1, 2020, running the systemextensionsctl uninstall command requires System Integrity Protection (SIP) to be disabled. This limitation is supposed to be removed by Apple at some point in the very near future.

For a variety of reasons, MDM commands sent out from an MDM server can fail to run correctly on a Mac. Many times, these MDM commands will not be re-sent unless the failure is cleared. With the failure cleared, the MDM server will not have a record of sending the MDM command and should try again.

On Jamf Pro, there’s a couple of ways you can clear failed MDM commands. The first is a manual process which uses the Jamf Pro admin console. The second uses the Jamf Pro Classic API and can be automated. For more details, please see below the jump.

Clearing failed MDM commands using the Jamf Pro admin console

To clear failed MDM commands using the admin console, please use the procedure shown below.

1. Run a search for the computers you want to clear.

Note: If you search with no criteria, the search results will list all Macs enrolled with the Jamf Pro server.

2. Once you have the desired list, click the Action button.

3. Select Cancel Remote Commands and click the Next button.

4. Select Cancel All Failed Commands and click the Next button.

5. Once all failed commands have been cleared, click the Done button.

Clearing failed MDM commands using the Jamf Pro Classic API

You can also use the Jamf Pro Classic API to script an automatic clearing of failed MDM commands at whatever interval is desired. There’s numerous ways to make this work, with my approach being the following:

1. Write a script designed to run via a Jamf Pro policy on individual Macs to perform the following tasks:

a. Use the API and the Mac’s hardware UUID to identify the Mac’s computer ID in Jamf Pro.
b. Use the API and the Mac’s hardware UUID to download the list of failed MDM commands.
c. Use the API and the Mac’s Jamf Pro computer ID clear all failed MDM commands associated with that Jamf Pro computer ID.

Note: For those who haven’t used the Jamf Pro Classic API before, you will need to provide a username and password to the script. This is a security risk, so my recommendation is to carefully evaluate if the risk is worth it for your environment. If it’s not, don’t use this approach.

One way to mitigate this risk is to set up a dedicated account with the least privileges necessary to accomplish the task of clearing the failed MDM commands. This method does not eliminate the risk, but it may reduce it to one acceptable in your environment.

In my testing, the least privileges are the following:

In Jamf Pro Server Objects:

Computers: Read

In Jamf Pro Server Actions:

Flush MDM Commands

2. Set up a Jamf Pro computer policy with the following components:

Script: The script to clear failed MDM commands
Trigger: Recurring Check-In
Execution Frequency: Once every day

Note: Execution Frequency can be set as desired for a longer interval, like Once every week or Once every month.

The script is available from following address on GitHub:

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

As part of working with Jamf Pro, I prefer to be able to save as much of the existing configuration of it as possible. Normally I can do this via the Jamf Pro Classic API and I have a number of blog posts showing how I use the API to create backups of my Jamf Pro configuration.

However, one set of data which is not accessible via the API are the Self Service bookmarks.

If I want to back up this information, is there a way outside of the API? It turns out that there is. For more details, please see below the jump.

After some digging around, I discovered that the Self Service bookmarks are automatically downloaded from the Jamf Pro server and stored locally on each Mac in the following directory:

/Library/Application Support/JAMF/Self Service/Managed Plug-ins

In this directory, there are .plist files named with the Jamf Pro ID number of the relevant Self Service bookmark.

To make backups of the Self Service bookmarks, I’ve written a script which performs the following tasks:

1. If necessary, create a directory for storing backup copies of the Self Service bookmark files.
2. Make copies of the Self Service bookmark files.
3. Name the copied files using the title of the Self Service bookmark.
4. Store the copied bookmarks in the specified directory.

Once the script is run, you should see copies of the Self Service bookmark files appearing in the script-specified location.

This location can be set manually or created automatically by the script.

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_Self_Service_Bookmark_Backup

Jamf_Pro_Self_Service_Bookmark_Backup.sh:

The MacSysAdmin conference, like many conferences in 2020, has moved to an online format for this year. The MacSysAdmin 2020 organizers have also decided to have both sessions that are new for the 2020 conference as well as give an encore performance for sessions given at past MacSysAdmin conferences.

I was pleased to see that my “Getting Started with Amazon Web Services” session from MacSysAdmin 2018 made the cut for MacSysAdmin 2020. For those interested, my session will be available for viewing this Friday, October 9th.

One of the challenges for helpdesks with folks now working remotely instead of in offices has been that it’s now harder to gather logs from user’s Macs. A particular challenge for those folks working with AppleCare Enterprise Support has been with regards to requests for sysdiagnose logfiles.

The sysdiagnose tool is used for gathering a large amount of diagnostic files and logging, but the resulting output file is often a few hundred megabytes in size. This is usually too large to email, so alternate arrangements have to be made to get it off of the Mac in question and upload it to a location where the person needing the logs can retrieve them.

After needing to gather sysdiagnose files a few times, I’ve developed a scripted solution which does the following:

• Collects a sysdiagnose file.
• Creates a read-only compressed disk image containing the sysdiagnose file.
• Uploads the compressed disk image to a specified S3 bucket in Amazon Web Services.
• Cleans up the directories and files created by the script.

For more details, please see below the jump.

Pre-requisites

You will need to provide the following information to successfully upload the sysdiagnose file to an S3 bucket:

• S3 bucket name
• AWS region for the S3 bucket
• AWS programmatic user’s access key and secret access key
• The S3 ACL used on the bucket

The AWS programmatic user must have at minimum the following access rights to the specified S3 bucket:

• s3:ListBucket
• s3:PutObject
• s3:PutObjectAcl

The AWS programmatic user must have at minimum the following access rights to all S3 buckets in the account:

• s3:ListAllMyBuckets

These access rights will allow the AWS programmatic user the ability to do the following:

1. Identify the correct S3 bucket
2. Write the uploaded file to the S3 bucket

Note: The AWS programmatic user would not have the ability to read the contents of the S3 bucket.

Information on S3 ACLs can be found via the link below:
https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.htmlcanned-acl

In an S3 bucket’s default configuration, where all public access is blocked, the ACL should be the one listed below:

private

Using the script

Once you have the S3 bucket and AWS programmatic user set up, you will need to configure the user-editable variables in the script:

For example, if you set up the following S3 bucket and user access:

What: S3 bucket named sysdiagnose-log-s3-bucket
Where: AWS’s US-East-1 region
ACL configuration: Default ACL configuration with all public access blocked
AWS access key: AKIAX0FXU19HY2NLC3NF
AWS secret access key: YWRkX0FXU19zZWNyZXRfa2V5X2hlcmUK

The user-editable variables should look like this:

Note: The S3 bucket, access key and secret access key information shown above is no longer valid.

The script can be run manually or by a systems management tool. I’ve tested it with Jamf Pro and it appears to work without issue.

When run manually in Terminal, you should see the following output.

Once the script runs, you should see a disk image file appear in the S3 bucket with a name automatically generated using the following information:

Mac’s serial number – Mac’s hardware UUID – Year-Month-Day-Hour-Minute-Second

Once downloaded, the sysdiagnose file is accessible by mounting the disk image.

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

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

I’ve started working with Jamf Protect and, as part of that, I found that I needed to be able to report the following information about Jamf Protect to Jamf Pro:

1. Is the Jamf Protect agent installed on a particular Mac?
2. Is the Jamf Protect agent running on a particular Mac?
3. Which Jamf Protect server is a particular Mac handled by?

To address these needs, I’ve written three Jamf Pro extension attributes which display the requested information as part of a Mac’s inventory record in Jamf Pro. For more details, please see below the jump:

The three Extension Attributes do the following:

jamf_protect_installed.sh: Checks to see if Jamf Protect is installed and the agent is able to run.

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

jamf_protect_status.sh: Checks and validates the following:

• Jamf Protect is installed
• The Jamf Protect processes are running

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

jamf_protect_server.sh: Checks to see if Jamf Protect’s protectctl tool is installed on a particular Mac. If the protectctl tool is installed, check for and display the Jamf Protect tenant name.

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

Something that has (mostly) become more rare on the Mac platform are kernel panics, which are computer errors from which the operating system cannot safely recover without risking major data loss. Since a kernel panic means that the system has to halt or automatically reboot, this is a major inconvenience to the user of the computer.

Kernel panics are always the result of a software bug, either in Apple’s code or in the code of a third party’s kernel extension. Since they are always from bugs and they cause work interruptions, it’s a good idea to get on top of kernel panic issues as quickly as possible. To assist with this, a Jamf Pro Extension Attribute has been written to detect if a kernel panic has taken place. For more details, please see below the jump.

When a Mac has a kernel panic, the information from the panic is logged to a log file in /Library/Logs/DiagnosticReports. This log file will be named something similar to this:

Kernel-date-goes-here.panic

The Extension Attribute is based off an earlier example posted by Mike Morales on the Jamf Nation forums. It performs the following tasks:

1. Checks to see if there are any logs in the /Library/Logs/DiagnosticReports with a .panic file extension.
2. If there are, check to see which are from the past seven days.
3. Output a count of how many .panic logs were generated in the past seven days.

To test the Extension Attribute, it is possible to force a kernel panic on a Mac. To do this, please use the process shown below:

1. Disable System Integrity Protection
2. Run the following command with root privileges:

dtrace -w -n "BEGIN{ panic();}"

3. After the kernel panic, run a Jamf Pro inventory update.

After the inventory update, it should show that at least one kernel panic had occurred on that Mac. For more information about kernel panics, please see the link below:

https://developer.apple.com/library/content/technotes/tn2004/tn2118.html

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/kernel_panic_detection

Not yet ready for macOS Big Sur 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 Big Sur upgrade is via the Software Update preference pane:

You can block it from appearing using the softwareupdate –ignore command, but for macOS Catalina, Mojave and High Sierra, that command now requires one of the following enrollments as a pre-requisite:

• Apple Business Manager enrollment
• Apple School Manager enrollment
• Enrollment in a user-approved MDM

For more information on this, please reference the following KBase article: https://support.apple.com/HT210642 (search for the following: Major new releases of macOS can be hidden when using the softwareupdate(8) command).

For more details, please see below the jump.

Once that pre-requisite condition has been satisfied, run the following command with root privileges:

softwareupdate --ignore "macOS Big Sur"

You should see text appear which looks like this:

Ignored updates:
(
"macOS Big Sur"
)

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

Note: If the pre-requisite condition has not been fulfilled, running the softwareupdate –ignore command will have no effect.

With Apple now officially selling Apple Silicon Macs, there’s a design decision which Apple made with macOS Big Sur that may affect various Mac environments:

At this time, macOS Big Sur does not install Rosetta 2 by default on Apple Silicon Macs.

Rosetta 2 is Apple’s software solution for aiding in the transition from Macs running on Intel processors to Macs running on Apple Silicon processors. It allows most Intel apps to run on Apple Silicon without issues, which provides time for vendors to update their software to a Universal build which can run on both Intel and Apple Silicon.

Without Rosetta 2 installed, Intel apps do not run on Apple Silicon. So for those folks who need Rosetta 2, how to install it? For more details, please see below the jump.

You can install Rosetta 2 on Apple Silicon Macs using the softwareupdate command. To install Rosetta 2, run the following command with root privileges:

/usr/sbin/softwareupdate --install-rosetta

Installing this way will cause an interactive prompt to appear, asking you to agree to the Rosetta 2 license. If you want to perform a non-interactive install, please run the following command with root privileges to install Rosetta 2 and agree to the license in advance:

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Having the the non-interactive method for installing Rosetta 2 available makes it easier to script the installation process. My colleague Graham Gilbert has written a script for handling this process and discussed it here:

https://grahamgilbert.com/blog/2020/11/13/installing-rosetta-2-on-apple-silicon-macs/

I’ve written a similar script to Graham’s, which is available below and from the following address on GitHub:

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