macadmin.fraserhess.com

When I deployed Zoom Rooms on Mac minis earlier this year, I assumed that the built-in automatic update functionality would run as the logged-in user. Our logged-in user for Zoom Rooms is not an admin, so I believed that an automatic app update would either fail or prompt for admin credentials. That would be a bad look, so I built a set of Jamf Pro policies that we ran somewhat manually to keep Zoom Rooms updated. We would also book the conference rooms in question during our maintenance windows.

We had an initiative for next year to bring more automation to this process. However, this week user AaandMAC on Mac Admins Slack pointed out to me that he was using automatic updates and his Zoom Rooms user was not an admin either. I started looking into the built-in feature and found that not only are updates installed by a background process as root, it has a number of advantages over my policy-based approach:

• Zoom Rooms updates can be fully automatic
• They can also be scheduled individually or in batches
• Updates can be scheduled in known maintenance windows
• By default, activity in the Zoom Room will prevent an update – in other words, updates shouldn’t interrupt meetings

This solves a set of problems for us. Jamf Pro policies do not have set schedules. Using built-in updates, we can schedule ZR updates in phases, after hours, without worrying about scheduling the rooms. There’s one disadvantage to this: the Jamf Pro inventory isn’t updated after an automatic update. I solved this by creating a launch daemon that is triggered when the Zoom Rooms executable is modified.

The launch daemon runs a short segment of shell script that performs the following:

1. Because Zoom Rooms automatic updates create a flag file at /Library/Logs/us.zoom.ZoomRoomUpdateRecord before the package is installed, the launch daemon exits if this file doesn’t exist
2. Waits for the Zoom Rooms process (ZoomPresence) to start
3. Runs an inventory command

The inventory command is part of the configuration that creates the launch daemon so it should be adaptable to management systems other than Jamf Pro. Step 1 means that manual updates of the Zoom Rooms app, such as using my existing Self Service policy, shouldn’t trigger another inventory.

You can find the script that creates the launch daemon here. Let me know in the comments if you have success adapting it to another MDM.