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.

Creating AWS S3 buckets for webpage redirection

I recently had an issue where I needed to solve a particular problem:

1. I had a DNS domain name

dns.name.here

2. I needed to point it to a HTTPS URL hosted on another domain:

https://other.dns.name.here/path/to/site/goes/here

3. The DNS server for dns.name.here does not support HTTP Redirect records.

To address this, I decided to use S3 buckets hosted on Amazon Web Services to handle the redirection to the HTTPS URL. In this scenario, what I’m doing is pointing the relevant dns.name.here domain name at the S3 bucket’s AWS domain name. The S3 bucket is performing a HTTP 301 redirect, which sends the requesting web browser the URL of the site I want to connect to. For those interested, Amazon’s documentation of how to use an S3 bucket for URL redirection is linked below:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-page-redirect.html

After doing it the first time manually, I decided to see if anyone had scripted this task. It turns out the answer is “no”, at least for what I wanted to do, so I’ve written a script which handles this task. For more details, please see below the jump.

Using the Jamf Pro API to report on Self Service policies

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.

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.

Running Jamf Pro inventory updates at startup time

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.

Slides from the “Leveling Up – Managing admin rights in the enterprise” session at MacSysAdmin 2022

For those who wanted a copy of my admin rights 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