Almost everyone is familiar with Exchange ActiveSync, which allows for synchronization of email, calendars, contacts and tasks on users' mobile devices. One feature of ActiveSync that many Exchange admins aren't quite as familiar with, however, is ActiveSync policies.
New devices are cropping up every day, and many admins struggle to understand exactly what happens when policies are enforced -- or aren't. As more employees rely on personal iPhones and iPads to access business information, it's critical that admins understand which ActiveSync policies can be applied and exactly what they do.
Basic ActiveSync policies in Exchange 2013
In Exchange 2013, admins will find that ActiveSync policy options have been renamed "mobile device mailbox policies." They are accessed via the Exchange Administration Center's mobile tab (see Figure 1).
When it comes to mobile devices and sensitive business information, we know that security is critical. Fortunately, ActiveSync password policies are supported on iOS devices, and there are several available.
The password policies listed below are enabled -- or disabled -- via the Exchange Administration Center (EAC):
- Require a password. This option ensures that the user has set a passcode on the iOS device.
- Allow simple passwords. This option enables a user to set a simple four-digit passcode, and is available on the General -> Passcode Lock settings screen on the iOS device under the "Simple Passcode" option. When the passcode is set with ActiveSync, the option is greyed out to the end user.
- Require an alphanumeric password. This option is self-explanatory. It requires users to create a more complicated password, one that can include a combination of lower and uppercase characters, or numbers and symbols, and so forth. Users are informed about the requirements that are set in the policy on their iOS devices.
- Require encryption on the device. All iOS devices released since the iPhone 3GS use encryption by default. If you want to ensure that only devices this age and newer can connect should enable this option.
- Minimum Password Length. If you plan on keeping the minimum password lengths in line with your on-premises Active Directory requirements, you'll be happy to learn that this policy is supported on iOS devices. When users are prompted to set a password (or passcode), they are notified of the minimum length required.
- Number of sign-in failures before device is wiped. As solid as device encryption and passwords are, if a hacker tries enough times, he'll eventually get in. Automatic device wipe is initiated, not by Remote Wipe but by the device itself. This ActiveSync policy option maps to the standard iOS feature, General -> Passcode Lock -> Erase Data.
- Require sign-in after the device has been inactive for X minutes. Once a device is unlocked, you can choose to provide a grace period before an idle device requires that the passcode be re-entered. This ActiveSync policy options maps to the General -> Passcode Lock -> Require Passcode after being set on the iOS device.
- Enforce password lifetime (days) and password recycle count. Users often choose a familiar letter or number combination -- it might be the date of their wedding anniversary or birthday -- for their password. Therefore, you should require them to change their password once in a while. When you implement this ActiveSync policy, both the passcode expiration date and history settings take effect on iOS devices.
All these policies are also available in Exchange Server 2010, on the Password tab on the properties page of each ActiveSync policy.
Additional ActiveSync policies in Exchange 2010 and Exchange 2013
As you can see, there's a glut of iOS device support for ActiveSync password policies. When it comes to the rest of ActiveSync's available policies, however, iOS devices fare better than most others (except for Windows Mobile 6.5). Unfortunately, support is still relatively sparse.
If you're working with Exchange 2010, ActiveSync policies are managed via the Exchange Management Console (EMC). Simply navigate to Organization Configuration -> Client Access, then to the Sync Settings tab (see Figure 2).
If you're using Exchange 2013 -- or simply prefer the Exchange Management Shell (EMS) in Exchange 2010 -- you can access these features using the Get-ActiveSyncMailboxPolicy and Set-ActiveSyncMailboxPolicy cmdlets (see Figure 3).
Let's start with the advanced features that are available for iOS devices:
- Include Past Email Items (Days). If you don't set this policy, users are allowed to choose how far back in time the iOS device will download messages; this includes downloads of all messages within a folder. Normally, users can set their preference by opening the iOS Settings app and navigating to Mail -> Contacts and Calendars -> Exchange Account Name -> Mail Days to Sync. When this policy is set, it's the only option available.
Users who want to view older messages still can. However, they'll need to use the Search the folder via the Mail app, then select Continue Search on Server.
The PowerShell you'll need here is: Set-ActiveSyncMailboxPolicy parameter -MaxEmailAgeFilter All (Default), OneDay, ThreeDays, OneWeek, TwoWeeks
- Allow Direct Push While Roaming. Data roaming charges can be costly. If you want to ensure that users make a conscious decision to download mail, you should disable Direct Push. Apple iOS allows Direct Push when roaming by default.
The PowerShell you'll need here is: Set-ActiveSyncMailboxPolicy parameter -RequireManualSyncWhenRoaming $False (Default), $True
- Allow Camera. The two aforementioned features require an extra Enterprise client access license (CAL). The Allow Camera feature is turned on by default. Should you choose to disable the camera, it will be unavailable across all iOS apps that use the underlying camera application programming interface, or API. This is accomplished by enforcing the Restrictions on Camera use setting within the General settings.
The PowerShell you'll need here is: Set-ActiveSyncMailboxPolicy parameter -AllowCamera $True (Default), $False
- Allow Browser. The final feature you can control on iOS devices is one that also requires an Enterprise CAL. Unfortunately, it also can prove quite tricky to get around, thanks to third-party browsers in the App Store, such as Google Chrome and Puffin. That said, disabling the built-in Safari does the job. It's accomplished via iOS restrictions, and the process is similar to disabling the camera.
The PowerShell you'll need here is: Set-ActiveSyncMailboxPolicy parameter -AllowBrowser $True (Default), $False
For more on ActiveSync
ActiveSync performance monitoring aids mobility
As you can see, though this is not a very big list, the ActiveSync policies you can apply should prove quite useful. The remaining available policies are not supported:
- Allow attachment download
- Maximum attachment size
- Enable password recovery
- Encrypt Storage Card
- Disable SMS Text Messaging
- Disable Wi-Fi
- Disable Bluetooth
- Allow Internet sharing from device
- Allow remote desktop from device
- Disable POP3/IMAP email
- Allow consumer mail
- Allow unsigned applications
- Application Block/Allow List
- Require Signed S/MIME messages
- Require Encrypted S/MIME messages
- Configure Message Formats (Plain Text/HTML)
- Email Body Truncation Size
- Include past calendar items (days)
- Allow IRM over ActiveSync
In this tip, we've covered which ActiveSync policies may be applied to Apple mobile devices and exactly how they affect those devices when they're implemented. Although the list is somewhat limited, it provides enough features to be useful.
If you're planning on more strictly enforcing what users can and can't do on their Apple devices, a dedicated mobile device management tool might actually be what you need. Failing that, check out the Apple iPhone Configuration Utility, which lets you create and deploy profiles that allow you to implement iOS-specific restrictions on devices manually.
About the author:
Steve Goodman is an Exchange MVP, and works as a technical architect for one of the UK's leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.
This was first published in February 2013