Introduction
Mobile devices have moved on since they first became popular ten years ago, and almost all access to Exchange mailboxes is via Exchange ActiveSync these days. This is a protocol that allows mobile devices such as smartphones and tablets to connect to Exchange. Depending on the device software, ActiveSync is capable of mail, calendar and task connectivity, and also varying levels of device management, including “remote wipe” capability. There is a really good primer on ActiveSync here; don’t be put off because it’s for programmers – there’s a wealth of explanation and troubleshooting information further down.
Almost all mobile devices, including the latest Blackberry 10 devices and smartphones running the Jolla operating system now come with an implementation of ActiveSync, or can have a third party ActiveSync client installed such as NitroDesk.
Challenges
This presents a real challenge for Exchange. Different manufacturers implement ActiveSync in different ways, supporting a varying number of features. While ActiveSync is a Microsoft protocol, Microsoft have no control over how a third party manufacturer might choose to implement it, and so troubleshooting ActiveSync problems can become very tricky indeed. Before blaming Exchange for any issues that are experienced with third party devices, it’s always a good idea to have a good read of this article:
Current issues with Microsoft Exchange ActiveSync and third party devices.
I find that this is kept up to date and includes information on the latest versions on phone software. It is worth paying close attention to where the support boundaries lie, as well.
There is a reasonable table of implementations here, which lists which operating systems support which features. Unfortunately it doesn’t cover Exchange 2010 SP3 or Exchange 2013, but I guess we can’t have everything.
I cannot stress enough that new versions of OS software often break exchange – iOS 6.1, issues with iOS 7 and android have all had problems, some of them very serious. If you don’t block novel devices as a matter of course, then you really must keep an eye on the article above. Here it is again, just in case: Current issues with Microsoft Exchange ActiveSync and third party devices.
Solutions
So, how can we make things better? Three areas require optimisation and management:
Users
By default, all users are enabled for ActiveSync access. this will probably not be suitable for your environment. disable users by running
set-casmailbox <username> -activesyncenabled $false
Check a user’s status by running
get-casmailbox <username>
You may see reference to running
get-casmailbox | set-casmailbox –activesyncenabled $false
on a regular basis or a schedule to ensure that all users in an organisation are disabled, then running cmdlets to re-enable on a group by group or user basis. Alternatively, by using the cmdlet extension agent (http://www.ehloworld.com/194) and this handy script (http://www.flobee.net/automatically-disable-activesync-for-new-mailboxes-in-exchange-2010) we can provision new users with ActiveSync already disabled. You can fine-tune individual users or groups through the application of policies, below.
Servers
By default, client access servers are enabled for ActiveSync, and SSL and basic authentication are set. It may be necessary to configure other forms of authentication such as RSA two-factor to suitably protect access to the environment. There is more information on this here.
Devices
By default, if a user is enabled for active sync (and by default they are) they can configure any device that supports ActiveSync to synchronise with the exchange server. It is just as easy to connect a cheap Chinese clone phone as it is a top of the range iOS device, although arguably no more harmful. It is therefore essential that mailbox policies are configured to properly control access to the exchange server. As noted above, there are many implementations of the ActiveSync protocol that pay little regard to the performance of the server and the impact the device may have on other users.
There are three main ways to manage these; mailbox policies, throttling and ABQ.
Mailbox Policies
As noted above users and devices require mailbox policies to be set correctly to control access and use of the exchange environment. This is a good article to start from to understand mailbox policies, but remember that not all devices will implement all settings. Mailbox policies allow you to set things like minimum password length and complexity for the device, and whether users are allowed to download attachments, how often they must refresh their passwords and so on.
Like most policy objects in exchange, there is a built in default policy which should be copied rather than altered, and then the copies altered and applied to users according to their need – so you might choose to prevent a group of users downloading attachments, or strengthen the security settings for users who have access to particularly sensitive material.
Another approach is to set policies according to the device, so for example, you can create a policy for Windows Phone 8 devices and a separate policy for iOS devices. You may also choose to differentiate between devices that are owned by the customer, and devices that are owned by the users themselves. The drawback with this approach is that the policy is always applied to the user, not the device, so if the user has multiple devices, or changes devices, then a policy change will be required. Notice that a user can only be assigned to one ActiveSync mailbox policy at a time, and setting a new policy removes any previous policy.
Client throttling
Client throttling is a new feature in exchange 2010 that is intended to prevent single users or groups of users taking down exchange by performing an unwitting denial of service attack. Now, it may be that your execs have been unknowingly co-opted as zombie shock troops by some shadowy criminal cabal, possibly in a secret volcano base, or it may be that they have just installed the latest version of iOS – personally, I find it hard to tell the difference. And exchange can’t differentiate either; in either case, it just stops working. The client throttling policy has sections for each access method – owa, ActiveSync, MAPI etc. – so you can set limits for critical indicators above which exchange will delay or simply deny connections to that user. Again, as with most exchange policies there is a default that is automatically applied to all users, which should not be altered; it should be copied, and then the copies tailored and applied to individual users or groups of users. As above, you can only apply one policy per user. Client throttling was originally “off” in RTM, but was switched on in SP1 by default, and has been further tweaked since then, so your default policy will depend on your service pack level – service pack 3, right? You can track the effect throttling has on your exchange environment using the instructions in this article.
The throttling policy itself can be a little tricky to understand; Elan Shudnow’s blog does a pretty good job of deciphering it – but remember this is for an earlier version of Exchange. I’d thoroughly recommend anyone who was looking to implement non-default policies do some serious reading. The MSExchange.org article and Chapter 10 of “Exchange server 2010 inside out” are also very good.
ABQ
Allow/Block/Quarantine lists are another new feature of Exchange 2010 that are intended to work together with mailbox policies. The policies allow you to control device *features*, whereas ABQ lists allow you to control which devices are allowed access. There is a great post on the Ehlo blog about the lists, and the work that went into designing them, and some generalisations about the way they are expected to be used – whether to block by default and only allow certain types of devices, or whether to allow or quarantine by default, and only block devices known to cause issues – iOS 6.1 take a bow.
Quarantine does not stop the device from connecting to exchange, only downloading content – so items may be added to calendars and other folders while the device is in quarantine – this can catch people out! For a full explanation of how this works, and screenshots, have a look at the msexchange.org pair of articles on mobile device management with Exchange 2010.
All three tools should be used to ensure that servers are appropriately secured, users have a suitable level of functionality and the organisation is protected from novel devices.
The future
There are some great features in Windows InTune , such as the ability to manage android devices with SCCM; the only drawback is that it is a subscription service. In the meantime, ActiveSync it is. If you follow the advice above and use the provided tools to limit your implementation, you should be fine.
503 5.0.0 polite people say HELO 
