iOS-based devices: Zero-touch management essentials

Managing multiple devices can be a full-time job. With a few tools in your arsenal, you can optimize mobile devices for zero-touch management.

Businessman touching tablet and laptop, managing global structure networking and data exchanges customer connection on workplace. Business technology and digital marketing network concept.

Image: ipopba, Getty Images/iStockphoto

It's no mystery why Apple's mobile devices have permeated into just about every workspace and industry. Initially hailed as a consumer device, the iPhone and later the iPad began to appear in meetings for note-taking, on-the-go conference calls, as a virtual assistant belting out reminders, calendar alerts, and as our digital rolodex for contact management. 

SEE: iPhone 11: A cheat sheet (free PDF) (TechRepublic)

As battery life grew and the underlying technology matured, the services surrounding this platform exploded to provide iOS capability and support. Fast forward several years and Apple-developed frameworks now allow IT to manage these devices from end to end as one holistic process or granularly based on specific applications. IT can also limit iOS devices to specialized sets of commands that work to manage only data containers housing company data while leaving personal data untouched.

There are several components that build on one another, like layers of a cake, to provide the infrastructure necessary for enabling zero-touch management. There is no one killer application or service that does it all, but rather a symbiotic environment that must exist to ensure that iOS devices are supervised and managed accordingly. I'll identify the different components, explain how they work, and how they integrate into the overall scheme.

Before we jump into the thick of it, let's define mobile device management (MDM) terms that will be used throughout this article.

The MDM terms you need to know

Managed devices have been enrolled as part of an MDM server or service. The enrollment process involves installing the server's management certificate on the device, and enabling the device to trust the server to make changes on the device through the use of commands and profiles.

Unmanaged devices are not enrolled with the MDM server, therefore changes made to the devices must be done manually by the devices' users. This includes installing applications, changing settings, and manually configuring functions. Unmanaged devices can be enrolled with an MDM manually through a user-enrollment profile, often either sent as a message to the user's email or through the MDM server's portal (if enabled).

Supervised devices are typically company-owned and have been provisioned by IT. Certain features within the frameworks Apple creates and updates over time are allowable only on supervised devices.

Unsupervised devices are client devices that have not gone through either on-boarding process. These unsupervised devices may still be enrolled with an MDM; however, certain supervised-only features will not be configurable on unsupervised devices, such as enforcing passcode restrictions, and blocking, or allowing certain apps to run. Unsupervised devices can be made supervised through the provisioning process, which wipes the device of all its data and factory resets it before enabling supervision mode.

SEE: Apple iPad (7th generation): A cheat sheet (free PDF) (TechRepublic)

The following components are required for all zero-touch environments to function flawlessly.

Device Enrollment Program (DEP)/Apple School Manager (ASM)/Apple Business Manager (ABM)

DEP was the management website designed by Apple that allowed corporate customers to add the company-owned devices' serial numbers into a database and link those devices to the company's MDM server. While the process is still called DEP, the program has been revamped and divided into two similar but separate websites: ASM and ABM.

ASM is geared toward educational institutions from K-12 to higher ed, while ABM is aimed at businesses. Though the product has changed, the implementation process is still basically the same: Add your company-owned devices' serial numbers to the online database so during the activation phase of setting up a device the iOS client will contact Apple's activation servers and query the database, locate a match for the serial number, and automatically direct the device to obtain its remote management configuration profile from the MDM server linked in the account.

Volume Purchase Program (VPP)

VPP is another Apple program that is set up per company in order to facilitate the corporate-wide management of application purchases, licenses, and downloads from Apple's App Store. Any purchases made through the VPP--whether they are paid or free apps--can be linked to any existing sites created within DEP/ASM/ABM based on license counts. These licenses may be transferred between sites within the same organization and recouped in the event that devices are decommissioned, bringing the licenses back to the central store for redistribution. When linked to an MDM server, the VPP-licensed apps appear within the server's management console, allowing you to determine how to deploy the apps to managed devices. With VPP, the MDM has full control of managed applications.

Apple Push Notification service (APNs)

APNs is the communication service that sends and receives information to and from devices and Apple services and is used by the MDM server as well. Apple requires an APNs certificate to be created before notifications can be used. 

