Exchange 2013 provides built-in functionality that will help protect your Exchange servers from ActiveSync devices that may be acting untowardly. This tip highlights that new functionality, as well as how to use it to get offending devices under control.
It seems every few months, smartphone manufacturers release updates that cause problems in IT.
The customizable nature of Android devices means that end-users can choose from a wide range of devices. The thing is, there are also hacks and custom firmware available. This allows for compatibility and support testing within an Exchange organization.
This tip examines a new feature in Exchange 2013 that helps alleviate some of the above described issues: ActiveSync device auto-block thresholds.
What do Exchange ActiveSync auto-block thresholds do?
Auto-block thresholds let admins configure limits on the number of times an Exchange ActiveSync device can perform a particular, pre-defined action over a period of time. It also lets them deny the device access to Exchange for however long they deem appropriate.
For example, you may determine that a device that sends 100 requests over the course of a minute is negatively affecting your Exchange environment. With auto-block thresholds, you can block the device for five minutes and notify the user (optional). This may be long enough to prevent damage to Exchange 2013 or -- if the user is doing something unusual -- discourage that activity.
If this sounds similar to ActiveSync throttling policies, you're on the right track. However, rather than effectively asking the device to back off nicely, auto-block thresholds deny the device access to Exchange ActiveSync and can even act on situations where the device repeatedly exceeds the budgets a throttling policy assigns. You have the option to ensure that the auto-block feature kicks in before throttling policies, or to use both alongside each other.
As of the time of this writing, only a small number of pre-defined categories are available for auto-block thresholds. That said, it's feasible that Microsoft could add others if deemed useful enough.
The current categories, or behaviors, as they are referred to within Exchange 2013, are as follows:
|UserAgentChanges||Provides a check against the number of times a device's user agent changes. For example, if an end user is experimenting with Android Firmware.|
|RecentCommands||Provides a check against the device repeatedly sending the same command over a set period of time. For example, if an iOS device continually attempts to update the same appointment due to a software bug.|
|Watsons||Provides a method to block devices that cause an application crash.|
|OutOfBudgets||Provides a check against devices that repeatedly exceed throttling policy budgets.|
|SyncCommands||Provides a check against devices attempting to perform a repeated server synchronization using the same sync key.|
|CommandFrequency||Provides a check against devices repeatedly making any type of command-based request repeatedly.|
A key point to understand before implementing this feature in your production environment is what a normal, healthy Exchange ActiveSync device looks like. If you don't know how often devices in your organization typically make requests to Exchange, you risk inadvertently blocking devices that aren't doing anything wrong.
A great tool to consider here is Log Parser Studio, which has built-in reports that process ActiveSync information in IIS log files. ActiveSync Reporting Services, which is built into Exchange 2010 and Exchange 2013, is another option.
Implementing auto-blocks on Exchange ActiveSync devices
You must use two Exchange Management Shell cmdlets to view and control organizational settings for Exchange ActiveSync device auto-blocks: Get-ActiveSyncDeviceAutoblockThreshold and Set-ActiveSyncDeviceAutoblockThreshold.
Let's set up an example using the scenario I described earlier, which involved an ActiveSync device that sent 100 messages in a single minute. In the example, we'll examine the policies already in place, and then configure Exchange 2013 to block overly chatty devices. Let's also base the example on the aforementioned CommandFrequency category (described in the table above).
First, use the following command to view existing settings. Note that it is formatted to view relevant information in an easy-to-read, filtered format (Figure 1).
Get-ActiveSyncDeviceAutoblockThreshold | Select BehaviorType,BehaviorTypeIncidenceLimit, BehaviorTypeIncidenceDuration,DeviceBlockDuration
As you can see in Figure 1, there are currently no settings configured. We'll now implement the configuration mentioned earlier, which will block devices that make over 100 command requests within a minute, for a period of five minutes. We'll also set a notification message for the user (Figure 2).
Set-ActiveSyncDeviceAutoblockThreshold CommandFrequency -BehaviorTypeIncidenceLimit 100 -BehaviorTypeIncidenceDuration 00:01:00 -DeviceBlockDuration 00:05:00 -AdminEmailInsert "<p>Your device has been blocked for 5 minutes due to excessive requests</p>"
If you want to enable the email notifications set on each behavior category for all your users, use the following command (Figure 3).
Set-ActiveSyncDeviceAutoblockThreshold EnableNotificationEmail -BehaviorTypeIncidenceLimit 1
Now that the proper configuration is in place, I have simulated this condition by making repeated requests to Exchange 2013 by constantly refreshing mail on my device. As suspected, making 100 end-user requests is actually quite hard (Figure 4).
Once the auto-block threshold is triggered, it's immediately evident to the user that something is up. The message the end user sees, however, isn't particularly informative. On iOS devices, for example, users will receive the message displayed in Figure 5.
When the user checks his email via Outlook Web App or the Outlook client, he'll see the email notification we've configured, along with the auto-block configuration. Thankfully, the email is considerably more descriptive than the previous message (Figure 6).
At the server side, the intentional failure that results from the device attempting to access Exchange is logged in the IIS log files as a "503 Service Unavailable" error:
2013-03-06 01:27:06 192.168.15.103 POST /Microsoft-Server-ActiveSync/default.eas Userfirstname.lastname@example.org&DeviceId= ApplDQGJ7DG5DTD2&DeviceType= iPhone&Cmd=Sync 443 email@example.com 192.168.15.109 Apple-iPhone4C1/1002.146 - 503 0 0 20030
If you've specified a period longer than the five minutes we've implemented here, there might be a time when you need to quickly re-enable access for a user. This is easily accomplished using the ResetAutoBlockedDevices switch with the Set-CASMailbox cmdlet (Figure 7)
As you can see, this is another solid example in a line of new Exchange 2013's features. Although it's a relatively small addition, it can prove extremely helpful when mitigating the unintended consequences of a BYOD environment or simply one where end users rely on consumer-grade devices.
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 June 2013