Creating a NexThink uninstaller for deployment via Jamf Pro

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.

Creating a NexThink installer for deployment via Jamf Pro

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:

—–BEGIN CUSTOMER KEY—–MIIDhzCCAm+gAwIBAgIEIa+KoTANBgkqhkiG9w0BAQsFADBbMScwJQYDVQQDDB5SZWdlcnkgU2VsZi1TaWduZWQgQ2VydGlmaWNhdGUxIzAhBgNVBAoMGlJlZ2VyeSwgaHR0cHM6Ly9yZWdlcnkuY29tMQswCQYDVQQGEwJVQTAgFw0yMjEyMDIwMDAwMDBaGA8yMTIyMTIwMjIwMDIxMFowSTEVMBMGA1UEAwwMbG9jYWxob3N0LmlvMSMwIQYDVQQKDBpSZWdlcnksIGh0dHBzOi8vcmVnZXJ5LmNvbTELMAkGA1UEBhMCVUEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaKRW9KeX4wg/838FkxmzaBjqf1DeKD5GKEqhUKz0y78Wwnsv2zAXGM4UkdZJP9zHtC9/wFQT+lhclDlogxkU9lfMADV7nMdGL0GkJzwMQNS52dPNXDup7/d9yRkyjkV0Pf4t2fJF3igoNXFQuBvuArkNV6hfja2gOEczOSAaJ7L7qRnSahLjciJRaCuEPjwneh3krhOFT+djwuYJMIvBDEqs+gfp4OPDDBtVg2scUUGRmHsC+JAoK+JwqYwB9TNt+9hZtGfDqgZSHebXEfRTguhQpBj0mPTo76EahAbHbXJhV+efg3jt32pZ6qRl8ffrZAjefWEAnOMyXQ7fbL+bpAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zAfBgNVHSMEGDAWgBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zANBgkqhkiG9w0BAQsFAAOCAQEAhpbntg+nwhIKgRuUidu/wXn197Ah0Pd4CYYxG5dR9rg8nWObx4QO6ApIH91nUUQVuV6mSTFtfy4yNQzxaROgZP9hDNvhd78D/ewXxp6bN/Xkn+c7SWrs/b1vHb2Dr1sDP4F9SAOrCI6TdoYa8UNhPXXSTt8M/hGSB2oWOpT2FAb2IbdmdYhDaibcJwp+/Had1FLbeDZgdgYCFoZLjws/9E/pIXjSxBYAJLbaQZffrfO5jCe2KesE73iQatW2IPynsFifRGGoMHXVLOfsLA9c2KDGqDmnJ+PvsBSe9rIpSJYC4WjR5Mt8W88kQSj05b9NqCsXmmMDEbD8uVLyKvQihA==—–END CUSTOMER KEY—–

view raw

Company-Name-customer-key.txt

hosted with ❤ by GitHub

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.

Session videos from Jamf Nation User Conference 2022 now available

Jamf has posted the session videos for Jamf Nation User Conference 2022, including the video for my Running Jamf Pro at Scale, from SAP with ❤️ session.

For those interested, all of the the JNUC 2022 session videos are available on YouTube. For convenience, I’ve linked my session here.

autopkg-conductor updated to support reporting to Slack and Microsoft Teams

When the autopkg-conductor tool was first written, one of its primary functions was to send the output of JSSImporter to a Slack channel. With JSSImporter being deprecated in favor of JamfUploader, I’ve decided to do the following:

1. Drop support for JSSImporter.
2. Add additional reporting options for JamfUploader.

As of the current version to the tool, autopkg-conductor can send output from JamfUploader to the following:

• Slack
• Microsoft Teams

For more details, please see below the jump.

Downloading macOS IPSW files for use with Mac virtual machines on Apple Silicon Macs

A change between creating Mac virtual machines on Intel Macs and creating them on Apple Silicon Macs is that virtualization on Apple Silicon Macs often assumes that the virtual machine is built using a macOS restore image . These restore images are files with an .ipsw file extension and are commonly referred to as IPSW files.

Apple publishes the download links for macOS restore images via the following URL:

https://mesu.apple.com/assets/macos/com_apple_macOSIPSW/com_apple_macOSIPSW.xml

If you look at the XML file from the link above, it provides download links for the current version of macOS for the various Mac models which support running that version of macOS.

Among the various models listed is the model identifier for Mac virtual machines (VirtualMac2,1) created using Apple’s Virtualization framework. This means that we should be able to identify and download the appropriate IPSW file for use when building Mac virtual machines.

Using this information, I’ve written a script to download the appropriate IPSW file for building macOS virtual machines by checking the file linked above for the download URL associated with the VirtualMac2,1 Mac model. For more details, please see below the jump.

Downloading macOS Monterey from the App Store

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/

Adding hidden Login Items on macOS Ventura

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.

Opening macOS Ventura’s System Settings to desired locations via the command line

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.

Building Jamf Pro smart groups for Ventura-compatible and Ventura-incompatible Mac models

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:

	Mac13,1
	Mac13,2
	Mac14,2
	Mac14,7
	MacBook10,1
	MacBookAir10,1
	MacBookAir8,1
	MacBookAir8,2
	MacBookAir9,1
	MacBookPro14,1
	MacBookPro14,2
	MacBookPro14,3
	MacBookPro15,1
	MacBookPro15,2
	MacBookPro15,3
	MacBookPro15,4
	MacBookPro16,1
	MacBookPro16,2
	MacBookPro16,3
	MacBookPro16,4
	MacBookPro17,1
	MacBookPro18,1
	MacBookPro18,2
	MacBookPro18,3
	MacBookPro18,4
	MacPro7,1
	Macmini8,1
	Macmini9,1
	VirtualMac2,1
	iMac18,1
	iMac18,2
	iMac18,3
	iMac19,1
	iMac19,2
	iMac20,1
	iMac20,2
	iMac21,1
	iMac21,2
	iMacPro1,1
	iSim1,1

view raw

ventura_compatible_models.txt

hosted with ❤ by GitHub

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:

Running Jamf Pro inventory updates at startup time using a Jamf Pro policy

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.