The MDM features and best practices you need to know

Many MDM solutions are designed squarely for Apple devices for organizations of all sizes and budgets. I will highlight a few of the more popular features to look for when researching an MDM platform that suits your organization's needs.

All MDM platforms follow the frameworks designed by Apple; the frameworks are essentially what actions are permissible by the MDM on client devices. While the frameworks are based on Apple's standards and will be the same across the board, not all MDM solutions support all of the available features the frameworks allow--so, at a minimum, an MDM solution should support all of the available frameworks for maximum compatibility and support.

Zero-day support for new features is also important. Apple controls the frameworks--not the MDM vendor--but the vendor can choose when to update its platform to incorporate new features. Zero-day support means the vendor makes new features available with the latest release of iOS. This will ensure your MDM solution is ready for the latest features, even if your client devices haven't made the leap.

Scale and resources

This is more of a general server best practice than an MDM feature, but I'd be remiss if I didn't mention it since I've seen this haunt organizations time and again, especially as they grow.

Many MDM solutions are cloud-based, a few are on-premise, and even fewer offer both. Either way, the MDM software runs on a server, and these client devices will be phoning home periodically to get updates, perform inventory, and receive commands. But if your server cannot handle the requests, it can result in delays to the services as they're being deployed. Some delay is understandable, especially with cloud-based solutions or requests being pushed to large numbers of devices at one time, but delays that span hours, days, or longer are a big problem. If the reason for these delays is that the server is starved for resources, the only thing that will likely correct the problem is upgrading the server, and that could be costly.

Pre-enrollment configuration

After setting up your MDM server, you can add a pre-enrollment configuration. For supervised devices, for example, you can stipulate a naming convention and whether the MDM profile can be removed manually. This, and other preliminary configurations, may be attached to the pre-enrollment or pre-stage configuration to ensure that newly enrolled devices get identical settings.

Configuration profiles

This is MDM's bread-and-butter: Configuration profiles are where settings can be managed, restrictions enabled, and more. Policies can be deployed governing everything from email access to Wi-Fi network connections to limits of what end users can do with a device. Configurations are typically created and then assigned to devices, either individually or as part of groups. 

Scoping and targeting

This is a best practice in general management. Scoping or targeting involves grouping together the devices that will have commands sent to them. This is an important part of the management process. As the number of devices being managed grows, it becomes harder to keep up with the one-offs. 

SEE: Bring Your Own Device (BYOD) Policy (TechRepublic Premium)

Administrative policies

I won't go into how to create policies for your organization to follow; instead, I will touch on some of the common occurrences that will benefit greatly from having policies in place.

Update/upgrades policy: IT is in charge of introducing new code to the system we manage every time updates or patches are pushed out. A policy that explains how to handle updates and allots for a testing window prior to production deployment can guide you when a new release is publicly available. 

Feature/app request policy: IT should not act with abandon when it comes to management in the name of keeping a device running stably. New features or applications might not be adopted right away because they must be vetted and tested within the organization. With this in mind, I'm a huge fan of a policy that allows users to request apps or features, or even justify why a particular restriction should be modified or lifted. This lets users have their voices heard and provides IT with much-needed feedback about exactly what is needed.

Lost/missing device policy: Mobile devices are meant to be, well, mobile: Taken everywhere, not sitting in an office somewhere tethered to myriad cables and under the watchful eye of anyone who comes and goes daily. It's unavoidable that devices will become lost, whether they go missing by accident or are straight-up stolen. If a mobile device is lost or stolen, it's important to have documentation that lays out the user's responsibilities and IT's role in locking down the device to keep data secure. For instance, what steps will be taken to try to recoup the device, including enabling lost mode and tracking the device's location through GPS, and/or involving law enforcement? It's better to think about these details in advance rather than try to figure them out in the heat of the moment.

By tying all these components together as one cohesive system, IT will be able to implement the fabled zero-touch management style, including allowing users to get new equipment and letting them set it up themselves. IT can use Apple's services and the MDM to handle the pre-staging so devices are provisioned exactly the same each time, managed efficiently, and decommissioned and remote wiped if lost.

Also see