I recently needed to prune some Time Machine backups, where I wanted to manually delete some older backups while not deleting everything on the drive. When I researched this, the guidance provided used the procedure described below:

1. Connect your external backup drive to your Mac if needed.
2. Launch the Time Machine app.
3. Use the timeline on the right of the screen or the arrows to navigate to the backup date you want to delete. Alternatively, use the Finder window to navigate to the file or folder you want to delete.
4. After selecting the date or file you want to delete, click the Action (…) button in Finder and choose to either Delete Backup or Delete All Backups of [Your File]

For an HFS+ formatted Time Machine backup drive, this guidance is correct. However, my Time Machine backup drive is APFS formatted. When following this guidance, I ran into the following issue:

1. Connect your external backup drive to your Mac if needed.
2. Launch the Time Machine app.
3. Use the timeline on the right of the screen or the arrows to navigate to the backup date you want to delete. Alternatively, use the Finder window to navigate to the file or folder you want to delete.
4. After selecting the date or file you want to delete, click the Action (…) button in Finder.

With APFS-formatted Time Machine backup drives, only the option to restore files is available. The Delete Backup or Delete All Backups options are not available.

So how can unwanted Time Machine backups be manually deleted? For more details, please see below the jump.

You can remove unwanted backups using either the Finder, or by using the tmutil command line tool.

To remove unwanted backups using the Finder, use the procedure described below:

1. Connect your external backup drive to your Mac if needed.
2. Open a new Finder window and select the backup drive.

You should see your backups listed in the Finder window.

3. Select the backup you want to delete and click the Action (…) button in Finder.

Note: You can also control-click on the desired backup to access the same options.

4. Select the Delete Immediately… option.

5. When prompted to confirm, click the Delete button.

Once confirmed, the backup should be deleted and disappear from the Finder window.

To remove unwanted backups using the tmutil command line tool, use the procedure described below:

1. Connect your external backup drive to your Mac if needed.

2. Open a Terminal window and run the following command:

tmutil listbackups

Note: You may be prompted to grant full disk access to the Terminal in order to run this command.

3. Identify the backup you want to delete. For this example, we’re using the following backup:

2022-07-01-154751.backup

To delete the backup using the tmutil command line tool, you need two items of information:

1. The path to the drive it is stored on.
2. The time stamp of the backup.

The path to the drive is going to depend on what the drive is named. In this example, the name of the drive is Backup so the path name should be as shown below:

/Volumes/Backup

The time stamp of the backup is going to be the name of the backup prior to the .backup part of the name. In this example, the backup is named 2022-07-01-154751.backup so the time stamp should be as shown below:

2022-07-01-154751

4. Once you have the path and time stamp, run the command shown below with root privileges to delete the backup:

tmutil delete -d /path/to/backup/drive -t timestamp_of_backup

You’ll need to provide the path and time stamp information using tmutil‘s -d flag for the path and the -t flag for the time stamp. For our example, where the path is /Volumes/Backup and the time stamp is 2022-07-01-154751, you would run the command shown below with root privileges to delete the backup:

tmutil delete -d /Volumes/Backup -t 2022-07-01-154751

The specified backup should be deleted.

5. Run the command shown below to verify that the backup has been removed:

tmutil listbackups

This post is focused on using Time Machine’s own tools to manage Time Machine backups, but you can also access and delete Time Machine APFS snapshots using Disk Utility on macOS Monterey. For more information on this, please see Howard Oakley‘s post linked below:

https://eclecticlight.co/2021/11/09/disk-utility-now-has-full-features-for-managing-snapshots/

As part of writing documentation today, I was given a script to follow when making some videos as part of the documentation process. The script included the following requirement:

• Prepare the Terminal to not show the hostname or the logged-in user

By default, Terminal in macOS Monterey will show both. How to get rid of this?

Fortunately for me, @scriptingosx had already documented how to do this as part of this post. You can use the PS1 environmental variable to set how your prompt appears in Terminal. After some experimentation, I set the following environmental variable:

PS1="\$ "

To have this prompt appear whenever I opened a new Terminal session, I added the following line to a newly-created .zshrc file in my home folder:

export PS1="\$ "

