Block badly behaving Exchange ActiveSync devices in Exchange 2013

Misbehaving Exchange ActiveSync devices can put a serious strain on your environment. Take control with new auto-block thresholds in Exchange 2013.

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. Apple iOS devices come to mind more often than most, due to their regular, over-the-air updates and a sizeable enterprise presence -- but they certainly aren't alone.

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:

Behavior Purpose
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).

Are there already auto-block thresholds in place?
Figure 1: First examine which ActiveSync device auto-block thresholds are already in place.

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

Configure an auto-block threshold.
Figure 2: Configure the auto-block threshold and include a notification message.

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>"

Enable a notification for mobile users.
Figure 3: Enable a device notification email message for all users.

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

An example of excessive ActiveSync requests
Figure 4: Example of an ActiveSync device making excessive requests (simulated).

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).

The iOS device user has received an error message
Figure 5: The end user has encountered an error message on his iOS device.

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:

According to the email notification, the offending device has been blocked
Figure 6: An example of an end-user notification email.

2013-03-06 01:27:06 192.168.15.103 POST /Microsoft-Server-ActiveSync/default.eas User=stevetest@stevieg.org&DeviceId= ApplDQGJ7DG5DTD2&DeviceType= iPhone&Cmd=Sync 443 stevetest@stevieg.org 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)

You can easily re-enable a blocked device
Figure 7: Immediately re-enable a blocked device.

Final thoughts

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

Dig deeper on Mobile Devices

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close