Troubleshooting “zsh: operation not permitted”

Posted on August 19, 2021 by alanysiu

If you try to run a script from the Terminal in macOS, you may get an error that says zsh: operation not permitted. As of this writing, the top Google search results for that all point to needing to grant the Terminal full disk access (either via System Preferences > Security & Privacy > Privacy > Full Disk Access or via MDM-delivered PPPC profile. If that works for you, great! But it could also be that there is an Apple quarantine extended attribute on your script. Now, of course, don’t take that extended attribute off if you don’t trust the


WWDC 2021 announcements for Mac admins…

Posted on June 9, 2021 by alanysiu

This fall, Apple is going to release its newest OS: macOS 12, Monterey. With that, there are some major improvements to Mac management that were not in Big Sur. Here are some highlights… From What’s new in managing Apple devices System Extensions removal With Big Sur, there were some fairly complicated digital gymnastics you had to perform to script uninstalling system extensions. With Monterey, things will supposedly be simpler, as removing the payload will also deactivate the system extension without prompting for a password. The ability to use a “firmware” lock on Silicon Macs Apple isn’t calling this a firmware


Command to add a secure token to a macOS user account

Posted on May 12, 2021 by alanysiu

If you run sysadminctl -secureTokenStatus firstuseraccount and see a secure token is enabled for that first account but run sysadminctl -secureTokenStatus seconduseraccount and see a secure token is not enabled for that second account, you can try adding a secure token to the second account, so it can turn on FileVault or become a FileVault-enabled account. Try logging out of the second account and logging into the first account, and then running this command: sudo sysadminctl -secureTokenOn seconduseraccount -password - -adminUser firstuseraccount -adminPassword - You should be prompted first for the password to the first account, and then for the


“Invalid Message – The message could not be parsed.” with Jamf Cloud

Posted on May 5, 2021 by alanysiu

Invalid Message - The message could not be parsed. is an odd error message for a jamf recon when you’re using Jamf Cloud, because if you Google that error message, there are only two results: FYI – Invalid Message – The message could not be parsed. Devices not updating inventory (Invalid Message – The message could not be parsed) The first is for on-premise Jamf and involves fixing a distribution point setting. The second tries to get some diagnostic data but then doesn’t actually give a solution. But what if you get that message, and you’re using Jamf Cloud, not


Why don’t Mac admins use MDM for Apple software updates?

Posted on April 28, 2021 by alanysiu

Context People who administer Mac deployments at a large-ish scale (hundreds to tens of thousands—i.e., large enough that you have to automate things and can’t physically touch every machine to change settings or install updates) generally want to be able to patch software and macOS while giving a decent user experience. I think you’ll find the vast majority of Mac admins (at least the ones on the MacAdmins Slack) don’t use MDM commands to install Apple software updates. What we used to be able to do was use the softwareupdate binary to script installs of software updates, but Apple’s made


Making sharding work with Munki catalogs in mind

Posted on March 31, 2021 by alanysiu

Some Munki admins use sharding to roll out to various portions of their fleet. Most versions of sharding create a random-looking (but not actually random) integer either between 0 and 99 or 1 and 100 that is based on a hash of the Mac’s serial number. Where that can be tricky is when you want to use it in conjunction with catalogs, which you likely do, especially if you have a catalog for early testers and one for VIPs or C-level execs. I’ve created a fork of munki-facts-conditions with a you can adapt for your own situation, based on


Copying the Rosetta 2 installer for offline installations

Posted on March 24, 2021 by alanysiu

I honestly don’t know why this gets asked about as often as it does, but I’ve seen several instances in which Mac admins want to know how to get the Rosetta 2 installer .pkg to be installed offline. The installer is about 6.2 MB, so I don’t think bandwidth is the issue, but maybe it is. In any case, if you have a Silicon-chip Mac with an active Internet connection, run softwareupdate --install-rosetta --agree-to-license to install Rosetta 2. Then, run grep "RosettaUpdateAuto.pkg" /var/log/install.log to find where the installer downloaded to. The location will likely be something like /var/folders/f5/_hdu19hcuin1ckjnqkjcndwkcnadskjnckjqwn/T/OAHSoftwareUpdate/RosettaUpdateAuto.pkg. Go to


Chrome mid-update versions and Munki

Posted on March 17, 2021 by alanysiu

Most of the time, if you want to patch Chrome using Munki, you just use add Chrome as a managed update or managed install to the relevant manifests in your Munki repo, and then have the AutoPkg Chrome.munki recipe import the new version of Chrome into your Munki repo from time to time (daily, weekly, etc.). And, most of the time, that isn’t an issue. Munki checks to see if the Chrome installed is the latest version, and then prompts to update if the latest version isn’t installed. That said, if Chrome is the primary browser your user is using,


Using a nopkg to “nudge” in Munki for Silicon Macs

Posted on March 10, 2021 by alanysiu

Context This is really just a proof-of-concept, but as of this writing both Nudge and Munki use the softwareupdate binary to try to download updates to see what’s available. With the Silicon chip Macs, Apple has now made it so that softwareupdate will prompt you for a password for downloading pending updates, even if you’re running as root. I strongly suspect both Nudge and Munki will move to some kind of model by which they either use an alternate method to determine which updates are pending (defaults read /Library/Preferences/ RecommendedUpdates isn’t always reliable, unfortunately) or will just ask that you


Conflict 409 Error: Duplicate alternate MAC address for Jamf API call

Posted on March 3, 2021 by alanysiu

Acknowledgements Major shoutout to Ben Toms from the MacAdmins Slack for pointing out what the issue is. The exact error message If you have a script that doesn’t return the actual response but just gives you an error code, you may get an error code of 409. If you Google something like 409 conflict jamf api, you’ll get a whole bunch Jamf Nation threads indicating that the 409 error comes up because your Jamf API account doesn’t have the correct permissions or you’re trying to update something to have the same name as some other thing (policy, profile, etc.). If