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:

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

As Apple introduces its new Apple Silicon Macs, it’s important that Mac admins be able to identify if their environment’s software will be able to run natively on both Intel and Apple Silicon as Universal 2 apps or if they’ll need Apple’s Rosetta 2 translation service installed first on their Apple Silicon Macs to allow their apps to run.

To assist with this identification effort, Apple has provided two tools:

• file
• lipo

Both have been around for a while and initially helped identify the original Universal binaries, which were compiled to support both PowerPC and Intel processors. They’ve now been updated for this new processor transition and either will be able to identify if an app’s binary was compiled for the following:

• x86_64 (Intel)
• arm64 (Apple Silicon)
• Both x86_64 and arm64 (Universal 2)

For more details, please see below the jump.

To identify if an app is Intel-only or Universal using the lipo tool, please use the command shown below:

lipo -detailed_info /path/to/binary

For example, on macOS Catalina 10.15.7 Apple’s Safari browser is an Intel-only binary, since macOS Catalina won’t run on an Apple Silicon Mac. Running lipo on macOS Catalina 10.15.7’s Safari should produce output similar to what’s shown below:

username@computername ~ % lipo -detailed_info /Applications/Safari.app/Contents/MacOS/Safari
input file /Applications/Safari.app/Contents/MacOS/Safari is not a fat file
Non-fat file: /Applications/Safari.app/Contents/MacOS/Safari is architecture: x86_64
username@computername ~ %

Likewise, Jamf Pro 10.25.2’s jamf binary now supports both Intel and Apple Silicon. Running the lipo command described above should produce output similar to what’s shown below:

username@computername ~ % lipo -detailed_info /usr/local/jamf/bin/jamf
Fat header in: /usr/local/jamf/bin/jamf
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 6441136
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 6471680
size 6121168
align 2^14 (16384)
username@computername ~ %

To identify if an app is Intel-only or Universal using the file tool, please use the command shown below:

file /path/to/binary

Running the file command described above on macOS Catalina 10.15.7’s Safari should produce output similar to what’s shown below:

username@computername ~ % file /Applications/Safari.app/Contents/MacOS/Safari
/Applications/Safari.app/Contents/MacOS/Safari: Mach-O 64-bit executable x86_64
username@computername ~ %

Running the file command described above on the Jamf Pro 10.25.2 jamf binary should produce output similar to what’s shown below:

