Implementing a Distributed MDM for a Multi-Site Nonprofit Environment

This documents how we designed, deployed, and maintained a distributed Apple MDM environment across multiple campuses in a nonprofit organization. The environment included staff devices, shared iPads, check-in stations, and location-specific operational constraints — all managed by a very small IT team.

The goal was to create something automated, repeatable and easily supportable by a lean team.

The Problem:

Before the implementation, there were several issues that made device management inefficient and risky as the organization grew:

1. Macs and iPads were set up by hand - Every device we order whether it's for a staff person, a shared device, a POS system, a check-in system passes through IT before getting deployed. Which means, time spent creating an admin profile, creating a user profile (with a password), installing printers, software, etc. Then it gets shipped to the specific campus where it's needed.
2. No standardized enrollment process - To be fair, there wass a standard. It lived on Google Keep. It had what needs to be installed and how it's supposed to be configured.
3. Configuration drift and security risks - Users don't update the OS, they install weird software/malware, install questionable chrome extensions, etc. Security settings varied from device to device. Non of it were malicious, it was simply a result of unmanaged endpoints in a real world environment.
4. Offboarding and Asset Management was messy - When staff left, we don't know where the machine is or the machine needed to come back to a central location to get wiped and redeployed. We don't know what assets we had and where. People would get the devices and use it for themselves because it may be "newer" than what was deployed to them.
5. Activation Lock Friction - This was a recurring operational problem. Devices were often left signed on to personal Apple IDs which meant IT had to contact former staff to get it released which causes redeployment delays and sometimes devices were effectively unusable until unlocked.

The Solution:

With the problem being defined, we wanted a solution that fits the organization's current need while also being flexible enough to scale.

Why Mosyle?

In a previous role, I had deployed Jamf to solve many of the same challenges. At the time, Jamf was widely regarded as the best Apple MDM solution available, but it came with higher cost and operational overhead, including on-prem hosting.

For this environment, we evaluated several options:

• Apple Business Essentials
• Jamf (cloud)
• Kandji
• Mosyle

Mosyle quickly emerged as the best fit. While Jamf remained a strong option, Mosyle offered a similar feature set at a lower cost. Apple Business Essentials was less intuitive for our needs, and Kandji’s interface felt closer to Apple Configurator, which didn’t align with our desired workflow.

The approach:

I designed the MDM strategy around a few core principles:

1. Automated execution
   - Devices enroll automatically (ABM + MDM)
   - Profiles are automatically applied based on device and location
   - Software gets installed
   - Security settings enforced
   - Devices shipped directly to the campus
2. Avoid policies that generated helpdesk tickets - Restrictions were evaluated not only for security impact, but for how often they disrupted users or required IT intervention. Policies that created frequent tickets were reworked or removed.
3. Assume devices will get lost, damaged, replaced, reassigned - We needed to have the ability to lock down a devices that gets lost or stolen, the ability to unlock activation lock and do re-enrollment or reassingment easily

The current core stack:

• Apple Business Manager (for ownership and enrollment)
• Mosyle (for Apple MDM)

Enrollment was standardized through ABM, while configuration profiles were scoped based on device type and use case.

What worked well:

Several things paid off pretty early on:

1. Zero touch deployment drastically reduced set up time
2. Standard security baseline improved consistency
3. Remote remediation became possible without user disruption
4. Offboarding got a little bit easier
5. Asset management got a bit easier as well

What didn't work:

Not everything went according to plan:

1. Some restrictions were too aggressive early on
2. Some legacy devices were not on ABM and had to be enrolled manually
3. Location based printer driver installs didn't work as expected
4. Screenconnect permissions required user intervention

Future improvements:

• Centralize identity (SSO, Google Workspace, Azure AD) we're still deciding
• Use role-based profiles instead of one-size-fits-all policies
• Better asset management (perhaps going to another platform to include Windows devices).

If I were starting over:

• I would plan and document the decision-making process better
• I would include the centralize identity/role-based profiles early in the process
• I would have clearer internal communication about the upcoming changes

Conclusion:

Overall, the implementation went smoother than expected. The rollout followed the natural device lifecycle rather than forcing a hard cutover. While a small number of devices still require manual enrollment or remain unenrolled, the foundation is now in place for a scalable, supportable, and resilient MDM environment.