I was confident that the profiles and scripts I’d created for our Intel Mac Minis would work a treat on the new M1 machines, but I decided to test that theory out using an M1 MacBook Air we already had. As a result, we are soon replacing them with shiny new M1 Mac Minis. However, these machines are the 2014 model Mac Mini, and are relatively old by now. Overall I was impressed at how useful it was. After a little bit of testing on a machine I had at home, and setting up some DHCP reservations for the machines, this solution worked incredibly well. Fortunately, we could enroll them in Jamf School, and use the new Auto-Advance functionality in macOS Big Sur to have them automatically configure themselves after we erased them remotely using eraseinstall. This process was complicated a little by working from home, and the fact that these machines are installed in a datacenter far from my house. Because spring has sprung, I recently decided to do some spring cleaning, and start from scratch. Each node is also configured slightly differently, so we can’t make a lot of assumptions about how each one is set up. These runners were configured a while ago now, and some of the configuration on them is undocumented. Every night, one of these runners gets picked to run AutoPkg against all of our recipe overrides, picking up any updates available for the software in our software catalog. In our environment, we run a handful of Mac Minis as build runners for our Autopkg infrastructure. Hopefully this is something that is patched in a future release. At the time of writing, this issue was present on the latest version of Jamf School (9.1.17) and all preceding versions.
0 kommentar(er)