username@computername ~ % file /usr/local/jamf/bin/jamf
/usr/local/jamf/bin/jamf: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
/usr/local/jamf/bin/jamf (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/local/jamf/bin/jamf (for architecture arm64):	Mach-O 64-bit executable arm64
username@computername ~ %

For more information about app testing, Howard Oakley has a blog post discussing the lipo tool in more detail which I recommend checking out. I’ve linked to it below:

Magic, lipo and testing for Universal binaries:
https://eclecticlight.co/2020/07/24/magic-lipo-and-testing-for-universal-binaries/

I’ve started working with Amazon Web Service’s new macOS EC2 instances and after a while, I noticed that no matter how much EBS drive space I assigned to a EC2 instance running macOS, the instance would only have around 30 GBs of usable space. In this example, I had assigned around 200 GBs of EBS storage, but the APFS container was only using around 30 GBs of the available space.

After talking with AWS Support, there’s a fix for this using APFS container resizing. This is a topic I’ve discussed previously in the context of resizing boot drives for virtual machines. For more details, see below the jump.

To resize a macOS EC2 instance’s boot volume, you need to do two things:

1. Identify the appropriate APFS container:

APFS containers act as storage pools for APFS volumes. APFS volumes are what act as the mounted filesystem, where you store your files, directories, metadata, etc. When you grow the APFS container, the APFS volumes will likewise get additional space.

To identify the container for the instance’s boot volume, use the command shown below:

/usr/sbin/diskutil list physical external | awk '/Apple_APFS/ {print $7}'

2. Once the appropriate APFS container has been identified, use diskutil to resize the container with all available disk space.

You can specify a size of zero (0) to grow the targeted container using all unallocated drive space.

/usr/sbin/diskutil apfs resizeContainer apfs_container_id_goes_here 0

In this example, I have an instance where my APFS-formatted boot drive is using 32 GBs of space, but the instance has 200 GBs of available EBS disk space.

Assuming that the command above gave us disk1s2 as a result, the command shown below can be used to resize the boot drive’s APFS container with all available disk space.

/usr/sbin/diskutil apfs resizeContainer disk1s2 0

Once the container resizing has completed, the OS should now recognize and be able to use the now-allocated space.

This can be confirmed by other disk space measuring tools.

One of the outcomes of the recent Amazon Web Service’s Insight conference was AWS’s announcement that, as of November 30th, macOS EC2 instances were going to be available as on-demand instances or as part of one of AWS’s reduced cost plans for those who needed them long-term.

There are a few differences about AWS’s macOS offerings, as opposed to their Linux and Windows offerings. macOS EC2 instances are set up to run on actual Apple hardware, as opposed to being completely virtualized. This means that there are the following dependencies to be aware of:

1. macOS EC2 instances must run on dedicated hosts (AWS has stated these are Mac Minis)
2. One macOS EC2 instance can be provisioned per dedicated host.

AWS has also stipulated that that dedicated hosts for macOS EC2 instances have a minimum billing duration of 24 hours. That means that even if your dedicated host was only up and running for one hour, you will be billed as if it was running for 24 hours.

For now, only certain AWS regions have EC2 Mac instances available. As of December 20th, 2020, macOS EC2 instances are available in the following AWS Regions:

• US-East-1 (Northern Virginia)
• US-East-2 (Ohio)
• US-West-2 (Oregon)
• EU-West-1 (Ireland)
• AP-Southeast-1 (Singapore)

The macOS EC2 instances at this time support two versions of macOS:

• macOS Mojave
• macOS Catalina

macOS Big Sur is not yet supported as of December 20th, 2020, but AWS has stated that Big Sur support will be coming shortly.

By default, macOS EC2 instances will include the following pre-installed software:

• ENA drivers
• EC2 macOS Init
• EC2 System Monitoring for macOS
• Systems Manager SSM Agent for macOS
• AWS Command Line Interface (AWS CLI) version 2
• Xcode Command Line Tools
• Homebrew

For folks looking to build services or do continuous integration testing on macOS, it’s clear that AWS went to considerable lengths to have macOS EC2 instances be as fully-featured as their other EC2 offerings. Amazon has also either made it possible to install the tools you need or just went ahead and installed them for you. They’ve also included drivers for their faster networking options and made it possible to manage and monitor Mac EC2 instances using AWS’s tools just like their Linux and Windows EC2 instances.

That said, all of this comes with a price tag. Here’s how it works out (all figures expressed in US dollars):

mac1 Dedicated Hosts (on-demand pricing):

$1.083/hour (currently with a 24 hour minimum charge, after which billing is by the second.)
$25.99/day
$181.93/week
$9493.58/year

Now, you can sign up for an AWS Savings Plan and save some money by paying up-front for one year or three years. Paying for three years, all cash up front is the cheapest option currently available:

$0.764/hour
$18.33/day
$128.31/week
$6697.22/year

Now some folks are going to look at that and have a heart attack, while others are going to shrug because the money involved amounts to a rounding error on their existing AWS bill. I’m mainly going through this to point out that hosting Mac services on AWS is going to come with costs. None of AWS’s existing Mac offerings are part of AWS’s Free Tier.

OK, so we’ve discussed a lot of the background but let’s get to the point: How do you set up AutoPkg to run in the AWS cloud? For more details, please see below the jump.

If you’ve worked with Amazon Web Service’s EC2 service previously, getting AutoPkg up and running in AWS should be fairly straightforward. That said, if you haven’t worked with either AWS or EC2 before, there may be a bit of a learning curve. For folks in this situation, I gave a talk on Amazon Web Services which should help get you started:

Getting Started with Amazon Web Services: http://docs.macsysadmin.se/2018/video/Day4Session4.mp4

In this example, I’m going to setting up a macOS EC2 instance with the following:

• git
• AutoPkg
• AutoPkgr
• JSSImporter

Pre-requisites:

• An Amazon Web Services account
• Money (at least $25.99)

Setting up a dedicated host

To run a macOS instance in EC2, you need to first choose an actual Mac Mini to run that instance on. Amazon refers to this as a dedicated host and the process looks like this:

1. Open the Amazon EC2 web console at https://console.aws.amazon.com/ec2/.

2. In the navigation pane, choose Dedicated Hosts.

3. Choose Allocate Dedicated Host and then do the following:

For Name Tag:, give it an appropriate name.

For Instance family, choose mac1.

For Support multiple instance types, uncheck the Enable checkbox.

For Instance type, select mac1.metal.

For Availability Zone, choose the Availability Zone for the Dedicated Host. (For this example, I’m in US-East-2 and I’m choosing us-east-2b.)

For Instance auto-placement, do not check anything.
For Host recovery, do not check anything.
For Quantity, keep 1.

Click the Allocate button. (This is the part where Amazon charges you $25.99)

At this point, the Dedicated Host should be created.

Setting up a macOS EC2 instance

If you haven’t previously done so, set up an AWS SSH key pair for use with EC2 instances:

https://docs.aws.amazon.com/cli/latest/userguide/cli-services-ec2-keypairs.html

Once your keypair has been created, select the Dedicated Host that you created and then do the following:

Choose Actions, Launch instances onto host.

Select a macOS AMI. For this example, I’m selecting macOS Catalina 10.15.7.

Select the mac1.metal instance type.

Click the Next: Configure Instance Details button.

On the Configure Instance Details page, verify the following:

Tenancy: Set as dedicated host.

Host is set as the Dedicated Host you created.

Update Affinity as needed. Mine is set to Off.

In User Data, I have a script that the Mac EC2 instance can run at boot.

This user data script does the following:

Configures Mac EC2 instance with the following:

• Account password for the default ec2-user account
• Set the Mac to auto-login as the default ec2-user account
• git
• AutoPkg
• AutoPkgr
• JSSImporter

Once these tools and modules are installed, the script configures AutoPkg to use the recipe repos defined in the AutoPkg repos section.

If you want to use this user data script, it’s available from the following address on GitHub:

https://github.com/rtrouton/aws_scripts/tree/master/setup_mac_ec2_instance_for_autopkg

Before adding the user data script to the instance build process, check the variables in the script and verify that they are set up the way you want. There is also an upper limit of 15K in size for this script.

From there, either copy and paste the script into the available user data blank or select the user data script as a file.

Double-check your Tenancy, Host and User Data settings to make sure everything is set as desired, then click the Next: Add Storage button.

Set how much storage you want. For this example, I’m setting it at 60 GBs of storage.

Note: Depending on how many AutoPkg recipes you’re running and the size of the installers, you may want to double or even triple the amount of storage I’m setting. Another thing to be aware of is that, the instance’s boot volume will need to be resized to recognize the additional space. If using the user data script linked above, boot volume resizing is included as part of the script’s run.

Once storage is set, click the Next:Add Tags button.

Set tags as desired, then click the Next: Security Group button.

Choose the options to set a security group as desired.

If you don’t have a security group available, I recommend creating one and setting it to allow SSH from only your IP address, then click the Review and Launch button.

Review your instance’s settings and make sure everything is OK. Once you’re sure, click the Launch button.

When prompted, select your SSH keypair, then click the Launch instances button.

Your Mac instance will now launch on the dedicated host. To see if it in the Instances list, click the View instances on host button.

To find out its public DNS address and other useful information, click on the instance ID.

Wait about fifteen minutes for your instance to finish setting itself up. After that you should be able to connect to it via SSH and (assuming you configured the right variables for VNC access) also via remote screen sharing.

Connecting to the macOS EC2 instance following setup

Following setup, you can connect to the newly-built EC2 instance via SSH. To do so, open Terminal and use the following SSH command:

ssh -i /path/my-key-pair.pem ec2-user@my-instance-public-dns-name

For example, if your SSH keypair was stored in ~/.ssh and named AutoPkg_SSH_Keypair.pem, you would use the following command to connect to a macOS EC2 instance whose address is ec2-3-23-97-197.us-east-2.compute.amazonaws.com:

ssh -i ~/.ssh/AutoPkg_SSH_Keypair.pem ec2-user@ec2-3-23-97-197.us-east-2.compute.amazonaws.com

No password is needed in this case, as you are using your SSH keypair to authenticate the SSH session.

To connect via VNC, I recommend setting up VNC to run over an SSH tunnel. The reason for this is that VNC by default does not encrypt its traffic so all network communication between you and the instance (including any passwords) would be sent in the clear. Using an SSH tunnel will allow you to wrap this unencrypted traffic inside SSH’s encryption, which should secure it against third parties.

To set up VNC to run inside an SSH tunnel, you will need to first set up a password for the ec2-user account if you haven’t done so already. You can do this by connecting to the instance via SSH and running the following passwd command:

sudo passwd ec2-user

Once the command has been run, follow the prompts to change the password. Once the password is set up, run the following SSH command on your end:

ssh -L 5900:localhost:5900 -i /path/my-key-pair.pem ec2-user@my-instance-public-dns-name

For example, if your SSH keypair was stored in ~/.ssh on your Mac and named AutoPkg_SSH_Keypair.pem, you would use the following command to set up an SSH tunnel for VNC between your Mac and a macOS EC2 instance whose address is ec2-3-23-97-197.us-east-2.compute.amazonaws.com:

ssh -L 5900:localhost:5900 -i ~/.ssh/AutoPkg_SSH_Keypair.pem ec2-user@ec2-3-23-97-197.us-east-2.compute.amazonaws.com

Once that’s done, do the following:

1. Under the Go menu, select Connect to Server.
2. In the Connect to Server window, enter the following:

vnc://localhost:5900

When prompted, use the following username and password:

Username: ec2-user
Password: Whatever password you defined in the script for the ec2-user account to use.

Once connected, you’ll be able to work with the Mac instance like you would any other remotely-accessible Mac.

In the case of a AutoPkg server built using the user data script I linked to above, you could open AutoPkgr and start setting up your recipes to begin scheduled runs.

After 24 years and 1078 known security vulnerabilities, Adobe Flash has reached end of life status as of December 31, 2020.

To assist with the process of removing Adobe Flash, I’ve written an uninstall script which will completely remove Adobe Flash. For more details, please see below the jump.

This script is designed to uninstall the Adobe Flash plug-ins and their associated components. As part of this, it runs the following actions:

1. Stop Adobe Flash Install Manager
2. If running, unload the launchdaemon used by the Adobe Flash update process.
3. Remove the Adobe Flash plug-ins, Adobe Flash Install Manager and their associated components.
4. Remove Adobe Flash preference pane settings at the user level.
5. Forget the installer package receipts.

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

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/uninstallers/adobe_flash_uninstall

As new Apple Silicon Macs (ASM) have begun making their way to organizations which use FileVault encryption to secure their fleets, a difference between Intel Macs and ASMs has become apparent.

Intel Macs:

• Supports account icons and password blanks at the FileVault login screen
• Unable to support username blanks at the FileVault login screen
• Unable to support smart cards for login at the FileVault login screen

ASMs:

• Supports account icons and password blanks at the FileVault login screen
• Supports username and password blanks at the FileVault login screen
• Supports smart cards for login at the FileVault login screen

Why the differences between platforms? For more details, please see below the jump.

Intel Macs

On Intel Macs, Apple is dependent on using the EFI login environment for the FileVault 2 login screen. This is a very limited environment in terms of functionality and is used in the FileVault 2 context to provide a way to boot the Mac while the main boot volume is locked by FileVault’s encryption. Once EFI has booted the Mac, the Mac then uses authentication from the user and the tools stored on the not-encrypted Preboot volume to unlock the much-larger encrypted boot volume.

EFI’s limitations mean that only a password blank is truly supported, with Apple having pushed the limits to support correctly matching up multiple account icons with the corresponding multiple account passwords.

Apple Silicon Macs

On ASMs, there is now a unified macOS login experience which includes FileVault logins. For details on this, I recommend checking out the Explore the new system architecture of Apple Silicon Macs session video from WWDC 2020. The explanation is available starting around 20:14.

On Apple Silicon Macs, macOS has a unified log-in experience. It supports a richer UI with accelerated graphics that is also consistent with macOS look and feel. This experience is made possible by fully booting macOS without requiring the user to unlock the system.

The unified log-in experience allows the introduction of new features even when FileVault is on. For example, it now has built-in support for authentication with CCID and PIV-compatible smart cards, as well as VoiceOver support for accessibility improvements.

In summary, the reason the FileVault login screen is different on ASMs is that Apple no longer needs to use the EFI login environment. Instead, ASMs are able to fully boot macOS while still securing user data within a locked volume which is protected by FileVault.

This is a huge leap forward for ASMs in terms of FileVault login functionality, as there is no longer a login functionality divide between enabling FileVault and not enabling FileVault. As of macOS Big Sur and the M1 ASMs, FileVault logins should now be able to use whichever authentication methods are supported by macOS. More importantly for the future, as native support for new authentication methods are added to the OS, FileVault logins should be able to use them natively as well.

One of the changes in macOS Big Sur is that the softwareupdate command has been updated with new functionality.

Among the changes is the ability to scan Apple’s Software Update feed and display a list of the currently available full OS installers. To access this list, run the command below with root privileges:

softwareupdate --list-full-installers

The list you receive will be dependent on whether or not your Mac can run a particular OS version. As an example, here’s the list you would receive inside of a VMware VM as of March 3rd, 2021.

Once you have the right macOS installer identified, you can use the softwareupdate tool to download it.

One thing to be aware of is that multiple versions of a macOS full installer may show up in the Software Update feed. As an example of this, the list above includes multiple entries for macOS 10.15.6 and 10.15.7. These installers would be for hardware-specific builds of that macOS version’s full installer. Unfortunately, it’s not easy to tell the various installers apart using the softwareupdate command because the build number is not included.

If you do need to be able to download an installer with a specific build number, I recommend using the installinstallmacos.py tool. This tool also references the Apple Software Update feed, so the information you get back should be similar but also include the relevant build numbers for the macOS full installers.

As part of the release notes for Jamf Pro 10.28, there is this note in the Deprecations and Removals section:

Support ending for the Jamf Pro Server Installer for macOS — Support for using the Jamf Pro Installer for macOS will be discontinued in a future release. Mac computers with Apple silicon are not supported by the Jamf Pro Installer for macOS. If you want to migrate your Jamf Pro server from macOS to Jamf Cloud, contact Jamf Support. If you want to keep your server on premise, you can migrate your Jamf Pro server from macOS to one of the following servers: Red Hat Enterprise Linux, Ubuntu, or Windows. For more information, see the Migrating to Another Server Knowledge Base article.

For those folks who are running on-premise Jamf Pro servers on Macs, it looks like it’s time to contact Jamf Support and plan a migration if you haven’t already. As of March 17th, 2021, Jamf’s published support for running Jamf Pro includes the following OS, database and Java versions:

For those using Jamf Pro’s Self Service, one of the handier features can be the Search function built into the app. This search is able to examine Self Service policies and use the information in the policy and Self Service description to populate its search results. For the most part, just the displayed information in the policy should allow Self Service’s search to display relevant policies.

However, you may have a need to force the search process to include policies that would otherwise fall outside of the search parameters. For those who need this ability, thanks to Self Service’s support of Markdown it’s possible to invisibly add search keywords to a Self Service policy description. For more details, please see below the jump.

Markdown is a markup language which uses specific syntax to produce formatted text. In the image below, the left side shows what appears in the Markdown editor and the right side shows how the formatted document would appear.

Among the syntax options is the ability to add comments using the HTML comment tag. These show up in the Markdown editor, but they don’t show up in the displayed document.

Since Self Service descriptions only display the formatted text, but the search function can search everything in the description, we can use the comment syntax to add search keywords which Self Service’s search can use but which are invisible to someone looking at the Self Service description via the Self Service app.

To add search keywords, add the syntax tags for Markdown commenting to your Self Service description and add the search keywords you want to use within the tags. An example is shown below:

<!-- Search Keywords Go Here -->

For example, if you wanted to add search keywords like Java and JDK to a Java install policy, you could add the following to your Self Service description:

<!--Java, JDK-->

Even if the displayed text in the policy or the Self Service description never mentions either Java or JDK, Self Service’s search will include this policy when you search for those terms.

Here’s another example, using Backup as a search keyword:

<!--Backup-->

Note: Self Service’s search is case-insensitive so searching for backup or BACKUP when you have Backup as the search keyword should also display the relevant policy or policies.

I’ve recently been working with Twocanoes Software’s Signing Manager in combination with my autopkg-conductor tool for managing AutoPkg runs. I’m happy to report it’s possible, but you may need to make some adjustments to how autopkg-conductor is being launched. For more details, please see below the jump.

As originally written, autopkg-conductor uses a LaunchDaemon to manage when the autopkg-conductor script is run. This was an idea I adopted from AutoPkgr, which also uses a LaunchDaemon to perform AutoPkg runs. The reason for using a LaunchDaemon is that the LaunchDaemon will be able to perform the scheduled AutoPkg run regardless of if the Mac is logged in at the loginwindow or not.

For the most part, this works fine to successfully trigger the autopkg-conductor script. However, a problem occurred once Signing Manager was added to the mix and I tried using it with the PkgSigner AutoPkg processor. The reason for this is that Signing Manager puts credentials into the login keychain and the user context was not correct to access those credentials. Instead, I was seeing errors like this when the LaunchDaemon triggered a run of autopkg-conductor:

After Twocanoes Support did some research, they recommended adding the following key to autopkg-conductor‘s LaunchDaemon:

Key: SessionCreate
Value: true

My LaunchDaemon now looked like this:

With renewed hope, I used the LaunchDaemon to trigger a run. Same errors:

This was clearly a case of context. I was running as the right user, but something about the session context wasn’t quite right to allow me access to the login keychain and access the Signing Manager credential.

After some additional research, Twocanoes Support recommended the following:

1. Have the user account be logged in at the login window (as opposed to running logged out.)
2. Replace the LaunchDaemon with a LaunchAgent.

I then unloaded the LaunchDaemon and replaced it with a practically identical LaunchAgent, with the two following keys removed:

Key: UserName
Value: Account which I was running AutoPkg from (in this case, the user account was named autopkg)

Key: SessionCreate
Value: true

The LaunchAgent appeared as shown below:

To test it out, I changed the following value in the LaunchAgent:

Key: RunAtLoad

From: false
To: true

After making that change, I logged out, logged in and * bang * my AutoPkg runs started being able to access the signing identity provided by Signing Manager and sign my packages using the PkgSigner AutoPkg processor.

Once my testing was completed, I changed the RunAtLoad key’s value back to false.

Transitioning from a LaunchDaemon to a LaunchAgent does mean I will need to leave the account I’m using for AutoPkg logged in at the login window, which has security implications to consider carefully.

In my particular case, AutoPkg is being run on a virtual machine where there is not a physical display attached and access to screen sharing is restricted, so for my particular case my opinion is that the trade-off is worth it.

With regards to Signing Manager’s operation, I also had some additional questions about it with regards to my AutoPkg runs which got answered during testing:

• Question: Does the Signing Manager app need to be launched, or will productsign (used by the AutoPkg PkgSigner processor) be able to get the certificate without the app being launched?
• Answer: After configuring Signing Manager, there’s no need to launch the app. As long as productsign is given the right signing identity (which Signing Manager refers to as a “fingerprint”), signing will work.

• Question: If you need to reboot your Mac, do you need to do anything following the reboot in order to having signing work?
• Answer: No

As part of introducing macOS High Sierra, Apple removed the telnet tool from macOS. This was part of Apple’s overall effort to improve security, as telnet does not use encryption and its traffic can be intercepted and read. However, telnet did (and does) serve a useful function as a quick way to check if it is possible to connect to a remote server on a particular port.

While there are alternative tools available for this task (like netcat), it’s also possible to still create a telnet connection on macOS using another tool: curl

For more details, please see below the jump.

You can use curl to create a telnet connection using a command similar to the one shown below:

curl -v telnet://ip.address.here:port.number.here

Note: You can also use a DNS address in place of ip.address.here.

For example, if you want to check if https://www.yahoo.com is responding on port 443, use the curl command shown below:

curl -v telnet://www.yahoo.com:443

You should see output similar to that shown below:

username@computername ~ % curl -v telnet://www.yahoo.com:443
* Trying 74.6.143.26...
* TCP_NODELAY set
* Connected to www.yahoo.com (74.6.143.26) port 443 (#0)
^C
username@computername ~ %

Note: Once successfully connected, use Control+C to break the telnet connection.

If the port is not open, you should see different output. For example, if you want to check if http://www.yahoo.com is responding on port 444, use the curl command shown below:

curl -v telnet://www.yahoo.com:444

Port 444 is not open, so you should see output similar to that shown below:

username@computername ~ % curl -v telnet://www.yahoo.com:444
* Trying 74.6.143.26...
* TCP_NODELAY set
* connect to 74.6.143.26 port 444 failed: Connection refused
* Trying 74.6.143.25...
* TCP_NODELAY set
* connect to 74.6.143.25 port 444 failed: Connection refused
* Failed to connect to www.yahoo.com port 444: Connection refused
* Closing connection 0
curl: (7) Failed to connect to www.yahoo.com port 444: Connection refused
username@computername ~ %

Most Mac admins have had this conversation at one point or another over the course of their careers:

“$Very Important Person left their Mac behind in a cab! What do we do?”
“OK, no worries. We can send a command to lock the computer or have it erase itself. Do you want it locked or wiped?”

At that point, the admin pulls up their MDM admin console and depending on what the response was (lock or wipe), send out the appropriate MDM command accompanied by a PIN code. Once received, the Mac will then turn itself into a paperweight which does or doesn’t erase itself.

Doing these one at a time is a pretty straightforward process. For example, here’s how it looks in Jamf Pro to send a device lock command via MDM:

1. Log into Jamf Pro using an account which can send lock commands via MDM.
2. Go to the appropriate computer inventory record.

3. Select the Management tab.

4. In the Management Commands section of the Management tab, click the Lock Computer button.

5. Enter the PIN code which will later be used to unlock the Mac. If desired, you can also enter a message which will appear on the lock screen.

6. Click the Lock Computer button.

7. Click the OK button in the confirmation window.

Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.

For a small number of machines (10 or less), the method outlined above works fine. But once you get beyond that number, this process gets time-consuming and unwieldy. Fortunately, there is also a way to use the Jamf Pro Classic API to send device lock commands. For more details, please see below the jump.

Pre-requisites:

If setting up a specific Jamf Pro user account for this purpose with limited rights, here are the required API privileges for the account on the Jamf Pro server:

Jamf Pro Server Objects:

Computers: Create

Jamf Pro Server Action:

Send Computer Remote Lock Command

Once you have your Jamf Pro account credentials handled, you can use an API command similar to the one shown below to send a device lock command (referred to in Apple’s MDM documentation as DeviceLock.)

/usr/bin/curl -su username_here:password_here https://jamf.pro.server.address.here:port_here/JSSResource/computercommands/command/DeviceLock/passcode/PIN_code_goes_here/id/Jamf_Pro_Computer_ID_goes_here -H "Content-Type: application/xml" -X POST

For example, here’s the command used to lock a Jamf Pro-enrolled Mac with the following Jamf Pro server, Jamf Pro account with the necessary privileges, Jamf Pro computer ID and desired PIN code.

• Jamf Pro server: https://jamfpro.company.com:8443
• Jamf Pro username: mdmlock
• Jamf Pro password: correct_horse_Battery_Staple
• Jamf Pro Computer ID: 9345
• PIN code: 123456

/usr/bin/curl -su mdmlock:correct_horse_Battery_Staple https://jamfpro.company.com:8443/JSSResource/computercommands/command/DeviceLock/passcode/123456/id/9345 -H "Content-Type: application/xml" -X POST

Note: Using the API to send lock commands does have a limitation, where it is not possible to include a message to appear on the lock screen. If a message must appear on the lock screen, I recommend using the method described earlier for sending lock commands from the computer inventory record in the Jamf Pro admin console.

To help make the task of sending MDM lock commands easier, I’ve written a script which uses the API command above to read input from a .csv file and use that information to send device lock commands to multiple Macs. This script reads a .csv file formatted as follows:

“Jamf Pro ID, PIN Code” as the first line

Subsequent lines:
Column 1: A Mac’s Jamf Pro ID
Column 2: Device Lock PIN code

For authentication, the script can accept 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

Once you have authentication handled, the script is designed to run as shown below:

/path/to/Jamf_Pro_MDM_Device_Lock.sh /path/to/filename_goes_here.csv

Once executed, the script will then do the following:

1. Skip the first line of the .csv file (this is the “Jamf Pro ID, PIN Code” line.)
2. Read each subsequent line of the .csv one at a time and assign the values of column 1 and column 2 to separate variables.
3. Use the variables in an API POST call to identify a Jamf Pro computer inventory record using the Jamf Pro ID listed in the .csv file and lock the Mac in question using the PIN code listed in the .csv file.

A successful MDM lock should produce output similar to that shown below:

Failures should look similar to this:

Attempting to send MDM lock to Jamf Pro ID 1234567890 with PIN code 348201.

ERROR! MDM lock of computer with Jamf Pro ID 1234567890 failed.

Attempting to send MDM lock to Jamf Pro ID 29352935 with PIN code 12345.

Invalid PIN code data provided: 12345

Attempting to send MDM lock to Jamf Pro ID AA2319 with PIN code 348206.

Invalid Jamf Pro ID data provided: AA2319

This script is available below and also from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_MDM_Device_Lock

Previously, I’d written a script to manage sending device lock commands using the Jamf Pro Classic API. After writing it, I thought that it would be a good idea if the script could also generate a report that could be handed off to others so I forked the script and updated it to generate a report in .tsv format. Since others might prefer the original script without the automatically generated report, I left that one alone and have made the forked copy into its own script. For more details, please see below the jump.

Pre-requisites:

If setting up a specific Jamf Pro user account for this purpose with limited rights, here are the required API privileges for the account on the Jamf Pro server:

Jamf Pro Server Objects:

Computers: Create, Read

Jamf Pro Server Action:

Send Computer Remote Lock Command

This script reads a .csv file formatted as follows:

“Jamf Pro ID, PIN Code” as the first line

Subsequent lines:
Column 1: A Mac’s Jamf Pro ID
Column 2: Device Lock PIN code

For authentication, the script can accept 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

Once you have authentication handled, the script is designed to run as shown below:

/path/to/Jamf_Pro_MDM_Device_Lock.sh /path/to/filename_goes_here.csv

Once executed, the script will then do the following:

Skip the first line of the .csv file (this is the “Jamf Pro ID, PIN Code” line.)
Read each subsequent line of the .csv one at a time and assign the values of column 1
and column 2 to separate variables.

Use the variables in an API POST call to identify a Jamf Pro computer inventory record using the Jamf Pro ID listed in the .csv file and lock the Mac in question using the the PIN code listed in the .csv file.

A successful MDM lock should produce output similar to that shown below:

Failures should look similar to this:

Attempting to send MDM lock to Jamf Pro ID 1234567890 with PIN code 348201.

ERROR! MDM lock of computer with Jamf Pro ID 1234567890 failed.

Attempting to send MDM lock to Jamf Pro ID 29352935 with PIN code 12345.

Invalid PIN code data provided: 12345

Attempting to send MDM lock to Jamf Pro ID AA2319 with PIN code 348206.

Invalid Jamf Pro ID data provided: AA2319

This script will also automatically generate a report in .tsv format with information similar to what’s shown below:

This script is available below and also from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_MDM_Device_Lock_with_Report