The .zshrc file is a configuration file for the zsh shell, so adding that and then opening a new Terminal window gave me a prompt which looks like this.

As part of making the videos, I also noticed that when I copied and pasted a command into the Terminal that the pasted text was highlighted automatically. I’d seen this before and ignored it, but I thought it might be an unnecessary distraction for those watching this video later, so I went looking for how to disable it.

After some research, I found that this was zsh’s “bracketed paste” feature, which was introduced as part of zsh 5.1. This feature can be turned off using the following command:

unset zle_bracketed_paste

Adding entries for both the prompt and turning off bracketed paste to my .zshrc file gave me the Terminal behavior I wanted:

export PS1="\$ "
unset zle_bracketed_paste

I also performed additional customization of my Terminal experience, but those modifications were managed using a configuration profile. For more details on that, please see this previous post:

https://derflounder.wordpress.com/2019/12/19/deploying-terminal-profile-settings-using-macos-configuration-profiles/

As a follow-up to a previous post, as part of that post I had been running certain shell commands by adding them to a .zshrc file:

• export PS1=”\$ “: Sets the prompt to only display “$” (no quotes) using the PS1 environmental variable.
• unset zle_bracketed_paste: Disable the zsh shell’s bracketed paste feature.

With some additional research, I learned that I could also run these commands using the Run command function which is available in your Terminal settings under the Shell tab.

To replicate what I wanted, I had to enable the Run command option in the Shell tab, then also set Run inside shell. Once those were enabled, I added the following shell commands:

export PS1="\$ " && unset zle_bracketed_paste && clear

• export PS1=”\$ “: Sets the prompt to only display “$” (no quotes) using the PS1 environmental variable.
• unset zle_bracketed_paste: Disable the zsh shell’s bracketed paste feature.
• clear: Removes all contents (including running the commands listed above) from the Terminal window.

The reason why this is nice is that I can now add running these commands to a macOS configuration profile using the CommandString key:

To see this used in context in a macOS configuration profile, please see below the jump.

The following profile sets the following settings:

• Font: Monaco 18 point size

Additional settings:

• Terminal prompt should not show the hostname or the logged-in user.
• Zsh’s bracketed paste feature is disabled

Privileges is an open source tool from SAP which helps folks manage admin rights for their account. As part of its feature set, it includes an option for time-limited admin using a specific function called Toggle privileges.

However, Toggle privileges’s time-limited admin feature for Privileges is its most misunderstood feature. The reason is that while the ability to set a time limit is only available if you’re using the Toggle privileges function, many users assume that this time-limited admin is available universally to all the functions used to get admin rights using the Privileges app.

It is not. Time limited admin is only available using the Toggle privileges function. If you’re not using the Toggle privileges function, there is no time limitation and you cannot set one from within the Privileges app.

This information is available in the Privileges FAQ:

• Question: By default, is there a time limit on the admin rights granted by Privileges?
• Answer: No. Admin rights are granted until some process (like running Privileges again) takes them away.

• Question: Can I set Privileges to give me administrator rights for a defined amount of time?
• Answer: Yes. You can use the Toggle Privileges option on the dock icon to get admin rights for a set amount of time (the default amount is 20 minutes.)

What does this mean?

1. The only way time-limited admin is currently working on Privileges is by using the Toggle privileges function.
2. If you are clicking on the icon in the dock and not selecting the Toggle privileges function, there’s no time limit.
3. If you’re using the PrivilegesCLI command line tool, there is no time limit.

How long do you have admin if you’re not using the Toggle privileges function? Admin rights are granted until some process (like running Privileges again) takes them away. There’s no time limit.

All of the Privileges management options available for time-limited admin at this time apply only to the Toggle privileges function. If you’re using any of the management settings options listed below, they apply only and exclusively to the Toggle privileges function:

• DockToggleTimeout
• DockToggleMaxTimeout

They will not manage time-limited admin for any of Privileges’ functions outside of using the Toggle privileges function.

What if you want time-limited admin outside of using the Toggle privileges function? You will need to use a separate mechanism. In my case, I usually point folks towards using PrivilegesDemoter:

https://github.com/sgmills/PrivilegesDemoter

This tool uses a separate mechanism for figuring out the timing and then uses the PrivilegesCLI command line tool to take away admin when the time limit set for PrivilegesDemoter expires.

One of the features of Microsoft Defender for macOS is tamper protection. This option is designed to prevent Defender or its settings from being removed or changed.

As of posting date, Defender’s tamper protection has three associated topics:

• Disabled: Tamper protection is completely off.
• Audit: Tampering operations are logged, but not blocked.
• Blocked: Tamper protection is on, tampering operations are blocked.

Microsoft has documentation regarding Defender’s tamper protection for macOS, available via the link below:

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/tamperprotection-macos

For more details, please see below the jump.

You can manage tamper protection via running commands via the command line, or via management profiles. The commands shown below allow tamper protection to be disabled completely, set to audit mode, or set to full tamper protection where Defender or its settings can’t be removed or changed.

To disable tamper protection, run the following command with root privileges:

To set tamper protection to audit mode, run the following command with root privileges:

To set tamper protection to full tamper protection mode, run the following command with root privileges:

If management via profiles is desired, the example profiles below will set Defender to audit mode or to full tamper protection.

Audit mode:

Full tamper protection:

To check the current Defender configuration, the following command can be run:

That should return output which looks similar to what’s shown below:

To check specifically for the tamper protection configuration, the following command can be run to check its status:

You should see the following output depending on the configuration:

Tamper protection disabled:

Tamper protection set to audit mode:

Tamper protection set to full tamper protection:

For folks with uninstall scripts for Microsoft Defender, they won’t be able to successfully uninstall Defender or its settings with tamper protection enabled. One way to address this is to add a section at the beginning of the uninstall script which can detect if full tamper protection is enabled and stop the script if it is. An example of this is shown below:

If full tamper protection is enabled, this example script will take the following actions:

1. Display the following message using osascript.

2. Exit after displaying the message.

Following an upgrade to Jamf Pro 10.41.0, you may notice that you have an alert showing in the Jamf Pro admin console.

When you click on the alert, you will see the following alert notification.

Verification of SSL certificates is disabled.

There will be a link to enable SSL certificate verification.

If you click that link, it’ll take you to Management Settings: Computer Management – Management Framework: Security.

So now what? For more details, please see below the jump.

The SSL certificate in question is the SSL certificate used by Tomcat. Jamf is deprecating the use of self-signed certificates for Tomcat, as mentioned in the Jamf Pro 10.41.0 release notes:

Removal of unverified SSL certificates in Jamf Pro — In a future release of Jamf Pro the option to use an unverified SSL certificate for Jamf Pro will be removed. Customers with Cloud-hosted environments and those with a verified third-party certificate will see no changes. Customers with On-Premise environments using Jamf Pro’s built-in certificate authority to issue SSL certificates need to move to a trusted third-party certificate.

The alert is being triggered if you have the SSL Certificate Verification setting set to one of the following:

• Disabled
• Always except during enrollment

The Disabled setting means the Jamf Pro agent installed on a Mac isn’t verifying certificate trust at all for the SSL certificate that Tomcat is using.

The Always except during enrollment setting means that the Jamf Pro agent installed on a Mac isn’t verifying certificate trust for the SSL certificate that Tomcat is using at enrollment, but does verify that the SSL certificate is trusted for all subsequent communication.

Note: The Always except during enrollment setting was meant to ensure that Jamf Pro could install a root certificate for a self-signed certificate and establish certificate trust that way.

If your Jamf Pro service is using a publicly trusted SSL certificate, the fix is to set the SSL Certificate Verification setting to the following:

• Always

Selecting that setting and clicking the Save button will result in the following warning being displayed. If you’re certain you have a publicly trusted certificate, click OK. Otherwise, click the Cancel button to back the change out.

As long as you have a publicly-trusted SSL certificate for Tomcat, changing the SSL Certificate Verification setting to Always should have no impact. 

If you’re hosted in Jamf Cloud, you should already be using a publicly trusted SSL certificate. If you’re hosting Jamf Pro yourself, I recommend verifying that you’re using a publicly trusted certificate before making that change.

