Once upon a time, the only way to get your email on a mobile device was to use IMAP or POP (or Research in Motion's BlackBerry devices, but I'm going to pretend like those don't exist because soon they won't). Either choice was widely -- and correctly -- perceived as a bad deal. Neither protocol works especially well for mobile devices because each depends on connection-based polling. Microsoft surveyed this state of affairs and decided to attack it by developing a protocol and server application to provide direct, integrated mobile-device access for Exchange Server. That product, Mobile Information Server, was eventually integrated into Exchange; its protocol, Exchange ActiveSync (EAS), is now the de facto market leader for mobile email and calendaring. Even Microsoft's staunchest competitors, including Google and IBM, have adopted EAS as the basis of mobile-device access for their own email server products. EAS is making inroads on the desktop, too, now that the Windows 8 Mail application and Microsoft Outlook 2013 both support its use. It's too early to sound the death knell for Messaging API (MAPI), but we can envision a future in which EAS is the primary protocol used for Exchange synchronization.

The EAS protocol itself is only part of the complete mobile-device access story for Exchange. There are four points of interest to us:

  • The EAS protocol defines how clients and Exchange talk to each other. The protocol defines how clients can synchronize data with, and download device policies from, Exchange. Microsoft has released the EAS protocol specifications so that, in theory, anyone can release a completely functional EAS client just by reading the protocol docs and writing a client that follows them.
  • The server implements the protocol so that clients have something to talk to. Different versions of Exchange implement different EAS versions: Exchange 2010 Service Pack 1 (SP1) implements EAS 14.1, as does the preview version of Exchange 2013, although this might change when the final product is released.
  • Features that use the protocol let you do useful or interesting things. For example, EAS 14.1 provides a feature that lets compatible devices download Global Address List (GAL) photos. Depending on the feature, you might or might not be able to enable or disable it through EAS policy settings.
  • Client apps use the EAS protocol to communicate with Exchange. Clients are free to implement whichever parts of the protocol and features they want. You can't change which features clients support unless you install a different client application, something that isn't always possible. Microsoft and Apple ship EAS clients on their mobile devices; some Android device vendors do too, whereas others require the user to download an app such as TouchDown or RoadSync. (Note that the Microsoft article " Current issues with Microsoft Exchange ActiveSync and third-party devices" shows known EAS issues with different clients, but this list isn't necessarily comprehensive.)

The item of most interest to Exchange administrators is the server component. That's where we get to control which devices and users are allowed to use EAS and what they can do with it when connected. (Microsoft controls the protocol, so we don't get any control over it; mobile-client management is a thorny subject that I won't address in this article.)

Controlling EAS Availability for Users

By default, Exchange 2010 users have EAS device access. You don't need to do anything to let users sync their devices -- which might or might not be what you want. There are two competing schools of thought when it comes to EAS access. Some administrators prefer to leave access open to everyone, restricting only a subset of users (e.g., interns, contractors) who don't need EAS access. Others prefer to turn off access for all users, and then re-enable it for selected users only. Both approaches are easy to implement; they just require a slightly different approach.

You have three options for controlling which users are allowed to use EAS. First, you can enable or disable EAS on individual Client Access servers. This type of restriction is the broadest option: A Client Access server that has EAS disabled won't accept EAS connections, even from users who are otherwise authorized. Think of it as having a coupon for free ice cream and then presenting it at your local car wash. EAS depends on having a properly configured virtual directory set up in Microsoft IIS on the Client Access server. So to disable EAS, merely go into IIS Manager on the Client Access server, right-click the MSExchangeSyncAppPool object, and choose the Stop command. To turn EAS back on, right-click the stopped pool and choose the Start command.

Second, you can enable or disable EAS on individual users by using the Set-CASMailbox cmdlet. The ActiveSyncEnabled flag is what makes the magic happen. For example, you can use something like the following to enable all the users in the Sales OU for EAS (presuming that you've disabled it for everyone else):

Get-Mailbox -OrganizationalUnit Sales | Set-CASMailbox

-ActiveSyncEnabled:$true