Using a mobile device management tool to deliver and enforce policies is like managing a second grade class.
Students in a given class fall into two major groups: boys and girls. But anyone who has managed a class of second graders will tell you that that difference can cause you to pull your hair out. The mobile devices in most organizations also fall into two major groups: Android and iOS devices. But mobile devices -- and kids -- are all a little unique, and each will respond to rules or policies a little differently.
Blame devices for MDM shortfalls
The majority of devices in the enterprise today run either Android or iOS, with some BlackBerry and Windows Phone devices thrown in. The biggest issue with enforcing MDM policies on all these devices is that there are minor differences between each platform and OS version.
You have to recognize and accept that iOS devices don't typically support MDM-controlled encryption. And different versions of Android handle app restrictions differently. For example, if you were to use an MDM tool to prohibit workers from using Google Play on their Android devices, this action would manifest itself differently depending on the version of Android. In Ice Cream Sandwich, Google Play still appears in the app drawer when it is restricted; workers just won't be able to use it. In Jelly Bean, Google Play will likely be completely hidden from the user.
But administrators also have to take carrier-skinned Android devices, jailbroken iPhones, rooted Android phones and custom ROMs into account. All these variables make it difficult to tell which policies will work on which devices.
What you can do
There are probably smartphones, tablets and laptops that you'll want to enroll in your MDM, so before you begin the process of selecting a vendor, your first step should be to inventory what devices you want to manage. Smartphones are one thing, but once you start looking to enroll tablets and laptops, MDM vendors have sporadic support. For example, some MDM tools can manage Windows laptops, but not Macs. Others don't understand the difference between Windows 8 Pro on a tablet and Windows RT.
If you thought you were going to be able to implement MDM, apply policies to devices and then walk away knowing all your devices were under control, you have been misinformed.
Once you've selected your MDM tool, gather a few test devices and review your new platform's default policies for each type of device. In my experience, most vendors' default policy is pretty benign and amounts to little more than an occasional check-in to inventory the device. But resist the urge to customize the default policy until you are comfortable adding and removing devices and handling basic administrative tasks. A lot of admins jump right in and promptly find themselves frustrated by what seems like unpredictable behavior. For example, policies you've created are being applied to some devices but not others. Though this might seem like a glitch, it's actually a gap in your knowledge of MDM.
Beef up your MDM knowledge
If, after first deploying your MDM agent, you try some of the "fun" features in your MDM tool, such as geolocation, selective wipes, remote locking and making phones vibrate, all those tasks will get pushed to devices. This might give you the impression that all policies are pushed out that way, which isn't the case.
In most cases, the MDM agent works on a heartbeat model. It reaches out to the management platform and says, "I'm here! Do you have any new policies for me?" When you created your new policy, your system likely didn't push the policies to enrolled devices immediately. It waited for the phones to check in. This is why some devices may appear to have the policy ahead of others.
Finally, the hardest part of deploying an MDM tool is actually getting the agent on users' devices. There are two reasons that this is an issue. First, most MDM tools can send an SMS text or email (or both) to users telling them how to get the MDM app from their device's app store. Your MDM tool might also send an email with an organization number and credentials that users will need to enter for MDM to work on their devices. This process can be confusing for users, and unless you plan to have the IT department install the MDM agent on every device, you should be able to clearly explain the process in terms your users will understand.
The second problem is that the warning that will appear on users' devices once they're enrolled in your MDM tool can be scary. It basically says, "This app requires permission to monitor your device and destroy it, if your IT department wants to." I would like to tell you that the message will be in techno-speak and your users will ignore it, but the warning is in plain English, and some of your users won't like it. It's a good idea to prep them about the warning and make sure they understand why the IT department might need to use the various features that come with MDM tools.
In school, the best teachers are the ones who can balance rules, individual attention and tolerance for the things they can't change. Approaching MDM the same way can put you on a path to success.
This was first published in February 2014