How Integrated Is My Current Mobile Device Management solution?

In a recent post, we talked about the five guidelines to a successful transition from one Mobile Device Management (MDM) solution to another. You read it here.

Today, we dive deeper into the ins and outs of your current solution. This knowledge is key towards a successful transition and assessing your next tool.

We will look at methods for exploring your solution, tips and tricks, best practices and some vendor-specific information. With this information, the picture of your project will become clearer.

What Are We Dealing With?

There are three main components to having devices managed: Profiles, Agents and Preferences. Providers tend to offer a combination that, in their eyes, offers the best all-around experience.

Profiles meld security settings, app installation, printer installation, etc. into a set of "instructions" for your device. Device manufacturers define the scope for these instructions through variables presented by MDM providers.

The first profile is a Trust Profile. It connects your device to your Profile Manager and indicates whether further profile installations from the Profile Manager can be trusted. Commonly, a Trust Profile is managed by a Simple Certificate Enrolment Protocol (SCEP) server.

Pictured above is the communication for a new Apple device to get enrolled and have Profiles installed.

When the Device Enrolment Program (DEP) from Apple is paired with Apple Business Manager, your new devices can enrol automatically as their serial numbers are tied to a SCEP server from the time of purchase.

Serial numbers of your current fleet must be changed from one SCEP server to another when changing MDM solution. This is managed through Apple Business Manager.

Agents are installed apps. They have advantages like device data monitoring (battery life, reboot history, etc) and modifying advanced settings as it's further rooted in the operating system (OS).

Being an application, they can manipulate and create files and folders. This makes them more invasive, thus more difficult to remove at times.

As a comparison, SimpleMDM's Agent is removed by deleting it from the Applications folder. On the other hand, Fleetsmith is dispersed throughout the OS and it's best to use their uninstaller (provided through the instance dashboard) to remove it.

We now know what to look for in our current environment. Moreover, we can ask for this information in our vetting process.

Let's Get Technical

Profile Recon.

Profile management is easy to spot. Here are two quick ways to determine if profiles are installed and what they are:

1. Click the Apple Logo (top left corner) > System Preferences > Profiles (If "Profiles" is missing, no profiles are installed)

You can see the different profiles on the left and their attributes on the right. The attributes reflect the settings controlled by your MDM solution.

Profiles can be removed by pressing the minus button (-) in the bottom left corner and entering Administrative User credentials.

Although user friendly, this solution of removal is rarely scalable as it requires considerable user input.

2. Alternatively, you can access this information via Terminal by launching Finder > Applications > Utilities > Terminal.app and typing sudo /usr/bin/profiles -P

The profileIdentifier attribute for the entries is a key component as it is unique and static to that profile. This makes it scalable through its use in scripting.

Profile Removal Using ProfileIdentifier

Staying on theme of transitioning from one MDM solution to another, Apple does not allow for two Trust Profiles to be installed simultaneously. Therefore, script the removal and the addition of the new profiles in one script. Aim for a fast switchover to avoid the reinstallation of profiles when the device checks in with the current MDM solution.

If possible, add #!/bin/bash at the beginning of your script. Most MDM solutions provide Bash script pushes ran as Root user.

You can remove all profiles by using sudo /usr/bin/profiles -D  but this will require a second confirmation by a Y/N key input, making it challenging when scripting.

Using /usr/bin/profiles -R -p and specifying the profileIdentifier works instantly.

To assist you further with Profile commands, we recommend visiting this page by Krypted. It provides fantastic fundamentals with great explanations on each command's use.

Removing Agents

Agents are trickier to remove, due to their invasiveness. We'll look at two ways to approach this: Install an uninstaller (the irony) or remove all the files individually.

1. (Recommended) Running an uninstaller will depend on the MDM provider. Fleetsmith has a practical uninstaller that is generic and runs without prompts. The goal becomes scripting the download and running the Uninstaller.

First, get the Uninstaller into storage that allows for a downloadable URL (sometimes provided by the MDM). Then, you can call for it using Curl. I mention Curl as opposed to wget commands as the latter requires additional installs on Mac OS.

Curl -o (case sensitive) downloads the file from a URL to a specified destination. Its format is Curl -o DESTINATION URL

Ex:Curl -o /path/to/download/dest.ext https://url.of.the.uninstaller

You can add -L before the -o to account for redirects. You can learn more about Curl syntax here.

2. (Optional) Removing an Agent manually can be a challenging task that may work better with some MDM solutions than others.

Firstly, to remove the agent from the Applications folder, the following commands should do the trick:

mdfind -name [application name]

sudo rm -rf /application.app

As a reminder, most MDM solutions run scripts as Root user, making the above possible without user input.

Secondly, look in some of these places for additional files:

/Applications/[Application]
~/Applications/[Application]
~/Library/Application Support/[Application]
~/Library/Preferences/[Application]
~/Library/Caches/[Application]
~/Library/Containers/Application]
~/Library/LaunchAgents/Application]
~/Library/PreferencePanes/[Application]
~/Library/Saved\ Application\ State/[Application]
~/Downloads/[Application]
/System/Library/LaunchDaemons/[Application]
/System/Library/LaunchAgents/[Application]

With the location in mind, you can remove files using rm before a file location.

Ex: rm~/Library/Application Support/[Application]

Below is a snippet of a recently used script:

launchctl bootout “gui/${LOGIN_UID}” /Library/LaunchAgents/com.MDMNAME.* &> /dev/null
launchctl unload /Library/LaunchDaemons/com.MDMNAME.* &> /dev/null launchctl unload /Library/LaunchAgents/com.MDMNAME.* &> /dev/null
pkill MDMNAME &> /dev/null
pkill MDMagent&> /dev/null
pkill MDMupdater &> /dev/null
rm /Library/LaunchDaemons/com.MDMNAME.* &> /dev/null
rm /Library/LaunchAgents/com.MDMNAME.* &> /dev/null
rm -rf /opt/MDMNAME &> /dev/null
rm -rf /Applications/MDMNAME.app &> /dev/null
pkgutil --forget com.MDMNAME.agent

The commands removed the Agent application and other files but the removal of Profiles is still required.

To avoid re-enrolment with re-installation of everything, remove the device from your MDM's Dashboard and the Serial Number from the SCEP server.

What's Next?

You've developed the tool to remove your current MDM solution. The next logical step is to install the new one. But before taking that on, there are four items to check off your to-do list.

1. Ensure the script is delivering the expected outcome. Run your Recon. commands again. Double check documentation and support sites for anything that might have been missed.
2. Test your script from the final distribution point. From our experience, adjustments will be required. Test it before you add additional tasks to your script to filter troubleshooting later.
3. Take inventory of your current profiles and what they do. Documenting which profile is responsible for what will help when you're troubleshooting the removal of profiles.
4. Finally, check for FileVault management. Traditionally, the FileVault key is stored with the MDM provider. Check how best to transfer FileVault keys or look into other storing solutions.

The MDM landscape is changing at a rapid pace and taking the time to understand how they work is key. With Apple pushing end user management rather than remote management, we are regularly subjected to change. We strongly encourage you to document your environment using the suggested reconnaissance steps and to devise a change-over plan regardless whether you think you'll need it.

Stay tuned to our Blog for parts two to five of this series. Up next: The Installation of a New MDM Solution.