On April 13, Microsoft announced details of their ActiveSync logo compliance program. While it’s taken me a little while to comment (other things go in the way), I think this is a good idea because it should rein in the tendency for ActiveSync to rapidly degrade to become the wild west of mobile communications interface standards. Microsoft really had to rein in the monster that they had unleashed when they launched the ActiveSync licensing program and encouraged mobile device manufacturers to adopt the standard without committing to implement a specific set of functions.
The result of Microsoft’s success in evangelizing ActiveSync over the last few years is that it has become the market-preferred synchronization protocol for mobile devices other than RIM’s Blackberry. Device manufacturers aren’t stupid and the fact that Exchange has continued to grow and taken an ever-commanding share of the corporate email market since server-based ActiveSync (EAS) first appeared in Exchange 2003 SP2 has been a huge factor in the adoption of ActiveSync. Together, the combination of easy licensing and a swelling user base means that ActiveSync has steadily reinforced its position, even if the companion Windows Mobile devices never impressed and the implementation of ActiveSync on devices such as Apple iPhones and various brands of Android devices wasn’t particularly complete. At times it seemed like some vendors implemented ActiveSync as if it was just a slightly more sophisticated version of POP3 or IMAP4 that was optimized for mobile devices and forgot that while email and calendar synchronization is important to end users, other pieces of functionality such as enabling remote wipe, enforcing password policies, and supporting AutoDiscover are really important to system administrators.
A good implementation of ActiveSync is much more than making sure that email was downloaded effectively as it arrived on a mailbox server (see this wikipedia entry to get a broad view of ActiveSync capabilities on different mobile platforms). The new compliance program seeks to address the problem by specifying 14 policies that an implementation must support before it is considered compliant.
Why is it important to implement the ActiveSync system administration features? Well, here are a few facts of system administration life:
- New mobile devices appear more rapidly now than they used to and this trend is going to continue.
- Users treat mobile devices as accessories and want to use the latest and greatest. That’s why they change phones so often.
- If they spend a lot of money to switch to the latest and greatest device, users are frustrated when they’re told that they can only use specified devices at work. They want to use a single device and will attempt to connect whatever device they feel like, even if policies say that only a list of approved devices are supported.
Exchange 2010 includes the ability to define and deploy ActiveSync device access rules that allow companies to implement restrictions on the devices that are allowed to connect. This is a good thing and you can get extremely granular about the device family and versions that you support (for example, only Windows 7 phones manufactured by HTC). ActiveSync policies depend on ABQ (Allow/Block/Quarantine) strings – information presented by the device to identify itself when it connects. The ActiveSync logo program requires devices to support ABQ strings to allow ActiveSync device access rules to be applied.
Exchange 2010 ActiveSync access rules are one of the pieces of functionality that are only exposed through the Exchange Control Panel (ECP) rather than the EMC console. To see the rules used in an organization, go to ECP, opt to manage the organization, go to “Phone & Voice”, and click on “ActiveSync Access”. Or you can use the EMS cmdlets such as New-ActiveSyncDeviceAccessRule to create a new rule, or Get-ActiveSyncDeviceAccessRule to view the current rules, and so on. For example:
Get-ActiveSyncDeviceAccessRule | Format-Table Name, Characteristic, QueryString, AccessLevel - AutoSize
But policies only work when devices broadcast accurate information to identify themselves and users, especially those with some influence within the organization, are willing to accept that some control is going to be exerted over the devices that they can connect to download and send email, which can of course contain valuable intellectual property that should be protected. Some companies really struggled after Apple launched the iPhone when they found that users were connecting to Exchange to access their email – and many of the users were executives! Cue another discussion about Apple’s flawed implementation of ActiveSync (see Paul’s blog for details).
While major vendors such as Apple (iPhone 3GS, iPhone 4, and iPad) and Nokia (what a surprise!) have signed up to support the new program, it’s hard to know whether the Microsoft ActiveSync logo compliance will achieve its goal. On the plus side, a standard has now been set for manufacturers, customers, and end users… and that can’t be a bad thing. After all, there’s a ton of non-compliant devices floating around today and it will take time before their useful working life expires and they are replaced, hopefully with compliant devices – assuming that a wide range of these devices are available.
Of course, time will tell just how observant device manufacturers will be. Consumers will know nothing about the purpose or meaning of the ActiveSync logo. Likely, it’ll just be another annoying sticker that has to be peeled off before a device can be used. This means that IT departments will have to do a good communications job to help users do the right thing and select compliant devices – or adopt the fist-in-your-face approach and implement stringent ActiveSync policies (if they use Exchange 2010) to block connections from anything other than compliant devices.
One curious point is that the standard to gain the ActiveSync logo doesn’t include security policies such as enforcing the requirement for devices to be encrypted or for their storage cards to be similarly protected. Omitting these policies weakens the standards because it means that devices that can store gigabytes of confidential data such as budgets and PowerPoint presentations describing company strategy can achieve compliance. Companies seeing the ActiveSync compliance logo may assume that all such devices are suitable for deployment in secure environments, or even inside corporate deployments. The security departments of large companies have torn their hair out because of the risk of information leakage from mislaid mobile devices for years and this program doesn’t help them at all.
A cynic might observe that Microsoft defined the standard to ensure that the widest possible set of devices might be certified, including their current implementation of the Windows 7 platform, which has some acknowledged issues in that respect. Of course, that’s not the reason but a certain lingering suspicion is in the air. But there’s hope for future improvement as revealed in this statement in the Exchange team’s blog post giving their view of the announcement:
“Over time, the program will evolve to require additional features and management policies”
Maybe the Windows 7 developers are waiting for the new program to develop before they’ll add the ActiveSync security features to their platform? If so, while they are waiting, you can continue to deploy Windows Mobile 6.5 devices, safe in the knowledge that while this platform is now sadly outdated, it is at least part of the new compliance program and it supports a wide range of security features.
For more information about Exchange 2010 ActiveSync device rules, see pages 626-631 of Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site.