Technology Blog
Version 4.13 of Microsoft AutoUpdate for Mac, released on Tuesday, contains a new Required Data Notice that will pop up immediately upon installation and must be acknowledged before MAU will continue to function.
While the user experience is not great, thankfully Microsoft has provided us a way to suppress the new dialog on managed systems. Read on for the details.
Back in February I wrote about Automating MAU Caching Server with Slack Notifications and it has been working great. Earlier this week a request was made on Github to add support for sending notifications to Microsoft Teams.
We don’t use Teams here at work but a quick search showed it supports messages via an incoming webhook, just like Slack, so I decided it give it a try. It didn’t take long to adjust the code and after realizing I could create a Teams workspace for free I got it tested in short order.
Paul Bowden merged my pull request so if you’d like to take advantage just grab version 2.6 of the MAUCacheAdmin script. If you are interested in the details read on.
Yesterday a colleague on the MacAdmins Slack asked for some help creating a package that would both install and register DetectX Swift (DTXS) all in one shot. He was having trouble getting it to work with Jamf Composer even though a couple of us agreed that in theory his method should be working.
While admins are able to easily register DTXS after installation using management tools, in my case Munki and in his Addigy, the goal was to create a package that could be installed manually by less savvy techs or sporadically as needed via Apple Remote Desktop (ARD).
I had a little time at lunch today and decided to give it a try as a basic package using pkgbuild. Thankfully it worked perfectly right out of the gate, read on if you’d like the details.
To know when Apple releases new updates that are downloaded by my Reposado server I’ve been depending on random checks via Margarita, emails from the Security-announce list or discussions on the MacAdmins Slack. Automating repo_sync runs is easy enough with a LaunchDaemon or cron job, but I want to automatically be notified whenever a new update is detected.
When searching to see if anyone had already done the work I found a script by Michael Stango on GitHub that sends email notifications when new updates are downloaded. Stango’s script even takes things a step further with the ability to automatically add new products to a testing branch. Awesome!
Since I have all my similar notifications (AutoPkg, MAU, etc.) feeding into Slack I wanted to send Reposado notifications there as well. I’ve been testing the updated bash script for a few weeks and am happy to share it, read on if you are interested in the details.
For at least a year MacAdmins have been dealing with Apple security updates failing if they are not installed soon after being downloaded. This is especially apparent to Munki admins who have Managed Software Center (MSC) configured to install Apple updates. Munki will invoke softwareupdate to download updates as soon as they are detected but users can defer the installation via MSC indefinitely by default.
If enough time has passed when the user finally decides to allow the logout / reboot for the update it will silently fail. The computer will reboot and the user will find themselves at the login window thinking the update completed successfully. However an hour or so later softwareupdate will again detect the update, download it and MSC will prompt the user to logout and install the same update they think they had just installed.
This is not a great user experience and has led to some frustration here at the newspaper. I’ve written a script that works around this behavior, read on if you are interested in the details.
Photo Mechanic (PM) has long been the software of choice for photojournalists worldwide. It has unrivaled speed for downloading, sorting and captioning images on deadline. I have been using PM for almost 17 years and it is an essential part in the workflow of our photographers here at the newspaper.
As our staff has grown so has the need to automate installations of software. In the past we simply emailed the registration information for PM to staff as needed. Of course this is an awful practice in regards to securing our paid licenses.
Thankfully we can programmatically activate and deactivate Photo Mechanic when employees install or uninstall the program via Managed Software Center (MSC). Read on for the details.
In the past I have always run MAUCacheAdmin manually. Microsoft Office updates are usually only released once per month so it is easy to know when another run is needed. Plus with no built-in way to move collateral files into the appropriate place automated downloads won’t automatically make updates available for clients.
However with more and more applications becoming Microsoft AutoUpdate (MAU) aware, and out-of-bound patches being released, I decided it was time to automate the checks and downloads to my MAU Caching Server. This is easy enough to accomplish with a LaunchDaemon but I still needed a way to be notified when MAUCacheAdmin found updated packages to download so that I could move the collateral files into place.
I decided to see if I could add Slack notifications and when I began to dig in was pleasantly surprised to see that Microsoft’s Paul Bowden had already coded HipChat notifications. Using that as a base it turned out to be much simpler than I expected to get it working with Slack. Read on for the details.
The topic of wether or not to allow an employee to use their personal Apple Watch to unlock their work Mac is a discussion that has come up a couple times over the years in the MacAdmins Slack #security channel.
When I first saw the subject brought up I hadn’t used the feature myself. At the time I was still maintaining separate personal and work iCloud accounts to keep everything segregated. But since I could imagine receiving a request from users to enable the feature, I decided I had better start testing it out so a policy could be formed in advance.
Apple calls the feature Auto Unlock. I’ve been using it for a while now and don’t see any reason to block it for employee use. Here’s why:
I have been running a Microsoft AutoUpdate (MAU) Caching Server for a couple years now and have always allowed it to download and serve everything, even applications we don’t use. My thinking was that I’d rather have something and not need it, than need it and not have it.
This has never been an issue for older products like Office 2011 and Lync (or even current products like Company Portal and Skype for Business) because combined they are only around 500 MB. The fact that Office 2011 and Lync are no longer receiving updates means the bits on disk haven’t changed in over a year and don’t need to be downloaded with each run of MAUCacheAdmin.
However things changed with the release of Office 2019 last fall. While Office 2011 is no longer being maintained, Office 2016 will continue receiving security updates until October 2020. If you have already transitioned to Office 2019 this means that MAUCacheAdmin will continue to download almost 6 GB of installers and updaters every month that you don’t need.
Thankfully it is easy to customize this behavior so read on if you’d like the details.
During a discussion in the #detectx channel of the MacAdmins Slack yesterday AP Orlebeke pointed out that when registering a DetectX Swift (DTXS) Pro or Management license via the command line it is only applied for users that already exist on the system. DetectX Swift will be in an unregistered state for any users created later.
In the ensuing discussion I opined that: “It would be trivial to whip up a Munki on-demand NoPkg that triggers the command line registration as root if the user ever got in a situation where they were using the DetectX GUI and were unregistered.”
DetectX developer Phil Stokes asked if I’d be willing to create an example so I did just that. Read on for the details.