Can you manage an iPhone like a BlackBerry?

Apple's iPhone 3.0 OS and iPhone Configuration Utility 2.0 extend the iPhone's enterprise-class management and security features. The InfoWorld Test Center sees how far they really go.

Users love the iPhone, but IT does not. The biggest complaints: The iPhone can't be managed for security and access policies like a BlackBerry can. Businesses can buy a BlackBerry Enterprise Server or Motorola Good for Enterprise server to manage user profiles over the air, ensuring that users conform to password policies, encryption policies, app-installation restrictions, and so on, as well as have their e-mail, VPN, and other settings preconfigured to reduce hands-on deployment effort.

For some time now, Apple's offered its free iPhone Configuration Utility for Windows and Mac that lets IT set up and install configuration profiles on iPhones in BlackBerry-like breadth. But it doesn't provide the over-the-air reach, the granularity of control, or the visibility that BlackBerry Enterprise Server offers. Lacking these key needs of larger businesses, iPhone Configuration Utility has been dismissed as a toy application.

[ InfoWorld Test Center's first look: What iPhone 3.0 brings to business -- and what it misses. | Should you upgrade to iPhone 3.0 S or just get an iPhone 3G S? Tom Yager investigates. ]

But last week, Apple shipped the iPhone 3.0 OS that adds improved support for Microsoft Exchange ActiveSync policies, and it made available the 2.0 version of its iPhone Configuration Utility, with significant new management and security capabilities. Can IT now manage the iPhone in the manner of the BlackBerry and Windows Mobile device?

To answer that question, the InfoWorld Test Center has been testing both the version 2.0 iPhone Configuration Utility and Exchange ActiveSync as approaches to managing iPhones to see how well they really work, and what types of IT and businesses can effectively use them -- and which cannot.

The short answer: Each tool has important capabilities that the other lacks. For managing our fleet of iPhones (and iPod Touches), we'd prefer to use them in combination. For shops not running Exchange, managing iPhones with the iPhone Configuration Utility alone has one critical drawback: Should the phone be lost or stolen, an administrator cannot initiate a remote wipe of the phone's data, or receive confirmation that a remote wipe occurred. But we found that managing iPhones via Exchange is no substitute for using the iPhone Configuration Utility.

iPhone Configuration Utility 2.0: Powerful but not scalable Apple's free iPhone Configuration Utility, boosted to a 2.0 version when iPhone 3.0 OS was released, has a rich array of policy controls that give IT great authority over iPhones and iPod Touches. The UI is easy to use, with various capabilities broken into "payload" sets that you switch among and configure for a given configuration profile. And they really do work, strictly enforcing their rules on the client devices.

The policies can be set so that an admin password is needed to remove them, as well as to allow user removal or completely prevent user removal. (For an IT admin to get around full removal prevention, you need to connect the device to your PC or Mac and run iPhone Configuration Utility's Remove feature on that device. That certainly gives IT control.)

The configuration utility has the password controls you'd expect, such as enforcing password entry to use the device and specifying restrictions (number of characters, disallowing repeating patterns, requiring a minimum number of characters overall and of symbols in the password, maximum password age, number of intervening unique passwords before one can be reused, and grace lock period before a password is required again). A key capability is being able to set how many failed password attempts wipe out the device's data, which turns the device into a brick. (A "bricked" iPhone can still make emergency calls, but that's it.)

If you're concerned about employees' nonwork activities, you can block access to explicit content; use of Safari, YouTube, and/or the iTunes Music Store; the ability to install apps; and the ability to use the iPhone's camera. But if you want to disallow specific applications, too bad. The only way to do so is to install the permitted apps on the device first (or remove the unpermitted ones), then disable the ability to install apps -- but that also disables app auto-updating.

You can also install credentials via profiles, which is handy if you want to require credentials for e-mail or VPN access, instead of using plaintext passwords that users might copy and use elsewhere. Other configurations you can set include LDAP server information, subscribed calendars, and a default Web clip (essentially, a Web page that appears on the Home screen as if it were an app, such as to your Web e-mail page or customer order lookup page).

You can create multiple configurations and apply multiple ones to individual devices. Thus, you can layer configurations rather than develop a custom profile for each and every device. For example, everyone might get a profile with Exchange, LDAP, password, and application access settings for your corporate standards. And you might have a separate VPN profile that only some users get, and a separate Wi-Fi profile that restricts some users to specific wireless LANs (based on SSID).

One warning on the tool: If you open a payload's settings and don't close it (click the minus icon), the profile includes all the null values for that payload, which essentially prevents users from accessing those settings. You can use this intentionally to, for example, block all Wi-Fi access by only allowing access to null SSIDs (which is not the same as any SSID) -- but it's easy to inadvertently prevent access you didn't mean to block.

The payload controls are for the most part thorough and have a good range of configuration options. But there are no controls over the iPhone's more granular settings, such as whether JavaScript is enabled or disabled or whether the user has encryption set for the device backup in iTunes.

The Wi-Fi configuration also doesn't let you require a certain minimum connection security (such as WPA2) for any Wi-Fi connection; you can only require minimum security protocols for specific SSIDs. That's too bad, as it would be useful to allow access at all Wi-Fi access points that meet a certain security requirement.

But the biggest flaw in the iPhone configuration utility is how it manages the configurations. This is a deal-breaker for large organizations that have to assure that they are meeting compliance requirements or that must be able to install and update configuration profiles over the air or over a network.

You can easily share configuration profiles by e-mailing them or putting them on a Web site. If users click the attachment or the link, the profile is installed. But there's no way to force them to install the profile, and even if they do you have no way of knowing that they did, nor any way of ensuring that they will install any updates or additional profiles.

The iPhone Configuration Utility works well in defining configuration profiles. And it's a reasonable tool for businesses that set up mobile devices for their users, as IT support can easily and quickly install the profile over a USB connection when preparing the device in the first place.

In some cases, you can comfortably rely on the use of e-mailed or Web-accessible profiles. After all, if those profiles contain the only route to what a user needs to, say, access e-mail or the VPN (such as by requiring a certificate be used for authentication), then users will install them -- or not be able to use their devices for work purposes in the first place. We suspect many businesses not subject to regulations such as HIPAA and Sarbanes-Oxley can live with this "they'll install it because they have to" strategy, but it's not ideal. After all, you still have the issue of managing updates, which are harder to enforce through such draconian hurdles than the initial corporate access is.

Exchange ActiveSync: Short on policy, long on reachThe Exchange ActiveSync policies the iPhone supports fall well short of the controls provided by the iPhone Configuration Utility. In both Exchange Server 2003 and Exchange Server 2007, you can enforce the use of a password on the device, and determine how complex the password must be and how often the user must change it. You can set the number of minutes the device can be idle before a password is required, and you can set a maximum number of failed password attempts before the data on the device is wiped clean.

However, the only iPhone feature you can disable using Exchange ActiveSync policies is the camera, and only via Exchange Server 2007. Exchange ActiveSync policies offer no control over the use of the Safari browser, YouTube, the iTunes Music Store, or the App Store. Nor, of course, can ActiveSync deliver configuration settings for Wi-Fi, VPN, LDAP, and calendar subscriptions to your iPhone users. For all of these things, there's no substitute for the iPhone Configuration Utility.

Nevertheless, Exchange ActiveSync offers iPhone administrators one essential feature that the iPhone Configuration Utility doesn't provide: the ability to push a button and make all of the sensitive data stored on an iPhone go away, no matter where that iPhone might be. This "kill switch" is available in both Exchange Server 2003 and Exchange Server 2007, but only in 2007 is it also extended to the iPhone user, who can initiate a remote wipe from Outlook Web Access. That seems like a good idea, since the user is likely to be the first one to know when his device is lost, but you can hide the mobile device management option from Outlook users that you don't want to trust with this responsibility.

We've tried several remote wipes from Exchange Server 2007, and it works like a charm. Apple warns that older iPhones could take as long as one hour per 8GB to be "bricked," but our iPhone 3G handsets (with about 1GB of data, and running either iPhone OS 2.2 or iPhone OS 3.0) were cleaned and ready for restoration within 10 or 15 minutes every time. The status of the wipe is reported in both the Exchange Management Console and Outlook Web Access. E-mail confirmation of a successful wipe is also sent to the user's mailbox.

From a practical standpoint, the iPhone Configuration Utility is probably just as effective against the loss of an iPhone as the kill switch in Exchange. After all, if you configure a complex password and a wipe of the phone after five or six bad guesses, you can be pretty darn sure that the data will be destroyed. Still, we recognize the importance of documenting the wipe and receiving a confirmation that a successful wipe has occurred. Many organizations won't settle for less.

The Apple/Exchange combination comes tantalizingly closerFor that reason alone, the best way to manage iPhones in the enterprise today involves the use of both the Apple iPhone Configuration Utility and Exchange ActiveSync. But even in combination, these tools don't offer the level of control that admins currently enjoy over BlackBerrys. If Apple wants to own the enterprise, it will need to give iPhone administrators more middle ground -- between allowing either all App Store apps or none, for example, or between turning Safari completely on or completely off.

More important, Apple will have to make the iPhone manageable with or without the user's permission. The iPhone Configuration Utility is good enough to get a fair number of iPhone users rolling, but only if they're responsible folks who can be trusted to play by the rules. As the number of iPhone users spikes and more control is needed, relying on users to install profiles and updates when asked is not going to cut it.

The good news is that most of the policy pieces are in place. The bad news is that the critical management pieces are still MIA.

Tags AppleiPhoneenterpriseRIM BlackBerry

More about AppleBlackBerryetworkMicrosoftMotorola AustraliaResearch In Motion

Comments

Comments are now closed

Vertigan broadband demand forecast leaves NBN Co CEO 'curious'

READ THIS ARTICLE
DO NOT SHOW THIS BOX AGAIN [ x ]