On the topic of deploying a multitude of system agents.

This post is based off a thread in the macadmins slack that it appears no-one has blogged about yet. A heartfelt thanks for those that contributed ideas.

As admins we are often asked to deploy a variety of agents or system extensions onto the computers and devices we administer. These can make sense and often required, for example an inventory service or to meet some security requirement. But sometimes we’re asked to deploy software that has conflicts or duplicated functionality with existing agents with little argument to prevent or at least have a discussion about the reasons or purpose. The classic case is being required to install two or more security products, each of which at best overlap in a large percentage of function or at worst, conflict and fight against each other in a battle of dominance over the device, reducing performance, battery life and the user experience.

As admins, our job is to protect the production environment and user experience of the systems we manage. What follows is a compiled list (in no particular order) of questions and expectations from a number of authors in the macadmin community that could be used the next time some team or higher up wants you to deploy the Next Great Thing™ they saw on an airport banner ad or product brochure.

Considerations before deployment

What’s the plan for ensuring that the latest version of this is always available quickly for deployment?

  • Access to vendor download sites or location where the latest supported version is available for packaging

Can other agents be removed due to duplicated functionality as a result of installing this?

Who is responsible for testing?

  • Ideally the owner of the agent should be involved in testing directly new versions on the latest OSes before rollout to the entire fleet.

For agent related issues, which team is responsible for actioning incidents and requests?

  • What resources are being provided to support the product.

What’s the impact to end user experience with having this installed?

  • What user impact testing has been performed? Has anyone run this for an appropriate amount of time on a daily workstation?

What configurations and exceptions have you come up with to ensure that performance sensitive users are not adversely impacted by its installation?

What features does this agent bring that we do not already have on our endpoints?

Has testing already been done with this agent in combination with all the other ones we have installed?

  • What was the result of that testing and who was involved?
  • Who in the requesting team is running macOS, Linux or Windows as their primary desktop and is going to be in the canary group?

What compliance requirement are being met by the agent?

  • Provide documentation

What’s the history of this product when it comes to timely OS compatibility updates?

  • Does the vendor respond quickly to OS releases or do they lag? By how long, days months years? To they build and test against beta OS releases? 

What technical capability does it add that nothing else does?

What organisational bottleneck does this attempt to work around?

Full configuration information for Group Policy/MDM profiles will need to be provided so that no manual actions are required on the part of users for installation or updates.

Expectations after deployment

If this breaks critical workflows during a crucial time, what’s the process for approval to remove this from devices?

  • Approval or justification may be sought after agent removal.
  • What’s the plan for rolling back when this is panicking/crashing machines?

The team owning this new agent understands that if there is a new OS update and the vendor states that a newer minimum version is required for compatibility for this version of the OS that there is an expectation that this agent (and any associated infrastructure updates) will need to happen in a timely fashion and not be a blocker for rolling out new OS versions?

It is understood that if the agent prevents installation of a new OS update which has high enough severity CVEs for too long, due to -other- compliance requirements for OS updates in a timely fashion, that this product will be removed until it’s compatible again with the newer OS version

  • It is considered more important that CVEs get patched than having this new agent installed.

Things to do with Dialog

It’s been 5 months since the last update. Dialog has learned a few more tricks in that time.

As workflows are capable of getting a bit more complex now, I’ve started a new repository which is going to contain a collection of scripts and is called, unimaginatively enough, Dialog-scripts. The purpose is to provide a collection of workflows that can be freely copied, modified and used as a basis for other workflows, and hopefully serve as a jumping off point for some of the more adventurous things Dialog can do.

One of the more recent ones lets you send scripted updates to modify content without re-launching. Combined with a list view, this lets you show a list of steps and update with ongoing progress. I’ve used this as a basis for the first entry to the Dialog-scripts repo that acts as a user-friendly visualisation of Scripting OS X’s awesome Installomator that takes a list of app labels, then steps through them one by one providing feedback as it goes.

Token Screenshot of Dialog doing things

Feel free to copy, modify, update, provide feedback or suggestions. There will be more to come 🙂.

Dialog is a feature rich open source utility app written in SwiftUI that is intended as a way to provide user notifications and interaction from shell scripts, similar to cocoadialog or jamfHelper. The latest release can be found on the Dialog GitHub page https://github.com/bartreardon/Dialog and also in the Jamf Marketplace 

free Apple eBook Resources

If you’re like me you’re not a huge fan of writing detailed documentation. While not much can be helped with environment specifics, there is a great selection of free ebooks from Apple that covers most of the hardware, OS and application software.

