How mobile device management works

Smartphones have become anarchy in a pocket. Here's what you need to know about mobile device management.

Smartphones have become anarchy in a pocket. They have the power of a full desktop system of just a decade ago, and that power is increasing quickly. With that power is ostensible responsibility, but smartphone users are often either unaware or oblivious to how much accessibility and potential damage can be done with smartphones—and the large amount and types of data that many smartphones can store.

Without control, mobile devices are walking security time bombs in addition to being fascinating tools. As a result, system administrators find themselves becoming involved and responsible for an entirely new category of devices, which often have far wider management variance than is found in server farms and cubical villages—lots of models, lots of operating systems, lots of carriers, and perhaps lots of bad habits to break and potentially damaging behavior to confine.

Mobile device users can become frustrated, too. In their quest to do their jobs, mobile device users are offered comparatively sophisticated communications platforms that they're often untrained to effectively use, control, and make productive. Often a single common application like email is an organization's incentive for smartphone use, and increasingly- the prospect of using a line-of-business application or set of communications features becomes the compelling reason to provision smartphones and mobile devices like the iPad and tablets. Like any new hammer, it seeks a nail, and initial deployments may lead to rapid fleet expansions, depending on popularity and real productivity with new mobile apps.

Obtaining applications away from the auspices of organizational distribution mechanisms can also be fraught with difficulty. Some sources of applications vet available applications more thoroughly than others, as recent "app store" problem investigations have determined. Some organizations have gone to the trouble of hosting their own application resources—like app stores— and sequester mobile device downloads strictly from these resources in a quest to contain user download behavior. Often, these "company stores" provide popular publicly-found (and checked) applications alongside those associated with the organizations desired vendors and mobility-related resources.

Hearding mobile cats

Many organizations impose mobile fleet order by implementing Mobile Device Management (MDM) applications across their installed base and subsequent mobile device fleet deployments. MDM apps are designed to corral smartphone functionality in explicit, policy-based ways. As a by-product, many MDM applications also provide proof of compliance for regulatory and other audit needs. Indeed a hallmark of the current crop of MDM applications is heavy reporting. Popular MDM applications provide pathways for international regulatory compliance proof, carrier usage reports, group costs, fleet/group/individual usage patterns, even how popular games and apps are used.

MDM applications are hosted either as an in-house deployed and managed application, or externally deployed via SaaS or "online" hosted models. Some MDM applications are telco/carrier-specific. Carrier-hosted MDM applications often cover only devices issued by the carrier. Many of these carrier-based MDM applications are OEM versions of other MDM applications, modified in some cases to handle carrier-specific service level agreements/SLAs, or specific carrier features or policy controls.

Other MDM applications may have either organizationally-based and/or hosted/SaaS versions available for deployment. Licensing is often flexible. But no matter where the MDM application is hosted, the scope of an MDM's scalability is important as organizations that seek to corral smartphone and mobile device use often must do so for their entire organization's field deployment of mobile devices. This mandate is often spawned by regulatory needs, audit/compliance policy adherence, or the fear of liability, security breaches/data loss, and employee safety.

It's for the audit reasons that some current device tracking management application vendors have extended their desktop/notebook management applications to extend to smartphone and mobile device users. Organizations such as Wavelink and Fiberlink/MaaS360 already had industrial-strength fleet management skills before they launched in to MDM. Others, like Tangoe, built highly-focused MDM applications that were used by carriers before they became available for large organizations.

Mobile device OS factors

Some, but not all mobile device/smartphone OS makers have MDM applications available and their management capabilities are often specific to the mobile device they make. RIM, as an example, has the Blackberry Enterprise Server as a nexus for controlling the Blackberry.

While Microsoft currently manages only their own phones using Windows Mobile OS through Microsoft's System Center: Mobile Device Manager/SC:MDM, the MDM functionality will soon be bundled into other System Center modules for production use in late 2011. In addition, Microsoft will also control iOS/Apple and Android phones, and perhaps others, a trend likely to be followed by other mobile device OS makers.

Smartphones and other mobile devices are controlled in the classic client/server model. An agent client application is initially installed on the smartphone or mobile device, sometimes in the smartphone's system software, but more often via software download provisioning. This adds client monitoring and device control. Provisioning can be as simple as a smartphone user clicking on an SMS message that has an embedded URL to the MDM resource server. Sometimes an agent is downloaded thru an "app store", emailed URL, or is initially provisioned under the auspices of a carrier or contractor.

MDM applications like Afaria (from Sybase) and Tangoe have user agent software that's downloaded in this way and smartphone agents become the focal point for communications with the desired MDM server. Microsoft's Exchange smartphone client software, ActiveSync, is sometimes used as the proxy agent for communications from an MDM server. There are also ActiveSync-like agents for MS Exchange like NotifySync for Blackberry phones that add Exchange and ActiveSync client policy control nexus for Blackberry mobile devices.

After the appropriate client agent is downloaded, it's installed onto the device. From there, the agent software examines the phone or device state, reports findings to the MDM control server, and the MDM control server then delivers instructions to the phone. The agent then makes adjustments to the phone's or device's behavior according to rules/policies dictated by selections made administratively in the MDM application via the received messages.