If you are hosting Jamf Pro yourself and don’t have a publicly trusted SSL certificate for Tomcat, I strongly recommend getting one as soon as possible. As Jamf’s release notes mention, the option to not use a trusted certificate will be removed from a future version of Jamf Pro.

As a follow-up to my earlier post about working with Microsoft Defender’s tamper protection, I’ve written an Extension Attribute for Jamf Pro which detects and reports on Defender’s tamper protection status. For more details, please see below the jump.

The Extension Attribute uses Defender’s mdatp command line tool to report on Defender’s tamper protection status. Once the mdatp tool is verified to be installed and executable, it’s used to check the tamper protection status. The EA will return one of the following values:

• 000
• 001
• 010
• 100

The returned values indicate the following:

• 000 = The /usr/local/bin/mdatp command-line tool cannot be found or is not executable.
• 001 = Tamper protection is fully disabled.
• 010 = Tamper protection is set to audit mode.
• 100 = Tamper protection is fully enabled.

The Extension Attribute is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/rtrouton_scripts/blob/main/rtrouton_scripts/Casper_Extension_Attributes/check_microsoft_defender_tamper_protection_status

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

PDF: https://tinyurl.com/jnuc2022pdf
Keynote: https://tinyurl.com/jnuc2022key

For those who wanted a copy of my filesystem talk at the MacSysAdmin 2022 conference, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/macsysadmin2022pdf
• Keynote: https://tinyurl.com/macsysadmin2022key

The video of my session is available for viewing here:

https://www.macsysadmin.se/video/day1session2.mp4

With the release of macOS Ventura expected this month, an important topic to many Mac admins is having their systems management tools detect as quickly as possible which of their Macs have upgraded to macOS Ventura. The reasons for this are varied, but one particular reason is to get configuration profiles deployed as soon as possible to manage new features and functionality in macOS Ventura.

One way to ensure quick detection if you’re using Jamf Pro is to have your managed Macs submit an inventory update to the Jamf Pro server when the Mac starts up. For one way to do this, please see below the jump.

For Macs managed by Jamf Pro, it’s possible to trigger the Jamf agent from the command line to do the following tasks:

1. Verify that the Jamf agent on the Mac can contact the Jamf Pro server.
2. Collect an inventory update from the Mac and submit it to the Jamf Pro server

The commands to do so are the following:

Verify connection to the Jamf Pro server:

Collect and submit an inventory update to the Jamf Pro server:

The following command should do the following:

1. Try for 60 seconds to verify the connection to the Jamf Pro server
2. If connection is successfully verified, collect and submit an inventory update to the Jamf Pro server.

Note: The && in the command will ensure that the second command (the inventory update) will only run if the previous command runs without errors. If the connection can’t be verified, the jamf checkJSSConnection command will exit with an error status. The error status will mean that the subsequent inventory update command won’t be executed.

The command above can be added to a LaunchDaemon like the one shown below. Installing this LaunchDaemon will ensure that the two commands (connection verification and inventory update) are run every time the Mac starts.

You can deploy this LaunchDaemon using a script like the one shown below. The example script shown below will do the following:

1. Create the LaunchDaemon file on the Mac in question.
2. Set the correct permissions on the LaunchDaemon file
3. Install the LaunchDaemon file into /Library/LaunchDaemons
4. Load the LaunchDaemon
5. Verify that the LaunchDaemon is in place and loaded.

Note: Once the LaunchDaemon is loaded, the Jamf agent on Mac will immediately perform the following actions:

1. Try for 60 seconds to verify the connection to the Jamf Pro server
2. If connection is successfully verified, collect and submit an inventory update to the Jamf Pro server.

The LaunchDaemon will also be loaded by the Mac at startup, so the same actions will also performed any time the Mac starts up.

As a follow-up to my previous post on running Jamf Pro inventory updates at startup, several folks have asked if the approach I showed was better or more efficient than using a Jamf Pro policy to run the inventory update. I thought about it and I can’t say for certain if the LaunchDaemon-driven approach I described is better than using a Jamf Pro policy.

