Changing Mobile Device Manager (MDM) can be a daunting task. It's usually a heavy investment of planning, testing and communicating before even rolling it out. Once rolled out, it's an iterative process to improve on its uptake.
This being said, there are many reasons to change MDM, especially as more quality competitors enter the space and Apple regularly changes its security and Operating System practices. Staying on top of the best tools for today and tomorrow has never been more important.
Although some MDMs may be mentioned, this article does not aim to be a comparison of products.
Today, we shed some light on processes that remain constant when moving from one Mobile Device Management system to another and hope to assist on your transitioning journey.
How Integrated Is My Current MDM?
Recon of the current system is where you want to start. This doesn't mean looking into how good the Self-Service store looks but rather what is this MDM using/doing to manage the fleet? Crucial to this whole process, things are often missed along the way.
Some MDMs will be able to do their management by simply having Profiles installed and others will additionally have an Agent, or sometimes a combination of both. Additionally, some are quite "sticky" and have settings stored in your Preferences Lists (Plists) and other System folders.
A great first place to check is > System Preferences > Profiles (if nothing is there, then no profiles are installed!). Alternatively (and this can really help with some later steps), you can use the following command:
sudo /usr/bin/profiles -P
Secondly, check Finder > Application for installed Agents. Agents can have a breadth of integration, so it's hard to tell if just removing the agent will suffice.
Thirdly, check to see if the MDM has an Uninstaller that is often found through the portal. It's a download link or a package to download. This can save huge headaches from doing it manually.
Fourthly (?), consider how, and how well, your current MDM pushes Bash Scripts and/or applications.
Lastly, take an inventory of what profiles are currently installed and what they do, either through the MDM portal itself or the installed Profiles. You'll probably want to replicate some of that in your new MDM, take inventory before you "nuke" that instance.
What Are the New Enrolment Requirements?
Although it may seem very simple to enrol a single user to an instance (and they will all advertise how easy it is), the enrolment process is often tailored to two scenarios: the user will enrol themselves via some authentication or you are starting from a brand new fleet with everything perfectly setup with Apple. With even the littlest experience that brought you to this page, you will know that the former is rarely true.
We are then left with figuring out what is required to fully enrol a machine and how do we do it at scale.
Firstly, it's important to know wether your organization is part of the Device Enrolment Program (DEP) with Apple and which Simple Certificate Enrolment Protocol (SCEP) server things are pointing to in Apple Business Manager. Otherwise you're going to have a real bad time enrolling new devices. They will point to the wrong place when trying to enrol. Additionally, any existing device having gone through DEP may always "call home" to the wrong SCEP server.
Secondly, checking for a Security Assertion Markup Language (SAML) connection made to a Single Sign-On (SSO) service for authentication to enrol. Depending on your current environment setup and user capabilities, this might be great or a real setback.
Thirdly, check to see how enrolment can be done. Some things, like Fleetsmith, provide Agents which are generic to the instance and can be great for scripting, albeit with the caveat that it gets them only partially managed. Others, like SimpleMDM, don't offer that luxury and rely more on enrolment links or invitation emails.
Manual Uninstall, Bash Script or Uninstall .PKG?
All three options offer their advantages and their disadvantages. Often, you don't get much of a choice.
Manual Uninstall is probably the most straightforward as you are definitely doing everything using your own workflow. It works but is rarely scalable. This requires figuring out what you need to do locally on a machine and on the MDM portal. Perhaps users can do it themselves, but that raises its own set of challenges.
Bash Scripting is powerful but definitely not as approachable. This requires "Front loading", meaning, you put in the work at the front end of your process to save you time on deployment. This requires a fair amount of research, development and testing.
Also, just because it works on your machine, that doesn't mean it can be pushed to other machines.
Often the easiest is running an Uninstaller, if available. Ideally, it can be pushed as an Application through the current MDM. Alternatively, a bash script that downloads and runs the application is often more straight forward than scripting the process from A-Z. The uninstaller tends to capture those really invasive MDMs. Finding a way to work with it is definitely recommended.
Test Your Solution, Test Again... And Test Again.
Testing is true for more than just scripting. Which ever option you decide on, testing your solution needs to be done under multiple circumstances. You can pull some great insight from UX designers's typical process (below) (Rebeca Costa, JustInMind, 26 March 2019).
At this stage we can assume ourselves to be at the prototyping stage. And more than ever, you need to do a qualitative test by making sure it works. It's imperative your solution removes everything your current MDM has in place and fully enrols your entire fleet into the new one. This is also the stage where you move from "works on my machine" to your scalable environment (ex: pushing the uninstall app through previous MDM).
Past this, it's time for User Acceptance Testing (UAT). Take the time to find users from varied parts of your organization. Additionally and perhaps more importantly, define the feedback you're looking for. As people, we're really good at expressing what doesn't work, but in this case we want to confirm something worked or didn't, in which case you need to express your expectations. Be specific.
Once you've received that feedback, which we will consider as our quantitative testing, it's time to analyze and make the appropriate changes through ideating, prototyping and repeating.
How Much Are Humans Required?
Finally, you've made it this far in this article and in developing your solution, it's time to free the beast! Not yet... If there is one thing that should be taken away from this, it's figuring out the human impact of the solution to the organization.
Poor solutions cost time, effort, money and reputation. It's one thing if your own resources are being used but it's another if it involves everybody in the organization and your Stakeholders will want to know about it. Here's the short of it: define your Stakeholders.
Communication is key, you've taken the steps to test and that should have defined what will be required from users. This starts becoming measurable, which is primo information for your Stakeholders. As a pro project management tip, whatever number you have in mind for metrics, add 10% as a buffer. Better to overdeliver than to underachieve.
Armed with this, it's time to make sure your resources for support are aligned. This means the support team is aware of the potential incoming workload and support articles and support channels are in place. Pick and share important dates, this entails Stakeholder communication, team communication and the organization's communication date(s). Channel your inner oversharer.
You can now communicate this with your stakeholders. With their approval, your team is prepped. It's time to communicate the planned change to your users. Plan for at least two communications dates and, if possible, two communication methods (Email, Slack, organization meetings, leader meetings).
When communicating to users, it's time to practice your empathy and put yourself in their shoes. Users have their own roles and responsibilities, and although important, this change is most likely a backburner item for them and you are asking them a favour (if they are required to follow certain steps).
Think about communicating the time it takes, the clarity of the steps required from the user (if necessary), what changes to expect, the marks of success/failure, where to ask questions before and after deployment and the available support channels.
Specifically to MDMs, some organizations having SSO enabled and sending an invitation email can be a great, fast and easy way to get people enrolled. The challenge then becomes people not remembering their password, a staple of Service Desk. For others, pushing changes and requiring "nothing" from a user is a more viable solution. "Front-loading" tends to pay-off in this step.
This concludes our first post on the high-level steps required to transition from one Mobile Device Management system to another.
In summary, there are five principals: removal of your current MDM, enrolment to your new MDM instance, the available methods of change implementation, testing and more testing, and finally the human impact.
If you enjoyed this read, make sure to stay up to date with our upcoming posts as we dig deeper into each of these sections as a five-part series.