Payload-Free Package Creator.app, an Automator application that allows the selection of an existing script and then create a payload-free package that runs the selected script, has been updated to version 2.4.

The functionality and operations of the app have not changed from Payload-Free Package Creator 2.3. The main change is that Payload-Free Package Creator.app is now a Universal app, allowing it to run natively on both Intel and Apple Silicon Macs.

Payload-Free Package Creator 2.4, along with all components and scripts, are available on GitHub via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator

In working with folks who want to build installer packages to install the Privileges app, I’ve noticed that a number of them have experienced problems with manually building an installer package for Privileges which correctly installs the Privileges app’s helper tool.

The result of an installer which does not install the helper tool correctly is that when a user requests administrator privileges using the Privileges app, the app prompts them to install the helper tool. This requires administrative rights, which sets up a chicken and egg situation where admin privileges are being required to get admin privileges.

Fortunately, there is an automated method for building the installer package which (so far) has worked correctly in each case I’m familiar with. There are AutoPkg recipes available for creating a Privileges installer package and AutoPkg is able to build a correctly working Privileges installer package.

For more details, please see below the jump.

For those not familiar with using AutoPkg, please follow the process below to build a working Privileges installer package:

Note: If you do not want to install AutoPkg on your own Mac, AutoPkg also runs fine in a macOS virtual machine.

1. If Git is not already installed, install Git.

Note: Git must be installed before installing AutoPkg because AutoPkg uses Git for many of AutoPkg’s functions.

Git is included with Xcode or the Xcode Command Line Tools, so installing either Xcode or the Xcode Command Line Tools will also install the necessary Git support.

2. Download the latest AutoPkg installer from https://autopkg.github.io/autopkg

3. Install AutoPkg.

4. Open Terminal and run the following command:

autopkg repo-add rtrouton-recipes

5. Once the repo has been added, run the following command to create an AutoPkg override of the AutoPkg recipe which creates the installer package:

autopkg make-override com.github.rtrouton.pkg.privileges

6. An AutoPkg override file should be created with the following recipe identifier:

local.pkg.Privileges

You can verify this by opening the override file in a text editor and looking for the Identifier key.

7. Once the override file has been created, run the following command to create a Privileges installer package:

autopkg run local.pkg.Privileges

You should then see output similar to this:

The newly-created Privileges installer package should be stored be in ~/Library/AutoPkg/Cache/local.pkg.Privileges.

8. Repeat process as needed for each new version of Privileges.

After a long run, first beginning with Mac OS X Server 1.0 in 1999, Apple has announced the end of macOS Server as of April 21, 2022. The final version is macOS Server 5.12.2, which runs on macOS Monterey.

macOS Server 5.12.2 has shed many of the features once supported by macOS Server. As of 5.12.2, the following two services are supported:

• Profile Manager
• Open Directory

Both services are not currently available outside of macOS Server, so Apple discontinuing macOS Server also means the end of the line for Apple’s Open Directory directory service and Apple’s Profile Manager MDM service.

For current customers who have purchased macOS Server, macOS Server 5.12.2 remains available in the App Store.

Kandji invited me to discuss the topic of whether you should set up users in your work environment with standard user rights or admin user rights. It’s a great topic and was a lot of fun to dig into, so I’m happy to say that they recorded the discussion between me and Steven Vogt. If you’re interested, the discussion is available on YouTube and I’ve linked it below:

As part of the release of Safari 15.5, there seems to be an issue with Safari being able to load embedded content on some websites. One example is the US State Department’s site for reporting a lost or stolen passport:

https://travel.state.gov/content/travel/en/passports/have-passport/lost-stolen.html

This site has embedded content and Safari is very slow to load that site. The behavior seems to be tied to the Hide IP address from trackers setting in Safari’s privacy settings:

With that setting enabled, slow website loading:

With that setting disabled, normal website loading:

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/

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.

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.

With the release of macOS Ventura, the System Preferences application has been replaced with the System Settings application.

macOS Monterey System Preferences:

macOS Ventura System Settings:

Along with this change, a number of previously-known commands for opening individual System Preferences preference panes from the command line no longer work with System Settings.

However, it looks like the underlying command line functionality wasn’t changed by Apple. You just need to know what the new options are to enter. For more details, please see below the jump.