The advantage of the LaunchDaemon-driven approach has is that the Mac admin has control of the options being used. In my example solution’s case, I have jamf checkJSSConnection checking for up to 60 seconds before giving up. Depending on your network setup, it may take that long before your Mac can verify it can talk to the Jamf Pro server.

If you’re running an inventory update via a Jamf policy’s startup trigger, you’re using whatever configuration Jamf has chosen for making sure the policy is triggered when you want it to be. Jamf’s choices may be the right ones, but those choices are being made by Jamf and not the individual Mac admin.

That said, collecting and submitting inventory updates to Jamf Pro is a problem which can be solved multiple ways and what I presented in my previous blog post was a solution, but not the only solution. With that in mind, please see below the jump for details on how to solve the problem of collecting and submitting inventory updates at startup using a Jamf Pro policy.

You can set up a Jamf Pro policy with the following options to collecting and submit inventory updates to Jamf Pro when a Mac starts up:

1. Under the General policy options, set the following trigger and execution frequency:

• Trigger: Startup
• Execution Frequency: Ongoing

2. Under the Maintenance policy options, set the following option:

• Update Inventory: Check the box to select this option

All other options (scoping, category, user interaction, etc.) can be set according to the individual Mac admins’s preferences.

As part of preparing for macOS Ventura, it may be useful to have a way to easily distinguish between the Macs in your fleet which can run macOS Ventura and those which can’t. Apple has published the following list of Macs which are compatible with Ventura, which will help with both identitying the compatible Mac models as well as the incompatible Mac models.

• iMac: 2017 and later models
• iMac Pro: All models
• MacBook: 2017 and later models
• MacBook Pro: 2017 and later models
• MacBook Air: 2018 and later models
• Mac Mini: 2018 or later models
• Mac Pro: 2019 or later models
• Mac Studio: All models

From there, here’s the list of Mac models which are compatible with macOS Ventura:

We can use this information to build smart groups which can help identify which Macs are compatible with Ventura and which are not. For more details, see below the jump:

Using the information mentioned above, I was able to build two smart groups, one which displays compatible Macs and the other which displays incompatible Macs.

The compatible Macs’ smart group checks for if the Mac in question’s model identifier is any of the model identifiers which are compatible with Ventura:

The incompatible Macs’ smart group checks for if the Mac in question’s model identifier is not any of the model identifiers which are compatible with Ventura:

To upload these smart group XML files to a Jamf Pro server server using the API, download the XML file to a convenient location, then run the commands shown below (substituting your Jamf Pro server and Jamf Pro user account information as appropriate):

Note: You will first need to get an API bearer token for authentication. Use the commands below (depending on which OS you’re using) to obtain a bearer token from your JAMF Pro server:

Get API bearer token on macOS Monterey and later:

Get API bearer token on macOS Big Sur and earlier:

The bearer token should look something like this:

Once you have the bearer token, use the token to authenticate the API command as shown below:

If the API bearer token is the one shown above, the API command should look something like this:

If the smart group was successfully uploaded, you should next see output similar to that shown below:

The new smart group should now be present on the Jamf Pro server.

Every so often, it may be necessary to generate a report from Jamf Pro of which policies are available in Self Service. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the policy records and generate a report in .tsv format.

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:

• Policies: Read

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

Usage:

./Generate_Self_Service_Policy_Report.sh

The script takes the following actions:

1. Uses the Jamf Pro Classic API to download the Jamf Pro IDs of all computer policies.
2. Checks which policies are Self Service policies.
3. Uses the Jamf Pro Classic API to download all information about matching Self Service policies.
4. Pulls the following information out of the policy record data:

• Jamf Pro ID
• If the policy is enabled in the Jamf Pro admin console
• The policy’s name in the Jamf Pro admin console
• The name of the policy’s category
• The name displayed in Self Service for the policy

Create a report in tab-separated value (.tsv) format which contains the following information about the Self Service policies.

• Jamf Pro ID
• If it’s a Self Service policy
• If the policy is enabled in the Jamf Pro admin console
• The policy’s name in the Jamf Pro admin console
• The name of the policy’s category
• The name displayed in Self Service for the policy
• Jamf Pro admin console URL for the Self Service policy

The report generated by script should appear similar to what is 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/Generate_Self_Service_Policy_Report