Category: Applications

Updates: Setup Manager and utiluti

Setup Manager 1.3

We have released Setup Manager 1.3 today. You can see the release notes and download the pkg installer here.

Most of the changes to Setup Manager in the update do not change the workflow directly. The focus for this update was to improve logging and information provided for trouble-shooting.

With the 1.3 update, Setup Manager provides richer logging information. You will find some entries in the Setup Manager log that were not initiated by the Setup Manager workflow, but are still very relevant to troubleshooting the enrollment workflow. You can see all installation packages that are installed during the enrollment, as well as network changes. This allows an admin to see when managed App Store installations or other installations initiated from the MDM or Jamf App Installers are happening in the enrollment workflow.

These can be very helpful to determine what might be delaying or interrupting certain other installations.

When we started building the “enrollment tool we wanted to use ourselves” more than two years ago, we chose to build a full application, rather than a script-based solution which remote controls some interface. One of the immediate benefits is that we could make the user interface richer and more specialized. Localizing the app into different languages was easier, too. Setup Manager adds Polish localization, bringing the total number of languages to ten!

(We use the help of volunteers from the community to localize to other languages, if you want to help localize Setup Manager into your language, please contact me.)

There was another goal, which took a bit longer to realize.

Swift apps allow us to dive deeper into the capabilities and information available in the operating system. A full blown app is also more capable at analyzing and displaying multiple sources of information at the same time. For example, Setup Manager will display a big warning when the battery level drops below a critical threshold.

These kinds of workflows and user interfaces would be nearly impossible or, at the very least, extremely complex to build and maintain with shell scripts. In this case, Setup Manager is monitoring and parsing other log files and summarizing them down to some important events in the background, while it is working through its main purpose of running through the action list from the profile.

This feature will not be seen by most users or even techs who are sitting in front of the Mac, waiting for the base installation to finish. But when you are trouble shooting problems during your enrollment workflow, these extra log entries can be very insightful. Even during testing, it unveiled some surprises in our testing environments.

We hope you like the new features. But, we are also not done yet and have plenty more ideas planned for Setup Manager!

utiluti 1.2

Since we are talking updates, I have also released an update to my CLI tool to set default apps for urls and file types (uniform type identifiers/UTI). utiluti 1.2 adds a manage verb which can read a list of default app assignments from plist files or a configuration profile. You can see the documentation for the new manage verb here and download the latest pkg installer here.

This allows you to define lists of default apps and push them with your device management system. Then you can run utiluti from a script in the same management system. This should greatly simplify managing default apps.

Note, that while you can set the default browser with utiluti, whether you are using the manage option or not, the system will prompt the user to confirm the new default browser. For this use case, you will want to put the utiluti command in a context where the user is prepared and ready for that extra dialog (such as a Self Service app). There are other tools, such as Graham Gilbert’s make-default CLI tool, which bypass the system dialog. In my experience, tools like this work well in fairly clean setup and require a logout or reboot after the change. This might fit your workflow, but you need to test.

I hope utiluti will find a place in your MacAdmin’s toolbox!

New tool: utiluti sets default apps

A while back I wrote a post on the Jamf Tech Thoughts blog about managing the default browser on macOS. In that post I introduced a script using JXA to set the default application for a given url scheme. (like http, mailto, ssh etc.) The beauty of using JXA/osascript is that it doesn’t require the installation of an extra tool.

However, there was a follow-up comment asking about default apps for file types, i.e. which app will open PDF files or files with the .sh file extension. Unfortunately, Apple has not bridged those AppKit APIs to AppleScript/JXA, which means it is not possible to use them in a script without dependencies.

Back then, I started working on a command line tool which uses those APIs. I didn’t really plan to publish it, since there were established tools, like duti, cdef and SwiftDefaultApp that provided the functionality. It was a chance to experiment and learn more about Swift Argument Parser. Then life and work happened and other projects required more attention.

A recent discussion on the Mac Admins Slack reminded me of this. Also, none of the above mentioned tools have been updated in the past years. As far as I can tell, none of them have been compiled for the Apple silicon platform. They don’t provide installation pkgs either, which complicates their distribution in a managed deployment.

So, I dusted off the project, cleaned it up a bit, and added a ReadMe file and a signed and notarized installation pkg. The tool is called utiluti (I am a bit proud of that name).

You can use utiluti to set the default app for an url scheme:

$ utiluti url set mailto com.microsoft.Outlook
set com.microsoft.Outlook for mailto

or to set the default app to open a uniform type identifier (UTI):

$ utiluti type set public.plain-text com.barebones.bbedit
set com.barebones.bbedit for public.plain-text

There are bunch of other options, you can read the details in the ReadMe or in the command line with utiluti help.

The functionality is quite basic, but please provide feedback if there are features you’d like to have added.

EraseInstall application retired

It makes me very sad that the EraseInstall application has been retired.

We built this tool three years ago, mostly because we wanted to learn how to build an app like this on macOS. We think it worked out well. We learned a lot, and are glad the application was useful to some.

Since then, all the people involved in the EraseInstall Project have moved on to other jobs or other responsibilities. Unfortunately, this leaves us with no time or resources to maintain or improve EraseInstall.

The repository and the application will remain available in its current state. There will be no more updates. If someone feels they can take up the project and continue it, please do!

If you are looking for a similar solution, we recommend Graham Pugh’s eraseinstall script.

Thank you, all, again!

Team EraseInstall: Mischa van der Bent, Arnold Nefkens, and Armin Briegel

Transmit 5 for Mac released

