Control user and device access to EAS
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 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.)
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):
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.
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:
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.
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
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.
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 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:
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.
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.
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.