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
To disable EAS for one or more users, just pipe the target mailboxes to Set-CASMailbox with -ActiveSyncEnabled:$false. You can combine Set-CASMailbox with whichever 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 most robust 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 behavior of this policy, which is pretty much what you'd expect: Devices are allowed to sync without restriction, and no password policy is enforced, but devices can 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 a policy 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't match, 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 the policy, 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 server allows non-provisioned devices.
You can have multiple EAS policies defined; switching a user to a different policy is simple. The -ActiveSyncMailboxPolicy switch for Set-CASMailbox controls 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 to do 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 no way 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 that devices sometimes lie about which policy settings they actually implement. (A semi-official Wikipedia page shows the current state of client support for a variety of devices.) There are three ways of working with EAS policy object
- In EMC, policies can be created and modified under the Exchange ActiveSync Mailbox Policies tab, which is under the Client Access node beneath the organization object.
- In the Exchange Control Panel (ECP), you can create, remove, and modify EAS policies by using the ActiveSync Device Policy slice under the organization object's Phone & Voice tab.
- In EMS, you can use the *-ActiveSyncMailboxPolicy cmdlets to create and remove EAS policy objects (New-ActiveSyncMailboxPolicy and Remove-ActiveSyncMailboxPolicy) or to view or change settings of an existing policy (Get-ActiveSyncMailboxPolicy and Set-ActiveSyncMailboxPolicy).
There are minor differences in terminology between these three implementations, and not every configurable option is present in ECP. For simplicity, I'll discuss 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:
- A field in which you can change the policy name (which Exchange ignores anyway)
- The Allow non-provisionable devices check box, which controls whether devices that don't accept a policy can sync, and which might represent a risk when enabled, given that you're essentially opening sync to any device, even one that can't implement the policy or that's blocked by the user
- The Refresh interval (hours) check box and text field, which control how often the server tells the device to request policy updates and which are cleared by default (meaning that the server never forces a timed update) but could be set to a value such as 24 hours if needed
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 password is 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 a useful security measure and usually worth the additional hassle. The settings on this tab include the following:
- Require password -- When the Require password check box is selected, the EAS policy forces the device to require a password. None of the other password options are active when this check box is cleared. If you select this setting without changing any of the other settings, the policy requires a simple 4-digit PIN.
- Require alphanumeric password -- If you don't want to allow numeric-only passwords, the Require alphanumeric password setting lets you force users to use a character or symbol in addition to numbers. The biggest drawback to this requirement is that the on-screen keyboard that the device shows for password entry is easiest to see and use when it contains only numbers. Requiring alphabetic characters means that the device must display its full alphanumeric keyboard, making password entry a little more difficult.
- Minimum number of character sets -- The Minimum number of character sets option should really be called something like "password complexity," because it specifies how complex the password must be. Character sets include lowercase letters, uppercase letters, symbols, and numbers. Setting this value to 2, for example, requires that the user pick a password that includes characters from at least two of those four sets. The default value of 1 allows users to specify all-numeric passwords.
- Enable password recovery -- When the Enable password recovery check box is selected, users can use Outlook Web App (OWA) to look up a device-specific recovery password, then enter that password to unlock the mobile phone. Exchange administrators can also use the EMC to look up recovery passwords. Windows Phone, Apple iOS, and most Android clients don't support this setting, which is too bad. It's a useful capability.
- Require encryption on device and Require encryption on storage card -- The two encryption requirements settings control whether the device is required to use onboard encryption to protect locally stored data. This is one area in which client software -- Apple's in particular -- has been caught failing to apply device encryption, but it seems that all the major client vendors now properly handle this setting.
- Allow simple password -- When selected, the Allow simple password check box allows the use of a simple 4-digit, numeric-only PIN.
- Number of failed attempts allowed -- In Active Directory (AD), we have the option to lock out an account after a certain number of failed logon attempts. In EAS, we get the option to force a device erasure after a user enters the wrong password a specified number of times.
- Minimum password length -- As its name implies, the Minimum password length option lets you set a password length from 4 to 18 characters.
- Time without user input before password must be re-entered (in minutes) -- The Time without user input before password must be re-entered (in minutes) option controls how long the mobile phone must be idle before the user is prompted for a password when trying to unlock it. On most clients, this setting is a floor. That is, if you set this value to 10 minutes, and the user separately sets a device lock time of 5 minutes, the shorter of the two times is used.
- Password expiration (days) -- The Password expiration (days) setting controls how long the user-selected password remains valid before it must be changed. This is a tricky setting: Users hate forced PIN changes, so enabling this setting is likely to generate some discontent, especially because users seem to be less likely to write down their PINs in the way that they might write down a complex AD password.
- Enforce password history -- You can use the Enforce password history setting to prevent users from reusing their previous device passwords. However, because there's no way to expire the device passwords as you can for AD passwords, this capability isn't terribly useful.
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 of calendar items or email that can be synced to the device, although most mobile clients have better controls for selecting how much email is synchronized and from which folders. The two most interesting controls on this tab are the Allow Direct Push when roaming check box, which controls whether devices 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 audio streaming, and other features that once were reserved for high-end devices. Not every organization wants all these features to be available to users. Some customers, such as parts of the US federal government, solve the problem by buying devices that don't have the unwanted features; you can actually buy modern smartphones from which the camera has been removed. More often, though, organizations either tell users not to do certain things (e.g., bring cellphones 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 device features 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 to implement 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 that your 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 controls that would regulate which applications could run on managed mobile devices. However, no clients support this EAS feature. Companies that want to actively manage which apps their users are allowed to run have been buying dedicated mobile-device management solutions, so there's been little demand for a fuller implementation 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 the portion 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 administrator can 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 the next 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 wipe command 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 can show 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 safe to 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 work better than previous versions on tablet and mobile devices, and it offers offline support. The existence of a Microsoft-provided rich mobile client will hopefully induce Apple, the various Android OEMs, and even the Windows Phone team to step up their game and deliver more of the functionality already specified in the EAS protocol. There are encouraging signs that Windows Phone 8 will feature improved EAS support, although Microsoft hasn't yet released any 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 personal archives. No matter how Microsoft changes the base protocol, though, being familiar with how to administer EAS devices is an important part of running an Exchange organization.