The smartphone user agent app periodically "phones home" or receives messages via an email or SMS proxy application to communicate the smartphone state. Messages are pushed (sent to the mobile device), where the resident agent software reacts to them, changing policy, adding or disabling features, perhaps backing up phone data, or reacting to changes.

As an example, a locality change might change a policy on a smartphone. International dialing might be disabled (or enabled). Perhaps a smartphone has been reported as missing, and the phone is remotely "killed" or wiped back to factory state with a new passcode. A new contact list is delivered. Updated software might be silently downloaded. Resident software might be tallied. The possibilities are as endless as smartphone features and the intelligence of the MDM application and its features. There are many common denominators of policy control item for mobile device features, like demanding that the phone has a PIN, or that only a specific group of phones having a certain revision level of OS and/or phone firmware gets a specific update, and so on.

Agents do their best to deliver information about the mobile device's state back to the MDM application. The mobile device state is a summary of conditions, settings, and where enabled, additional data such as the location of the phone, messages/calls sent received, software installed (and versions), security data, and policies in place.

Devil's in the details

MDM applications must control a range of features and be able to detect numerous smartphone or device states. This becomes complicated for MDM application vendors for many reasons as there are strong differences between platforms, carriers, operating systems, and user options.

One of the major detection problems surrounds differences in operating systems and their versions—and there are numerous operating system versions to track unless an organization has selected a single mobile OS—which has become increasingly rare. The most popular smartphone operating systems include Windows Mobile in three distinctly different versions; Apple's iOS in four versions; Android in three+ versions; Blackberry OS in two major current releases; HP/Palm's WebOS in two versions (more coming soon); and Symbian, which can be found on numerous phones, especially from Nokia and Sony-Ericcson. Each of these vendors plans upgrades in the near future.

Smartphone and mobile device hardware makers usually develop their phones to work at a "spec" designed to meet the requirement of a smartphone OS version. The vendor's operating system components may or may not allow user updates to core software. Smartphone hardware vendors can limit specific smartphone phone features, or the telco/carrier used by the phone. As data plans vary vastly for smartphones, some vendors limit browsers to specific sites to conserve data transfer costs. Some limit GPS functionality to save battery life. Others change defaults to various applications like POP email—to point mail to a carrier's favored host. Uniformity across an operating system for smartphones isn't guaranteed.

There's also the difficulty of user "tinkering". Users may alter smartphone software application loads dramatically, but it's increasingly common to find users intentionally breaking the walls between operating system and/or firmware and user application space in a process called "rooting" or gaining operating system super-user status. Rooting is usually the first step towards the capability of changing a smartphone's firmware or operating system payload as a "user-mod" implementation. Such mods are frequently performed to thwart carrier-based or smartphone hardware vendor-based constraints in use. One popular root user-mod permits tethering devices (like notebooks systems or iPods) via WiFi to a phone's data connection in a process called ‘tethering'. Carriers often impose constraints on tethering as such connections are often seen as thwarting their revenue plans.

Gaining this super-user capability is called "rooting". A phone is security-cracked with software that enables phone operating security bypass. The software and scripts used, often downloaded as a bundle, is called a "rootkit". Some rootkits can disable MDM agent control capability, and the step used to install a rootkit can be covered, leaving no trail. Currently, it's a cat-and-mouse game to detect rootkits on Apple's iOS and on Android versions. By the time you read this, it's likely to have changed, but we won't know how—and that's the challenge for MDM application makers as new rootkits and security-thwarting applications appear constantly.

Some organizations believe that intentionally thwarting software agents or attempting to breach security violates policy and requires strong recourse, while other organizations believe that systems security protects users from potentially dangerous security breaches and merely admonish users, then take action to remove offending software or states that interfere with their sense of security integrity.

Across the spectrum of mobile devices managed, MDM applications are also the focal point for audit, compliance, regulatory control, and reporting. Some packages have reporting capability that allows international regulatory and privacy compliance, where others are more focused towards asset assay, financial costing (for departmental or divisionally-focused accounting), and fleet quality in terms of patch-and-fix level, software inventory and licenses, and decision support.

The decision support components in turn relate to call center and support (help desk) visit costs across models and operating systems. For some organizations, the day of having a single mobile device or smartphone vendor is long gone. Decisions revolve around model reliability, field support costs, user satisfaction assays, successful user interaction with their devices, and overall productivity versus cost. As tremendous amounts of information can be accumulated with MDM tracking, trend analysis data becomes available, but is often best examined through external means, like spreadsheet and light database analysis tools.

Smartphones and mobile devices are now the equal to desktop and notebook assets in terms of accessibility, communications power, and potential for trouble. MDM applications provide the nexus to control these communications assets in flexible ways—and across a wide spectrum of operating systems. As a helpful benefit, large and articulated amounts of information can be garnered about many important qualities of mobile device usage patterns and costs. While this kind of control was once a luxury, it's now becoming a mandatory addition to IT management infrastructure. And largely, we're glad it's there.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies