Operating a large Mac fleet

Your MDM, your purchase records and your list of who has which Mac often don't match. Compare them and look for Macs that were bought but never enrolled, records for devices that are long gone and the same Mac listed twice. Clean up those records before you use a fleet report to decide anything, such as which Macs to replace.

For each Mac, track the macOS version, the essential apps and who owns it. Track where it is too, if your work needs that. Then write down the profiles, scripts and rules you run today. If you move to a new MDM later, this list tells you what already works and has to keep working after the move.

Every group in your MDM should exist for a reason you can name. That reason can be a hardware model, a macOS version you still support, an app a team needs or a stage in a rollout. Write down the criteria that put a Mac in a group or keep it out, and test both on a few devices that look like the rest of your fleet. Watch for groups that overlap. If two policies set the same thing differently, the Mac gets conflicting settings and the result is hard to predict.

Before a change goes to everyone, send it to a small test group. Pick people who use different apps and peripherals, such as docks and printers, so the test covers what people really use. Decide before you start which result lets you move on to the next group.

For every app, write down who owns it, where the licence comes from, how it gets updated and what configuration it needs. Use a distribution route that the app vendor and your MDM support. If an install breaks, you can then ask them for help.

Scripts need more care. Before one goes out, check what privileges it runs with, what inputs it relies on and what it does when a step fails. Then run it twice on a Mac that's already set up. Scripts do run more than once, for example when the MDM retries after a failure, and the second run must not break anything.

When the MDM reports a command as successful, check on the Mac itself that the app is installed, the setting is in place or the service is running.

Decide which macOS versions you support, when updates go out and the deadline by which every Mac must have them. Test the update features your MDM has today, and look at what the person at the Mac sees. Then make sure your support team can see every update that failed and every Mac that can't be reached.

Some Macs can't update on time, for example because an app someone needs doesn't support the new macOS yet. Give each of those exceptions an owner and a review date. The update guide covers what has to be in place before an update and how to plan restarts.

Measure how often setups fail, how many support requests come in, how many update exceptions you carry and how long it takes to get a person working again after a Mac fails. Plan your own staff and any outside help from those numbers. A fixed ratio of devices per administrator leaves out how complex your apps are and what level of support you've promised the business.

Keep track of renewals, such as certificates and tokens, and of who holds recovery access. Write a handover document, then test it. Ask another administrator with the right permissions to run the service without the person who usually does. If they get stuck, fix the handover while that person is still around to answer questions.

Apple Platform Deployment · Software updates