I’ve put together a list of the ones I’ve found to work, which is available below. Find any more? Please let me know in the comments:

One of the changes made between macOS Monterey’s System Preferences and macOS Ventura’s System Settings is that the Hide checkbox in System Preferences’ Login Items has disappeared from System Settings’ Login Items.

Login Items in System Preferences

Login Items in System Settings

Fortunately for those who want to continue being able to launch applications on login and automatically hide them, it’s still possible to do so on macOS Ventura from the command line using osascript.

To do this, run a command similar to the one shown below using the logged-in user’s privileges:

/usr/bin/osascript -e 'tell application "System Events" to make login item at end with properties {path:"/path/to/itemname", hidden:true}'

For example, if you want Safari to launch at login with its windows automatically hidden, run the command below using the logged-in user’s privileges:

/usr/bin/osascript -e 'tell application "System Events" to make login item at end with properties {path:"/Applications/Safari.app", hidden:true}'

Safari will appear in the Login Items list without any sign that it’s launching as hidden, but the application behavior on login will be just like it would be on earlier versions of macOS where the Hide checkbox was checked.

Now that macOS Ventura has been released, it’s become more difficult to access the macOS Monterey installer for those who still need it. Fortunately, macOS Monterey has not been removed from the App Store and it is still available for download. Apple has a KBase article that shows how to access the macOS Monterey page in the App Store, available via the link below:

https://support.apple.com/HT211683

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

https://apps.apple.com/us/app/macos-monterey/id1576738294?mt=12

That link should open the App Store and take you to the macOS Monterey download page.

In the event that you’re blocked from downloading macOS Monterey, you should be able to download it in a virtual machine. I have a post on how to do this, available via the link below:

https://derflounder.wordpress.com/2017/02/21/downloading-older-os-installers-on-incompatible-hardware-using-vms/

A while back, I had to build an installer for NexThink Collector which could be deployed via Jamf Pro. NexThink can be interesting to deploy because the installation process:

1. Involves an application named csi.app, which has a command line tool.
2. The referenced csi app’s command line tool configures and runs an installer package.
3. The command line tool also needs to reference a license file, which NexThink refers to as a CustomerKey file.

The CustomerKey file should look similar to what’s shown below:

All the needed components with the exception of the CustomerKey file, which is different for each customer, ship on a disk image.

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing one of the following:

Graphical installation: Mounting the disk image, double-clicking on the installer package and following the prompts, entering the correct configuration information were needed.

Command line installation: Mounting the disk image, opening the Terminal application and using the csi app’s command line tool to configure the installer package and run the installation process.

For the Enterprise Deployment section of the application, the NexThink documentation says they support it but doesn’t provide information on how to do it.

In my case, I decided to do the following to deploy it via Jamf Pro:

1. Wrap the disk image and CustomerKey file inside a separate installer package.
2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Identify the location of the csi.app on the mounted disk image.
D. Identify the location of the CustomerKey file stored inside the installer package.
E. Use the csi app’s command line tool to configure and run the NexThink-provided installer package on the mounted disk image, to install the NexThink Collector software.
F. Unmount the disk image.

For more details, please see below the jump.

Note: The details of installing and configuring NexThink are going to vary between shops, because different shops are going to configure different options for NexThink. Please consider what’s shown below as a general example, not something that will work for all environments.

Pre-requisites:

• Packages
• Vendor-provided NexThink disk image with the NexThink Collector installer for macOS
• Vendor-provided CustomerKey text file

Before building the package, you’ll need to create a directory named CustomerKeys somewhere convenient.

Once the CustomerKeys directory has been created, add the CustomerKey file to it. The CustomerKey file is a plaintext file, where the filename must end in the .txt file extension. For this example, the CustomerKey file is named Company-Name-customer-key.txt.

Building the NexThink Collector installer

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project NexThink Collector Install 22.9.1.14.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

• Identifier: set as appropriate (for my installer, I’m using com.nexthink.pkg.collector)
• Version: set as appropriate (for my installer, I’m using 22.9.1.14 )

In the Post-installation Behavior section:

On Success: should be set to Do Nothing.

In the Options section:

• Require admin password for installation should be checked
• Relocatable should be unchecked
• Overwrite directory permissions should be unchecked
• Follow symbolic links should be unchecked

5. Select the Payload tab. Nothing here should be changed from the defaults.

6. Select the Scripts tab.