For the last couple of years I’ve been making Apple eBooks available on Jamf Self Service and scoping to particular devices, e.g. everyone with a MacBook Pro gets access to the MacBook Pro Essentials book.

In Jamf Pro, go to to the “eBooks” section under “Content Management”, click the “+New” button and search. Choose “eBook available in the iBooks Store”. You can preview the book in the Books app as well to make sure you have the one you are after.

Useful books that I’ve found (search for these by title or author – Results may differ depending on what store you select, but these are whats available in the Australian Apple Books store)

Hardware “Essentials” series

Great to include for users of that device type, especially if they are moving from one type of device to another or if they are first time Mac users.

  • MacBook Pro Essentials
  • MacBook Air Essentials
  • iMac Essentials
  • Mac Pro Essentials
  • Mac Mini Essentials

“User Guide” series from Apple Inc.

The User Guide series covers non Mac hardware as well as Applications for each platform and how to use them

  • iPhone
  • iPad
  • Keynote
  • Pages
  • Numbers
  • Final Cut Pro

Apple Inc. – Business

The Employee Starter Guides are a good resource to help new users get up to speed with using Apple devices in an organisational setting. While these can’t go into detail about a specific environment, they do provide some more context that is only applicable in those environments, such as Automated Enrolment

  • Employee Starter Guide for Mac
  • Employee Starter Guide for iOS and iPadOS

“Everyone can Create” series from Apple Education

The “Everyone Can Create” series is a great resource that goes into creating music, photos and video as well as some teacher guides

Author Names

Apple have several Author names so it can be useful to search by author to restrict your results.

  • Apple Inc.
  • Apple Inc. – Business
  • Apple Education

Final Words

This is by no means an exhaustive list. Over time the books are updated but rather than update the existing eBook, Apple may publish a new book, for example there will be more than one “MacBook Pro Essentials”. It’s usually easy to tell which one is the latest by the cover.

Dialog 6 months later

How It Started

A bit over six months ago I had one of those bursts of inspiration that only comes at the most inopportune of times. The basis of the idea was to make an app that would display a message to my mac users that looked nice and was customisable with text and images. SwiftUI was on the list of things I wanted to learn and so Dialog was born.

Two days later on the 11th March 2021 the first beta version was released on GitHub as a binary and the following day I wrote a blog post announcing it. The source was released on the 20th after clearance from my employer.

The initial version was fairly basic at the time but did what I wanted it to do. Displayed a window where I could control the title, message, button labels and include an image (or icon). It was one fixed size as I wasn’t up to speed with SwiftUI’s declarative layout style and making it do what I wanted, but it was a start and we all have to start somewhere.

How it’s going

Six months later and I have been nerd sniped with features and created an app that I think does about as much as anyone (a mac admin at least) could want in an app who’s task is to display a message to the current user.

Apart from what it started with, Dialog now displays selectable dropdown lists, has text entry, fully customisable text colours and font sizes, support for SF Symbols as an icon, can display another icon as an overlay to the main icon, built in markdown support, can display arbitrary window sizes, has background images, full screen display mode, can timeout after a specified number of seconds (with a custom timeout indicator because why not), text justification, banner images, can provide json output and last but not least, supports a good chunk of the command line arguments from jamfHelper making it easy to drop in replace and not require an admin to re-write existing scripts (too much…it does it’s best and there are some options not currently supported). All in an app thats fully self contained and less than 2MB in size.

Along the way I’ve learned more about SwiftUI than I thought I ever would and have used what I have learned in other projects, contributing to Nudge v1.1.1 with a refactor in how its layout is presented by SwiftUI and making future support for arbitrary window sizes easier to implement in that utility.

As is evidenced from the progress in Dialog over the last 6 months, I’m more than open to feature suggestions and bug reports. I have no immediate plans to slow down development and with this first SwiftUI app ticking along nicely I have ideas for a few more apps and utilities.

Dialog is also in the Jamf Marketplace where it has been getting a semi respectable level of attention in terms of generating traffic (If you are using dialog, please leave a review) and the latest release can be found on the Dialog GitHub page https://github.com/bartreardon/Dialog-public

If you check it out, please send through feedback or join the #dialog channel on the macadmins slack.


“Dialog” – An app for showing a dialog

Why a dialog app? Two reasons, the tool I have been using to this point was coming up short on some features I wanted to have, and I wanted an excuse to get my teeth stuck into a SwiftUI project. Also, I wanted to finally get around to releasing a tool for the mac admin community that is hopefully useful (I have a number that are useful, just not released)

3 days later…Meet Dialog.

