Suppressing the Welcome to macOS Tahoe 26 screen with a configuration profile on macOS Tahoe 26.1.0

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac. Among those which appear following an upgrade to macOS Tahoe 26 is the Welcome to macOS Tahoe 26 screen, which provides a walkthrough of selected new features available in macOS Tahoe.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Welcome to macOS Tahoe 26 screen on macOS Tahoe 26.1.0 using a configuration profile. For more details, please see below the jump.

Disabling the floating thumbnail preview for screenshots on macOS Tahoe

One of the features available when taking screenshots is the option to see a floating thumbnail preview of the screenshot before it gets saved to the location you’ve chosen to save screenshots to. This option is enabled by default and looks like this on macOS Tahoe.

1. Screenshot is taken.
2. Floating thumbnail preview appears and slides off-screen.
3. Screenshot file icon appears (in this example, screenshots are being saved to the desktop.)

I prefer to have this option turned off, as I’d rather have the ability to select and work with the screenshot file right away in place of waiting for the floating thumbnail to appear and disappear.

Fortunately, this option can be turned off in a couple of ways. The first is through using Screenshot.app, which is included with macOS.

When you use Screenshot.app, it will provide a toolbar for selecting screenshot image or screencapture movie options. As part of that toolbar, there is an Options button.

When you click the Options button, you get a menu where one of the selections is Show Floating Thumbnail. If you unselect that, the floating thumbnail preview no longer appears when taking screenshots or making screencapture movies.

You can also disable this from the command line, by running the two following commands in Terminal:

	/usr/bin/defaults write com.apple.screencapture show-thumbnail -bool false
	killall SystemUIServer

view raw

gistfile1.txt

hosted with ❤ by GitHub

In my case, I wanted to disable the floating thumbnail preview on my Macs so I’ve written a profile which can enforce this. It’s available via the link below:

https://github.com/rtrouton/profiles/blob/main/DisableScreenshotFloatingThumbnail

Deploying custom DDM declarations using Blueprints in Jamf Pro

One of the management options Jamf Pro provides with Blueprints is the ability to create and deploy custom declarative declarations to managed Macs. What this means that if you can manually build the JSON payload for a DDM declaration, you should now be able to deploy it using Blueprints even if Jamf does not have a Blueprint template available yet for that declaration. This is conceptually similar to Jamf Pro’s ability to deploy custom configurations in management profiles to macOS using the Application & Custom Settings management profile payload

For more details, please see below the jump.

Granting a local user account administrator rights on a Mac which only has accounts with standard user rights

I recently saw a post on LinkedIn where the poster had apparently removed all accounts which were assigned administrator rights on the Mac from the local group named admin on macOS and then had difficulty recovering from this state.

On macOS, membership in the admin group is what grants administrator rights, so now this meant that the Mac only had accounts which had standard user rights.

There have been methods available in the past for fixing this from the Recovery environment which used the chroot command line tool in the Recovery environment to change the active filesystem from the Recovery environment to the Mac’s regular boot drive, then run the dseditgroup command line tool to re-add one or more local user accounts to the admin group on the boot drive.

However, it looks like the chroot command does not work currently in the Recovery environment available to macOS Tahoe on Apple Silicon Macs. When launched, it reports an error and then exits.

With the chroot command line tool no longer working in Recovery, that would seem to close off most avenues to re-adding users to the admin group for Apple Silicon Macs running macOS Tahoe. However, after some research, I’ve discovered an alternative method which uses the sudo command line tool. For more details, please see below the jump.

Enabling Touch ID authentication for sudo using Blueprints in Jamf Pro

One of the capabilities Apple added in macOS Sonoma was a pluggable authentication module (PAM) configuration option to enable Touch ID authentication for the sudo tool which would persist and not be overwritten by software updates.

To enable this option, there is a /etc/pam.d/sudo_local.template file on macOS Sonoma and later which appears as shown below:

	# sudo_local: local config file which survives system update and is included for sudo
	# uncomment following line to enable Touch ID for sudo
	#auth sufficient pam_tid.so

view raw

gistfile1.txt

hosted with ❤ by GitHub

Copying the /etc/pam.d/sudo_local.template file to /etc/pam.d/sudo_local and uncommenting the indicated line allows Touch ID to work as authentication for the sudo tool.

	# sudo_local: local config file which survives system update and is included for sudo
	# uncomment following line to enable Touch ID for sudo
	auth sufficient pam_tid.so

view raw

gistfile1.txt

hosted with ❤ by GitHub

A number of Mac admins have written scripts to apply this PAM configuration to Macs, but there didn’t seem to be a good way to handle this without scripting. However, as part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to manage sets of tamper-resistant system configuration files for different system services. As of this date, the following services built into macOS can be managed this way:

• sshd
• sudo
• PAM
• CUPS
• Apache httpd
• bash
• zsh

Jamf Pro’s Blueprints supports managing these services via the Service configuration files component. Since enabling Touch ID authentication for sudo is managed using a PAM configuration file, that means that enabling Touch ID authentication for the sudo tool can be accomplished via Blueprints. For more details, please see below the jump.

Session videos from Jamf Nation User Conference 2025 now available

Jamf has posted the session videos for from Jamf Nation User Conference 2025, including the video for my “MDM and DDM 101” session.

For those interested, all of the the JNUC 2025 session videos are available on YouTube, though it doesn’t appear that there’s a dedicated YouTube playlist at this point. For convenience, I’ve linked my session here.

Deploying software update declarations for automatic OS upgrades using Blueprints in Jamf Pro

One of the management options Jamf Pro provides with Blueprints is sending DDM declarations to managed Macs run macOS software updates automatically. This is comparable to Jamf Pro’s managed software update functionality, which also provides the ability to send a DDM declaration to run software updates.

Previously, the only option for deploying software update declarations via Blueprints was to specify an individual OS version. Now there is a new option for upgrading the OS version to the latest version a particular Mac can support.

For those familiar with Jamf Pro’s managed software update functionality, the new software update declaration functionality provides the following update options:

• Download and schedule to install
• Latest version based on device eligibility

The Latest version based on device eligibility functionality in the managed software update functionality tells the managed Mac to download and install the latest version of macOS that a particular Mac can support. The Blueprints software update declaration functionality provides that same experience, where you can do the following:

• Set that you want the managed Macs to update their OS version to the latest version of macOS a particular Mac can support.
• Set a deadline that you want to have your Macs updated by.

For more details, please see below the jump.

macOS 26.1.0 virtual machines do not generate valid system serial numbers

After updating to macOS Tahoe 26.1.0 yesterday, I then did what I normally do and began building new virtual machines to test with. I built a VM for macOS 26.1.0 and then noticed something odd. The virtual machine did not have an assigned system serial number. Instead, where you would expect to see the serial number displayed, there is a blank entry.

I built a macOS 26.0.1 VM and saw the serial number appear.

I then upgraded the VM from macOS 26.0.1 to macOS 26.1.0. Poof, no more serial number.

After talking with colleagues in the Mac Admins Slack, I was pointed to a Known Issues entry for Virtualization in the macOS 26.1.0 release notes:

The serial number published for the virtual machine is 0, which prevents iCloud and related applications from functioning correctly. (163294564)

You can’t set a system serial number manually for macOS VMs running on Apple Silicon Macs, so it looks like this state of affairs is with us until Apple fixes it. Hopefully that is soon.