Managing Exchange ActiveSync Policies in Exchange 2010

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 -- andcorrectly -- perceived as a bad deal. Neither protocol works especially well for mobile devices because each depends on connection-based polling. Microsoftsurveyed this state of affairs and decided to attack it by developing a protocol and server application to provide direct, integrated mobile-device accessfor Exchange Server. That product, Mobile Information Server, was eventually integrated into Exchange; its protocol, Exchange ActiveSync (EAS), is now thede facto market leader for mobile email and calendaring. Even Microsoft's staunchest competitors, including Google and IBM, have adopted EAS as the basisof 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 thedeath 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 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 EASand 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 thornysubject 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 whatyou want. There are two competing schools of thought when it comes to EAS access. Some administrators prefer to leave access open to everyone, restrictingonly 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 forselected 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. Thistype of restriction is the broadest option: A Client Access server that has EAS disabled won't accept EAS connections, even from users who are otherwiseauthorized. 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 configuredvirtual 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 everyoneelse):

Get-Mailbox -OrganizationalUnit Sales | Set-CASMailbox-ActiveSyncEnabled:$true 

To disable EAS for one or more users, just pipe the target mailboxes to Set-CASMailbox with -ActiveSyncEnabled:$false. You can combine Set-CASMailbox withwhichever other Exchange Management Shell (EMS) cmdlets you want. Of course, if you'd rather, you can use the Exchange Management Console (EMC) instead:Just open the target mailbox's properties and use the appropriate controls on the Mailbox Features tab.

There's a third way to control which users have access to EAS, and that's to create an EAS mailbox policy and apply it to users. This is generally the mostrobust means of control because the EAS policy mechanism gives you the most control over what the devices -- and thus the users -- can do.

Assigning and Removing EAS Policies

EAS policies are applied to users; each user can have zero policies or one EAS policy at any given time. If you don't explicitly assign a policy to a user,the default policy is applied instead. The Microsoft article " Understanding Exchange ActiveSync Mailbox Policies" specifies the default behaviorof this policy, which is pretty much what you'd expect: Devices are allowed to sync without restriction, and no password policy is enforced, but devicescan be remotely wiped.