The app has a simple premise, show a dialog with a title, some text, one or two buttons and optionally an image. I took inspiration in the UNIX philosophy of having one tool do one job. Everything Ic can do can be specified on the command line and the app will return different exit codes depending on what action the user takes.

At its most basic, it looks like this:

Which is pretty boring, fortunately you can customise all the options. The three actions a user can take are:
1 – Press the [OK] button (or hit <Enter> on their keyboard)
2 – Press the [Cancel] button (or hit <ESC>)
3 – Press the [More Information] button.
Each action is closes the app with exit code of 0, 2 or 3. The [OK] and [More Information] buttons can optionally also redirect to a URL.

The Title and Message areas can be specified of course. The icon image can be either a jpg or png from a file or a URL. If the image is square (e.g. a jpg) the corners are slightly rounded for a more pleasing look.

Put that together you can make something interesting:

Dialog is only supported on macOS 11 (universal) at this point in time.

To check out a pre-release version, please visit:

Source code will be made available soon. <- Edit: Source is now available as of 20-03-2021

Electron and Squirrel.framework suck…

…your laptop battery and make you fans spin hard if you don’t jump when the updater shows up.

Recognise that dialog? – Many apps pop up the same type, Lock icon with the App icon overlaid and the text “An update is ready to install. <AppName> is trying to add a new helper tool”

Well if you’re lazy and don’t get to it, or it pops up when you’re not at your computer, you may find that the fans in your Mac are making noises. A quick check of Activity Monitor confirm that the app in question is taking up a good chunk of your CPU, but doing what exactly?

Spinning wheels it turns out calling the same method repeatedly as long as the dialog is waiting to be dismissed. https://soundmacguy.wordpress.com/2018/02/25/microsoft-skype-definitely-and-teams-maybe-disabling-automatic-updates/ (thank you to Nathaniel Strauss over on the macadmins slack for pointing this out)

Squirrel.framework is a common update framework unsed in Electron based apps like Atom, Discord, Microsoft Teams, Visual Studio Code and Signal among others. And it has a bug


Not so encouraging though…

So, if you were like me and were wondering why – now you know. If you know anyone that works on Electron apps for Mac and has patched this issue, can you send it upstream please? 👍

Discovering non-native macOS Applications

As was announced at WWDC 2020, Apple will be releasing Macs later this year running on Apple Silicon based on the ARM64 architecture. This transition will hopefully have us running universal applications but also possibly forced to run some intel only apps transcoded through Rosetta 2, depending on vendor support. As a mac admin it might be handy to know how to discover what applications on your systems don’t have a version compiled for ARM (or intel 64 bit for that matter).

This (very) simple script will go though all applications system_profiler knows about and report if the application binaries have no match for the current system architecture:

systemarch=$(uname -m)
for apppath in $(system_profiler SPApplicationsDataType | grep 'Location:' | awk -F ": " '{print $NF}'); do
    apparch=$(mdls -raw -name kMDItemExecutableArchitectures "${apppath}")
    echo ${apparch} | grep -q ${systemarch}
    if [[ $? -ne 0 ]]; then
        echo "${apppath} has no native binary for ${systemarch}"
        echo "${apparch}"

uname -m tells us the current system architecture
mdls -raw -name kMDItemExecutableArchitectures /some/file.app tells us the architecture(s) that the app is compiled for which could be ppc, i386, x86_64 or arm64

Sample output from the future might look something like this:

/Applications/dosbox.app has no native binary for arm64

You could use this as a basis for your own scripts or to perhaps instead check for apps that do match the host architecture or have multiple architectures (aka universal binaries).

Happy scripting.

Shell Junkies – MOTD and SSH banners

macOS presents a wonderful graphical UI but there are times where we log on, copy files or perform other work via the command line over SSH. The default experience for generic logins is rather plain but we can jazz it up a little.

The first is by using the file /etc/motd (or Message Of The Day). This is simply a text file and whatever is in it will be displayed after login. It’s a bit of a misnomer as without anything else the file is static, unchanging file rather than something inherently “daily” but with a bit of imagination one can embellish and update the file on a regular basis. for example:

echo "You have logged on to $(hostname)" > /etc/motd
echo "Today's date is $(date +"%d %b %Y")" >> /etc/motd
echo "The weather for today is: $(curl -s 'wttr.in?format=3')" >> /etc/motd

(A fairly simple script but will do as a demonstration).

  • Save this file to an appropriate location such as “/usr/local/motd_updater.sh“.
  • Set permissions with “sudo chmod 744 /usr/local/motd_updater.sh
  • Create a launchd to run it once a day or whatever schedule you prefer – an example here – and place it in /Library/LaunchDaemons/ and load with sudo launchctl load /Library/LaunchDaemons/com.motd_update.plist (or whatever name you gave it)