Under the Additional Resources section, add the following file and directory:

The NexThink disk image

The CustomerKeys directory containing the CustomerKey file.

The last part is telling the NexThink installer to run, using the csi app’s command line tool. For this, you’ll need a postinstall script.

Here’s the postinstall script being used for this example installer package:

If not already selected, select the postinstall script and add it to the project.

Note: The options shown in the postinstall script for configuring NexThink are not going to work for all shops, because different shops are going to configure different options for NexThink. Please consider what’s shown above as a general example, not something that will work for all environments.

For more details on the available configuration options, please see the Command-line installation section of the NexThink documentation available via the link below:

https://docs.nexthink.com/platform/latest/installing-collector-on-macos

7. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• Does not have the NexThink Collector software installed

The end result should be that the NexThink Collector software installs onto the Mac and is registered with the NexThink server.

As a follow-up to my previous post on building an installer for NexThink Collector which could be deployed via Jamf Pro, I also needed to build an uninstaller for this software. Fortunately, NexThink ships an uninstaller script on the same disk image that it uses to ship its installer.

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing the following to run the uninstall process:

A. Mounting the disk image
B. Opening the Terminal application
C. Using the uninstaller script to run the uninstallation process.

In my case, I decided to do the following to deploy the uninstaller via Jamf Pro:

1. Wrap the disk image inside a separate installer package.
2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Use the uninstall script to uninstall the NexThink Collector software.
D. Unmount the disk image.

For more details, please see below the jump.

Pre-requisites:

• Packages
• Vendor-provided NexThink disk image with the NexThink Collector uninstaller script

Building the NexThink Collector uninstaller

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project NexThink Collector Uninstaller 22.9.1.14.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

• Identifier: set as appropriate (for my uninstaller, I’m using com.nexthink.pkg.collector.uninstaller.)
• Version: set as appropriate (for my uninstaller, I’m using 22.9.1.14. )

In the Post-installation Behavior section:

On Success: should be set to Do Nothing.

In the Options section:

• Require admin password for installation should be checked
• Relocatable should be unchecked
• Overwrite directory permissions should be unchecked
• Follow symbolic links should be unchecked

5. Select the Payload tab. Nothing here should be changed from the defaults.

6. Select the Scripts tab.

Under the Additional Resources section, add the following file:

• The NexThink disk image

The last part is telling the NexThink uninstall script to run. For this, you’ll need a postinstall script.

Here’s the postinstall script being used for this example:

If not already selected, select the postinstall script and add it to the project.

7. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• The NexThink Collector software installed

The end result should be that the NexThink Collector software is removed from the Mac.

As part of some recent testing, I needed to do some work with Palo Alto’s GlobalProtect VPN software. Palo Alto provides an installer package for GlobalProtect, but it has some interesting characteristics as the installer includes three installation options. One is enabled by default and the other two are disabled by default.

The first configuration is the option to install GlobalProtect, the default enabled configuration:

The second configuration is the option to uninstall GlobalProtect, which is disabled by default:

The third configuration is the option to enable the System Extension for GlobalProtect, which is disabled by default:

Note: In the image above, I’ve done some photoshopping because checking the third option to enable the System Extension for GlobalProtect also enables the option to install GlobalProtect. I made the change to the image to hopefully make more clear which option I was discussing.

The options to uninstall GlobalProtect and enable the System Extension for GlobalProtect can be managed by using an installer choices XML file to selectively enable only the desired option. For example, here’s the installer choices XML file for enabling only the option to uninstall GlobalProtect:

Here’s the installer choices XML file for enabling only the option to enable the System Extension for GlobalProtect:

Using these options, I was able to build recipes for AutoPkg which would automatically build three installer packages:

• An installer which installs GlobalProtect.
• An installer which uninstalls GlobalProtect.
• An installer which enables the System Extension for GlobalProtect.

The reason I chose to do this is that using AutoPkg to create these additional installer packages should help ensure any changes that Palo Alto makes to GlobalProtect’s uninstall and System Extension enablement will automatically be available whenever a new version of GlobalProtect is picked up by AutoPkg. In turn, this should save work for those deploying GlobalProtect because now they don’t need to figure out what may have changed between GlobalProtect releases. For more details, please see below the jump.

There is an existing AutoPkg .download recipe for GlobalProtect, available via the link below:

https://github.com/autopkg/peshay-recipes/blob/master/PaloAlto/GlobalProtect.download.recipe

Since that part of the recipe setup is already done, I focused on building AutoPkg .pkg recipes. For the example recipe shown below which handles creating the installer which installs GlobalProtect, the recipe won’t make any changes to the downloaded installer package beyond renaming it. This is because by default, the GlobalProtect installer package installs GlobalProtect.

The second and third .pkg recipes will wrap the downloaded installer package inside a second installer package, along with the following files which will also be stored in the second installer package:

1. An installer choices XML file
2. A postinstall script which will install the downloaded installer using the options configured by the installer choices XML file.

AutoPkg recipe to create an installer package which uninstalls GlobalProtect:

AutoPkg recipe to create an installer package which enables the System Extension for GlobalProtect:

Upgrading to macOS Ventura from macOS Monterey or earlier seems like it should be a straightforward process.

1. Open System Preferences

2. Click on Software Update.

3. If the macOS Ventura upgrade is listed there, click on the Upgrade Now button.

However, you may get different upgrade experiences depending on whether you are running macOS 12.3 or later, or if you’re running macOS 12.21 or earlier.

macOS 12.3 or later:

1. You see a macOS Ventura installer which is around 6 GBs or less.

2. When you click Upgrade Now, you are asked to authenticate as a user. Not as a user with administrator privileges, just as a user.

macOS 12.21 or earlier

1. You see a macOS Ventura installer which is around 12 GBs or more.

2. It downloads an Install macOS Ventura app to your Mac and installs it in /Applications.

3. The Install macOS Ventura app automatically launches once download and installation of the application completes.

4. Running the Install macOS Ventura app will prompt for a user with administrator privileges to authenticate before the upgrade proceeds.

Why the difference? The reason is that Apple has developed a new software upgrade path to macOS Ventura for Macs running macOS 12.3 or later which doesn’t require the following:

1. The need to run the macOS Ventura full installer
2. The requirement to authenticate as an administrator before upgrading from macOS Monterey to macOS Ventura.

Apple did include additional logic for macOS Ventura upgrades for upgrading to Ventura 13.0.0 and 13.0.1, where if a Mac running macOS Monterey 12.3 or later was enrolled with an MDM management solution and was thus in supervised mode, the new software upgrade path was disabled for those Macs.

As of the release of macOS 13.1, this logic no longer applies and supervised Macs may be offered the new upgrade path (which doesn’t require admin rights to upgrade.) 

For more details about this, and information on how to block the macOS Ventura upgrade from appearing in Software Update if your organization needs more time, please see the Apple KBase article linked below:

• Manage upgrading to macOS Ventura in your organization: https://support.apple.com/HT213471

My colleague Robert Hammen has also written on the topic of delaying upgrades, so if you’re interested in that topic, please see his Medium post linked below:

• Holding Back the OS Upgrades: https://hammen.medium.com/holding-back-the-os-upgrades-6c2d97f99ac3

Every so often, it may be necessary for Mac admins to deploy a script that can apply different settings to Mac desktops and laptops. A good example may be using the pmset command to apply Energy Saver settings, where you may want to apply one set of power management settings to laptops and a different set to desktops.

In the example above, the Model Identifier information from the system_profiler command is used to help identify if the Mac is a desktop or laptop. In this case, the Model Identifier information is checked to see if the model identifier contains “Book”.

If it does, it’s a laptop. Otherwise, it’s a desktop:

However, the latest Mac laptops’ model identifier does not contain “Book”. This means that this identification method should no longer be considered reliable.

What’s an alternative way to check? One way is to use the ioreg command to see if the Mac in question has a built-in battery or not. Laptops will have a built-in battery and desktops will not. For more details, please see below the jump.

You can use the ioreg command shown below to query the information for the AppleSmartBattery hardware driver (currently used by macOS for its battery management) and check whether the Mac has a built-in battery or not:

On a laptop, the following command should return Yes:

On a desktop, the same command should return no output:

You should be able to use this command to update the example script for setting power management to correctly identify laptops vs. desktops again:

Note: The AppleSmartBattery hardware driver is being queried by the ioreg command to gather this information. If Apple ever changes the name or the functionality of the AppleSmartBattery hardware driver, this method may stop working and need to be updated for the new name or functionality.