Panic has updated their awesome file transfer application Transmit for Mac to version 5.

(Transmit iOS is still at version 3. Available on the iOS AppStore.)

I just mentioned Transmit in my post on Transferring files with SSH earlier this week (I just updated the links in that post).

Also, this version of Transmit is no longer available in the Mac AppStore, adding to the ever longer list of applications that are leaving the AppStore. Panic’s reason is that they want to give users a free trial option.

Things 3 is out!

My favorite to-do-list manager that I keep returning to has gotten the long awaited update!
Things 3 from Cultured Code is out.

I have been using the beta for a while now and just love the application. Things 3 has plenty of features, but also a gorgeous and clean interface.

You can download a trial for the Mac version from their website. You can purchase the Mac, iPhone and iPad versions from the respective AppStores. Currently the app is on 20% introductory sale until May 25.

Check Python Syntax in BBEdit with flake8

There are existing scripts out there that will run flake8 against a python file in BBEdit, but none of them worked quite the way I wanted. So here is mine:

Before you can run this, you need to install flake with sudo easy_install flake8. Then you need to drop this script in ~/Library/Application Support/BBEdit/Scripts. You can launch it from the menu with the script icon.

Start Screen Sharing or Apple Remote Desktop Sessions with Spotlight

Screen Sharing is a really useful tool in Mac OS X. Most people use it locally and select the Computer from the Sharing area in the Finder sidebar. You can also connect Screen Sharing to a remote host. In Finder select “Connect to Server” from the “Go” menu and enter

vnc://host.example.com/

which will connect Screen Sharing to the address. ((It will use VNC on TCP port 5900 in case you have connection issues.))

You could add the vnc URI to the favorites in the “Connect to Server” dialog, but there is a better way: Screen Sharing remembers the last connections in ~/Library/Application Support/Screen Sharing/. There you will find the hosts you have connected to as .vncloc files. Find the host(s) you use most frequently and copy them to the Desktop or your Documents folder. ((anywhere Spotlight will index)) Then rename them to just the hostname or another descriptor. You can now double-click to initiate the Screen Sharing connection. But even better: you can invoke Spotlight, start typing the hostname and the vncloc file should be right there. No matter what you are doing the remote session is just a few keystrokes away.

However, if you prefer to use Apple Remote Desktop over Screen Sharing, this will not work. ARD does not open vncloc files. However, ARD is scriptable, so we can build a workaround. Even better ARD supports Automator, so we don’t even need to write code.

  • open Automator. From the template chooser, select “Application.”
  • add the action “Choose Remote Computer” and select a computer to connect to. ((The computer has to be already known to the local Remote Desktop to appear in this list.))
  • add the “Observe Computers” action next. ((curiously enough there is no “Control Computers” action, but switching from observe to control is only a single click. This may be so you cannot accidentally invoke a remote control session.))
  • you’re done. Save this Automator applet and give it the name of the computer.
  • you can start this applet by starting to type the computer’s name in Spotlight and you will a remote observe session in Remote Desktop.

Create more applets for each host you frequently use. if you select multiple computers in the first action, you will get the nice “multi observe” window in Remote Desktop. Or you can replace the “Choose Remote Computers” action with a “Choose Computer Lists” action.

Automatically connect to Airfoil Speakers

Update: In one of those embarrassing “You know there is a checkbox for that!?” moments, @rogueamoeba points out there is in fact a checkbox for this under Preferences “Automatically Transmit To:”

Airfoil from Rogue Amoeba is a wonderful application that allows you to stream audio from your computer to any device that will receive Airplay audio or run the Airfoil Speaker application. This includes all iOS devices. I use it stream audio to any room I may be in where I just hook an iPod touch or the iPhone up to the stereo.

The one drawback is the UI, which only allows to the devices to stream to on the Mac that is streaming. So I’ll be in the kitchen, where a 1G iPod touch is permanently hooked up to some speakers, turn on the iPod touch, start the Airfoil speakers app, then walk to the Mac in the living room, select the iPod touch in the Kitchen and walk back to enjoy the music. Wouldn’t it be great if Airfoil automatically picked up the iPod when it appears in the list?

Luckily Airfoil has AppleScript support. It is actually very easy. I have named all my iOS device to start with either “iPhone”, “iPad” or “iPod touch” so I can make Airfoil connect to all devices that are running the Airfoil app with

tell application "Airfoil"
    connect to every speaker whose name starts with "iP"
end

Now we need to keep running this command periodically in the background. I could setup a launchd plist for that, but AppleScript provides a simpler solution. Scripts that are saved as “Stay Open Applications” have an idle handler that is called after a certain number of seconds. See the details at the AppleScript Language Guide here.

So we wrap the command in an idle handler and add some checking to see if Airfoil is running so we don’t force launch Airfoil:

property idleTime : 30 -- in seconds

on run
	idle -- call idle on launch
end run

on idle
	tell application "System Events"
		if exists application process "Airfoil" then -- check if Airfoil is running
			tell application "Airfoil"
				connect to (every speaker whose name starts with "iP" and connected is false)
			end tell
		else -- if Airfoil is not running script can quit, too
			tell me to quit
		end if
	end tell
	
	return idleTime
end idle

The value returned from the idle handler is the time (in seconds) until it gets called again. This will leave other speakers (that don’t start with “iP”) such as the local speakers and any Airport Express speakers unaffected.

Save this as an application and make sure to select the “Stay Open” option. Then find the application and double click to launch. Start and quit Airfoil speakers app on your iOS devices and listen to Airfoil connect automatically.