Now, whenever someone connects via ssh they will be greeted with the a message that will update daily.

This is great, but a user won’t see the message until AFTER login. What if you want to display a message BEFORE login, such as an Acceptable Use Policy? Fortunately that’s easy enough to do as well as SSHD has a method for displaying a banner on connection. Much like MOTD, the banner is just a plain text file and you can tell SSHD to display it prior to prompting for a password.

For a basic banner, edit the file “/etc/banner” and copy in the following:

  Conditions of Use

  WARNING: Your access to the system must be authorised.
            Unauthorised access may be prosecuted.

  By accessing this system, you agree that:
  - your actions may be monitored
  - you must abide by the MY ORG Code of Conduct and any Acceptable Use Policy
  • edit the file “/etc/ssh/sshd_config
  • find the line “#Banner /etc/banner“, uncomment and save
  • sudo launchctl kickstart -k system/com.openssh.sshd” to restart sshd

Now when someone logs in via SSH, they will see the text displayed in /etc/banner prior to entering their password. Very handy for presenting things like acceptable use policies:

As with /etc/motd, you can modify /etc/banner as you wish with a script or the like to keep it up to date as details change, even splash a bit of colour around with ANSI escape codes. Have Fun.

Adding a JIRA issue collector to Jamf Self Service for user feedback

If your org is one of the many that uses JIRA internally for tracking workflow or projects then you’ll know about issue collectors. I’ve used issue collectors before in munki and my post on that is still available here https://groups.google.com/d/msg/munki-dev/PwvrYaqKxGc/97w7G-USFwUJ

For Jamf Self Service it needs a little bit of extra work as unlike Managed Software Centre there’s not a lot of interface modification you can do. That said, it’s still fairly simple to set up.

Step 1 – create your issue collector in JIRA – consult your jira docco on how to do that but the simplest is to set “Prominent” trigger style and then pick a template. I went with “Custom” and selected “Description” and “Attach File” custom fields. Add an appropriate trigger text and message.

Step 2 – create a page to add the generated issue collector code to. Here’s a template I created earlier:




Save it as feedback.html and place it on a web server somewhere.

Step 3 – We aren’t done yet (believe it or not). We need to add in our issue collector code. Go grab it from the issue collector setting in JIRA and paste it in between <body> and </body> tags. All going well, when you re-load your html file you should have a blank page with a JIRA feedback link at the top like this:

That’s not super ideal though – we want to see the form straight away. A simple way to do this (because JIRA is weird and don’t let you easily just create a blank issue collector page) is to create an onload event and have a snippet of JS click the “Provide Feedback” link for us.

Step 4 – Copy the following into the body of your ever growing html file:

    window.addEventListener('load', function() {

Now if you re-load your page it should pop up the issue collector straight away (bonus points if you have SSO enabled and it picks up who you are straight away – otherwise have a play around with creating an anonymous issue collector):

Step 5 – Now jump onto your JSS and create a new bookmark and link it to the URL of the feedback html (icon shamelessly ripped off from the Apple Feedback Assistant)


Optional – I also created a background image to display on the page so when someone submits their feedback and the form disappears, they see a happy message 😃

Install Microsoft O365 Apps direct from CDN via script in Jamf (or munki for that matter)

Hate trying to keep up to date with Office updates? Couldn’t be bothered importing gigabytes of data into your local software repo? Annoyed that deploying Office via VPP automatically takes ages and is seemingly random? Download direct from Microsoft’s CDN – and do it from a re-usable script as part of a jamf policy or munki no-pkg – and have it update DEPNotify status with a percentage count as it downloads and also as it’s installing. 👍


This is my script and I wrote it for my environment – it comes without warranty but feel free to use it, copy it, modify it, burn it or sacrifice it to the gods. There are bits of this I found on the internet and I can’t remember where I got it from (the pulling % downloaded from curl output) – I’ll update here for proper attribution when I find where I got that….on stackoverflow somewhere.

I use this in my DEP process as I found installing VPP from the app store was hit and miss. It could be re-purposed for self service or some other use. It presumes DEPNotify is already running (which in my case it is)

If you want to try it out, add this to a policy and pass “Word”, “Outlook”, “Excel” or “PowerPoint” as a parameter and it will (should) find the download link, kick off the install and clean up after itself.

Not tested as a nopkg in munki (yet) but there shouldn’t be a reason it couldn’t work with some minor modifications.