Now might be a good time to point out that the remote wipe feature built in to EAS depends on the device receiving a policy update in the first place.During the initial sync of a new device (that is, one that hasn't been synchronized to the server before), the device and server exchange what EAS calls apolicy key. Think of the policy key as a GUID or MAC address; it's a unique key that indicates one specific policy. If the device and server keys don'tmatch, the device is required to request the most recent policy and then apply it. The process of applying a policy to the device is known as provisioning.On most devices, the user will see a dialog box indicating that the server is applying a policy and asking whether to accept it. If the user declines thepolicy, the server might or might not allow the device to continue to sync to it; the exact behavior depends on whether the default policy on the serverallows non-provisioned devices.

You can have multiple EAS policies defined; switching a user to a different policy is simple. The -ActiveSyncMailboxPolicy switch for Set-CASMailboxcontrols which policy is assigned to a given mailbox. You can assign a policy by specifying the policy as an argument to this switch. The simplest way todo so is by calling Get-ActiveSyncMailboxPolicy with the name of the policy you want, as in this example:

Set-CASMailbox id [email protected] -ActiveSyncMailboxPolicy(Get-ActiveSyncMailboxPolicy "Sales").Identity 

You can remove the existing policy by passing $null as the value to ActiveSyncMailboxPolicy. Doing so causes the user to get the default policy. There's noway to have a user who doesn't have any policy at all defined.

Creating and Managing Policies

On the Exchange side, EAS policies are pretty straightforward. The trick is to remember that not every device will implement every policy setting, and thatdevices sometimes lie about which policy settings they actually implement. (A semi-official Wikipedia page shows the current state of client supportfor a variety of devices.) There are three ways of working with EAS policy object

There are minor differences in terminology between these three implementations, and not every configurable option is present in ECP. For simplicity, I'lldiscuss the EAS interface as it appears in EMC.

What's in a Policy?

Let's take a look at the major categories of available policy settings by touring the tabs in the policy Properties dialog box in EMC.

Figure 1: EAS Mailbox Policy Properties 

General tab.The General tab (see Figure 1) contains only three controls of interest:

Password tab.The next (and arguably most important) group of settings appears on the Password tab (Figure 2) and controls device passwords, including whether a passwordis required. Most organizations that allow mobile-device access require the use of a password.

 
Figure 2: EMC Properties Password Tab

Although entering a password can be inconvenient, it's auseful security measure and usually worth the additional hassle. The settings on this tab includethe following:

Sync Settings tab.The controls on the Sync Settings tab (Figure 3) control what the device is allowed to do when it synchronizes. You can limit the number of days worth ofcalendar items or email that can be synced to the device, although most mobile clients have better controls for selecting how much email is synchronizedand from which folders. The two most interesting controls on this tab are the Allow Direct Push when roaming check box, which controls whetherdevices that are roaming away from their normal cellular carrier network are allowed to use push email, and the Allow attachments to be downloaded to device check box, which gives you a way to keep users from downloading potentially sensitive attachments.

Figure 3: EMC Properties Sync Settings Tab

Device tab.Mobile-device hardware has changed a lot over the past several years. Even low-end devices now usually have high-resolution cameras, Bluetooth audiostreaming, and other features that once were reserved for high-end devices. Not every organization wants all these features to be available to users. Somecustomers, such as parts of the US federal government, solve the problem by buying devices that don't have the unwanted features; you can actually buymodern smartphones from which the camera has been removed. More often, though, organizations either tell users not to do certain things (e.g., bringcellphones into the lab) or use technical controls to try to block the actions.

The controls on the Device tab (Figure 4) fall into the latter category. EAS provides a means for you to define a policy that blocks certain devicefeatures from working . . . if the device supports those policy settings. Many devices don't, either because the policy setting doesn't make sense(such as enabling the Allow infrared setting on iOS devices, which don't have infrared [IR] ports) or because the EAS client vendor didn't bother toimplement support for the setting. If you're depending on these controls as a major part of your mobile-device security strategy, be sure to confirm thatyour devices actually implement the policies you care about.

Figure 4: EMC Properties Device Tab 

Device Applications tab and Other tab.The two remaining tabs, Device Applications and Other, are vestigial, like your appendix. Microsoft added them to lay the groundwork for policy controlsthat would regulate which applications could run on managed mobile devices. However, no clients support this EAS feature. Companies that want to activelymanage which apps their users are allowed to run have been buying dedicated mobile-device management solutions, so there's been little demand for a fullerimplementation of this feature.

EAS and Remote Wipe

Being able to remotely erase a lost or stolen device is a great security feature, provided you don't mind erasing the entire device and not just theportion of data belonging to the organization. There are two primary ways to initiate a remote wipe: The user can do it through ECP, or the administratorcan do it through EMC. In either case, the wipe process itself requires that the device receive the command, meaning that the wipe won't happen until thenext time the device wakes up and attempts to sync with the server. Therefore, a lost device that runs out of battery power doesn't execute the wipecommand until it's recharged. The device isn't supposed to give the user a chance to opt out of the wipe operation, either. Keep in mind that Exchange canshow you when the wipe was requested, but it will only display an acknowledgement of the wipe command if the device returns one.

The Future of EAS

Because Microsoft has built EAS support into the built-in Windows 8 Mail client and Outlook 2013, and because of the huge installed base for EAS, it's safeto bet that EAS will be around for the long term. It's interesting to see how the OWA team has been positioning OWA in Exchange 2013; it's designed to workbetter than previous versions on tablet and mobile devices, and it offers offline support. The existence of a Microsoft-provided rich mobile client willhopefully induce Apple, the various Android OEMs, and even the Windows Phone team to step up their game and deliver more of the functionality alreadyspecified in the EAS protocol. There are encouraging signs that Windows Phone 8 will feature improved EAS support, although Microsoft hasn't yet releasedany details. It's also possible that we'll see some improvements in the EAS protocol itself, such as a means for EAS devices to access Exchange personalarchives. No matter how Microsoft changes the base protocol, though, being familiar with how to administer EAS devices is an important part of running anExchange organization.