Published: April, 2020
Mobile device management (MDM) is a high-stakes proposition at Cisco, where employees use nearly 60,000 personally owned devices. Every activity allowed on company-owned devices is also allowed on supported personal devices, including mail access and connecting to applications hosted in our data centers or in the cloud. If unauthorized devices get access to company data and applications, we risk security breaches and infections. Conversely, if authorized devices can’t get access, employees can’t do their work and Cisco IT is bombarded with support cases. You can read about our BYOD security architecture here.
When the MDM platform we’d hosted in our data centers for more than 12 years reached end of life, we carefully compared five leading platforms to replace it. Our choice: Cisco Meraki Systems Manager (SM). As a cloud solution, Meraki SM eliminates the need to buy and manage infrastructure. It provides the core capabilities we need, like remote device locking, device wipe, application management, certificate management, and self-service PIN changes. And a rich set of APIs lets us integrate Meraki SM with other applications and automate much of the self-service setup process. User self-service enrollment is a must-have when you have as many mobile devices as we do.
During project planning, the Cisco IT product owner and a dedicated user experience designer kept the focus on the user experience. For example, they thought about security and data privacy from the user’s perspective. Personal data privacy is a legitimate concern when your employer manages your device, and to ease user concerns we clearly state what we can and cannot see and do with the device and data before the setup process begins.
After building a prototype we conducted a 20-user pilot. Our goal for the pilot was making sure users could easily self-enroll new devices and switch enrollment of their existing devices to Meraki SM without having to delete and then re-install existing work apps. We aimed for a process so simple that users didn’t need instructions.
Here’s what we came up with. We asked pilot users to download the eStore app (our IT services catalog). When opening this, step-by-step prompts guided the user through the process, agreeing to usage policies, and confirming the Cisco apps to be installed (email, Cisco TV, etc.). Users whose device was already enrolled on the old platform were asked, “You had these apps before. Do you want to keep the same ones?” This spared them from having to download the apps all over again. The whole enrollment process took 15 minutes.
Based on user feedback during the pilot we made adjustments to the eStore app and Meraki SM settings to fine tune the experience. Mostly, this came down to clarifying certain guidance instructions and some optimizations in the flow that users followed.
We use APIs extensively—to scale and to adapt Meraki SM for our operational environment. As Customer Zero for Meraki SM, during the pilot and beyond we worked closely with Meraki to suggest new API calls and optimize the number of calls. Our end-to-end setup process requires just 3-6 calls per second, thanks to batching and throttling. Daily reporting uses a lot more API calls. Reporting on 60,000 devices involves a lot of data, so controlling how and when APIs are called is essential to avoid rate-limit errors that can slow down self-enrollment for users. When we told Meraki about our concern, they created new APIs that pull production data for all managed devices rather than for each individual device, significantly reducing the number of API calls needed for daily reporting.
During the pilot we also optimized the number of API calls used for app updates. Since the same number of calls are needed to push an update to one user or many, we decided to push updates to groups of users. From the console we select the app to update and whether the update applies to all devices, all entitled devices, or all devices with the old version installed. (Entitled devices are the ones that belong to people allowed to have the app, whether or not it’s currently on their device.) We typically select “all devices with the old version installed”—both to minimize API calls and avoid cluttering users’ devices with unused apps and notifications about those apps.
After the pilot we began migrating our users’ 50,000 personal iOS devices to Meraki SM. On their device, users open the eStore app and are prompted step-by-step to enroll the device in the new management system.
The tricky part is motivating users whose devices are already enrolled with the old system to take action. There’s no natural incentive because the key advantages of Meraki SM—no infrastructure to buy or manage, no software upgrades or testing, etc.—benefit Cisco IT more than end users.
Here’s how we did it. We created a policy in the old MDM platform that updates the existing eStore app on a user’s device. At the same time we conducted an email campaign asking users to upgrade to the new device management system. The email asks the user to open the new version of eStore recently installed on their device and take the next 10-15 minutes to enroll the device in the Meraki SM platform. When they open the eStore app they’re guided through the set up process step by step. As part of the process they agree to the end-user license agreement and acknowledge what data Cisco IT can and cannot access when a device is under management. This disclosure helps us maintain users’ trust, and we’ve received a lot of positive feedback about it.
While we can’t move the device to the new management system on behalf of our users, we designed the self-service enrollment process to be simple and fast. For instance, we automated un-enrolling the device from the old system and enrolling it in Meraki SM. That process is completely hidden from the user. Similarly, apps on the user’s device that were managed under the old MDM system are automatically moved over to Meraki SM management. This saves users from having to delete each of their business apps and then download them again. At the end of the self-service enrollment process the device is managed by Meraki SM—and the user has the same business apps as before.
Like many enterprises, Cisco IT uses certificates for activities like VPN access. We operate our own certificate authorities (CA) and need our management systems to be able to work with them. As Customer Zero, Meraki worked with us to make certificates customizable, with options to support services such as VPN access and integrate with third-party CAs.
We use the Meraki SM web-based console for app management, operations work, and Tier-3 support. IT staff members are assigned different privileges based on whether they work with data, devices, or security. Some people can view and change settings and devices, for example, while others can only view them. For more granular permissions, we use Meraki SM APIs to create customized viewers. For example, to protect user privacy we created a viewer for Tier-1 support staff that displays a subset of user and device data that appears on the full Meraki SM dashboard.
By the end of February 2020 we’d moved 37,000 iOS devices to Meraki SM. About half of those are devices employees acquired after we started using Meraki SM. The other half are existing devices that employees moved over to the new platform using the self-service enrollment process. To migrate efficiently at scale we did it in batches, starting with 50 users, then 200, 500, 1000, 2000, 5000, and 9000.
The metrics point to high user satisfaction. Only 1.6% of users needed support during self-service enrollment, far below what we’ve seen for similar transitions in the past. Of 37,000 devices transitioned to Meraki SM, only 20 required Tier-3 technical support. And 88% of users gave positive feedback on the experience immediately after enrolling their devices.
We finished our iOS device migration and started our Android device migration in March 2020. The old system will go offline for good in April 2020.