This is the text of an article that I wrote for Windows IT Pro magazine that was never published. It might be of some interest and use to folks grappling with ActiveSync partnerships, so I decided to publish it here. Enjoy!
Update: See this post for information about how Microsoft has automated some aspects of partnership management in Exchange 2013, Exchange 2016, and Exchange Online (Office 365)
Managing Exchange ActiveSync device partnerships
An interesting aspect of the Bring-Your-Own-Device (BYOD) device phenomena allied to the growing role of Exchange ActiveSync (EAS) as the de facto protocol for mobile device connectivity is that some organizations running Exchange 2010 SP1 or later releases have experienced situations where users have exceeded the number of permitted ActiveSync partnerships for their mailbox. When this happens, Exchange sends a message to the user the next time that they attempt to add a new device to their mailbox:
Subject: Error with your new mobile phone partnership
Importance: High
You have 10 phone partnerships out of the maximum allowed 10 partnerships. After you reach the maximum, you can’t create additional partnerships until you delete existing ones from your account. To do so, sign in to Outlook Web App, click Options > Phone > Mobile Phones, and delete any unused partnerships.
In this article I explain how Exchange 2010 manages ActiveSync device partnerships and how you can increase the number of partnerships allowed for a mailbox, plus how to locate old partnerships that might belong to devices that are no longer in use and then how to script a procedure that you could run on a regular basis to remove obsolete partnerships. Unless otherwise indicated, the code listed here should work well with Exchange 2010, Exchange 2013, or Exchange Online (Office 365). The explanation of how Exchange throttles ActiveSync connections is specific to Exchange 2010 SP1 and later releases.
Storing ActiveSync partnerships
Figure 1: Listing ActiveSync partnerships from Outlook Web App (Exchange 2010)
Exchange 2010 and Exchange 2013 store details of ActiveSync device partnerships (the connection between a mobile device and a mailbox) as properties of the Active Directory account that owns the mailbox. Although there’s no technical reason that limits Active Directory to storing more than 10 partnerships, someone in the Exchange development group took the view that ten seemed a good number, certainly sufficient to meet the needs of all but the most hyper-connected user. The restriction on ActiveSync partnerships through throttling policies was first introduced in Exchange 2010 SP1 and also applies to Exchange Online tenant organizations in Office 365. The limit proved appropriate until recently when BYOD challenged the assumption that users would be happy with ten devices.
I don’t consider myself to be anything more than averagely connected, so I decided to follow the advice in the message and use Outlook Web App (OWA) to check what partnerships are registered for my mailbox. As shown in Figure 1, OWA duly reported that four partnerships were in place.
I only use one of these partnerships on a regular basis. Fortunately, much of the mystery behind a partnership can be dispelled by clicking on the Details icon, which reveals the information about the selected partnership shown in Figure 2. In this case the partnership links my Windows Phone (Nokia Lumia 800 at the time the article was written) with Exchange. We can see the version of the phone O/S (7.8) and various other information, including (if you scroll to the bottom), the version of ActiveSync used by the connection and the number of folders that Exchange synchronizes with the device.
Figure 2: Viewing partnership properties
Four partnerships seemed like three too many. The most obvious of the other partnerships was for an old iPhone 3GS that I used before I bought my Nokia. The others were surprising: “TestActiveSyncConnectivity” was created by the Exchange Remote Connectivity Analyzer to test ActiveSync connectivity while “WindowsMail” was created by the Windows 8 Mail application to synchronize with my Exchange Online mailbox.
Even though Outlook 2013 uses ActiveSync to connect to Hotmail (or Outlook.com) instead of the older Hotmail connector, you won’t find this connection listed as an ActiveSync partnership. It is, after all, not used to connect to an Exchange mailbox.
Given that I have two surprising partnerships, it’s easy to see how someone who has been using Exchange 2010 for a while and likes to experiment with the many varied mobile devices that you can connect to Exchange with ActiveSync (iPhone, iPad, Windows Phone, and lots of different Android devices) might exceed the limit. To get an overview from an organization perspective, you could use MVP Brian Desmond’s script to create a CSV file containing details of the partnerships known for all mailboxes (Figure 3).
Figure 3: Viewing a CSV file containing device partnership data
Manipulating a CSV file with Excel is an effective way to understand what kind of mobile devices are connecting to Exchange, including some that might surprise because you didn’t expect to find them listed. Larger organizations might prefer to load the data into a more robust query and reporting tool such as Access or even SQL.
Increasing the limit for ActiveSync partnerships
The limit is controlled by the EASMaxDevices property in the throttling policy applied to the mailbox. Throttling policies serve to restrict the amount of system resources that an individual mailbox can consume and were first introduced in Exchange 2010 SP1. Unless assigned a specific throttling policy, every mailbox comes under the control of the default throttling policy, which sets EASMaxDevices to 10. You can therefore increase the limit by either updating the default throttling policy to allow the desired number of partnerships or by creating a new throttling policy and then applying that policy to the mailboxes of the hyperconnected users.
For example, if your organization only has a default throttling policy, the following Exchange Management Shell (EMS) command will increase the limit to allow twenty partnerships:
Get-ThrottlingPolicy | Set-ThrottlingPolicy –EASMaxDevices 20
It’s possible that your users might want to use all of their ActiveSync devices at one time. If so, you should also updated the EASMaxConcurrency property to the same value as EASMaxDevices.
The *-ThrottlingPolicy cmdlets are only available to on-premises administrators. The reason being that Microsoft doesn’t want its cloud tenant administrators messing around with commands that have the potential to affect other tenants.
The alternative is to create a new throttling policy. The following commands create a new policy that contains the desired settings (the other settings for the policy will be inherited from the default throttling policy) and then applies the new policy to a specific mailbox:
New-ThrottlingPolicy –Name “HyperConnected ActiveSync” –EASMaxDevices 20 –EASMaxConcurrency 20
Set-Mailbox –Identity “Tony” –ThrottlingPolicy “HyperConnected ActiveSync”
Immediately the Set-Mailbox cmdlet runs successfully, the user will be able to create additional partnerships.
Locating old partnerships
It’s the nature of mobile devices that some are quickly discarded as new and more attractive devices become available on the market. However, these devices leave a lingering indication of their presence as an ActiveSync partnership that will eventually have to be removed to keep a user under their permitted limit.
OWA allows users to remove partnerships using the delete (X) option shown in Figure 1. However, the problem with relying on this strategy is that users are unlikely to know about the option (how many users know about ActiveSync partnerships) and so they’ll never navigate through the OWA options to the right place. Even if they find the option to list partnerships, even fewer will be brave enough to delete a partnership on the basis that they won’t know if this action will affect their other mobile devices. All in all, cleaning up the debris of obsolete partnerships is likely to remain a task for Exchange administrators.
Neither the Exchange Management Console (EMC) nor the Exchange Control Panel (ECP) contain options to allow an administrator to manage device partnerships across the organization. EMC ignores ActiveSync completely, possibly on the basis that Microsoft knew that they were going to replace this console with the new Exchange Administration Center (EAC) in Exchange 2013. ECP knows about partnerships, but only if you take the option to “Manage another user” to be able to access the partnerships for a selected user. The options presented by ECP under “Manage your organization” are restricted to ActiveSync device access settings. There’s nothing for it but to resort to PowerShell.
Two cmdlets are of interest. The first is Get-ActiveSyncDevice (or, if you want to be fashionable and use Exchange 2013, the Get-MobileDevice cmdlet, as it will eventually replace Get-ActiveSyncDevice), which returns information about devices known through partnerships with a mailbox. For example, the following command returns information about all the device partnerships associated with my mailbox:
Get-ActiveSyncDevice –Mailbox “Tony”
The information shown is essentially that displayed in Figure 2. As with many PowerShell cmdlets, the output can be a tad verbose. A better command that limits the information to the essential information is:
Get-ActiveSyncDevice –Mailbox “Tony” |Format-List DeviceId, DeviceType, DeviceModel, DeviceOS, FriendlyName, Name
The following information is displayed for each device:
DeviceId : 1140B5A5508D422741F2E87CE114E115
DeviceType : WP
DeviceModel : NOKIA
DeviceOS : Windows Phone7.10.8773
FriendlyName : Tony's Nokia
Name : WP§1140B5A5508D422741F2E87CE114E115
The DeviceId property is important if you need to focus in on a specific device from a list. For example, to delete the partnership for the device shown above, I can use the command:
Get-ActiveSyncDevice | where {$_.DeviceId -eq “1140B5A5508D422741F2E87CE114E115”} | Remove-ActiveSyncDevice
It’s possible that you’ll find two entries in the list for the same device. From experience, this seems to happen when a device goes through a factory reset and is then used to create a new ActiveSync partnership. The clue as to which partnership is active and which belongs to the device prior to its reset is the date that the last synchronization occurred, which brings us to the reason why a second cmdlet is required.
Although it’s a useful command to get started with, Get-ActiveSyncDevice doesn’t tell us what partnerships might be obsolete because it doesn’t report information about the synchronization state of a device. It’s reasonable to assume that a device is active and in use if it is synchronizing regularly with Exchange. On the other hand, if a device has not synchronized in the last 90 or 120 days, there’s a fair chance that it has been tossed into a desk drawer or found some other dark corner to hide.
The Get-ActiveSyncDeviceStatistics cmdlet comes to our aid. This cmdlet reports information about device activity. Thus, a command like this will provide us with a good overview of the device activity for a specific mailbox:
Get-ActiveSyncDeviceStatistics –Mailbox “JSmith” | Format-Table DeviceID, DeviceType, FirstSyncTime, LastSuccessSync
DeviceID DeviceType FirstSyncTime LastSuccessSync
-------- ---------- ------------- ---------------
ApplV50396X7Z38 iPad 06-08-2012 10:48:23 11-08-2012 22:54:42
Appl820101JN3NP iPhone 06-08-2012 10:48:23 03-05-2012 15:28:56
Appl87945F3Q3NQ iPhone 06-08-2012 10:48:23 16-02-2012 23:36:07
ApplDNQHHGDLDTD2 iPhone 06-08-2012 10:48:23 17-08-2012 07:32:51
This article was written on August 17, 2012 (shown as 17-08-2012 on my system), so we can see that two of the devices have been synchronized reasonably recently (the first and last in the list) whilst two others haven’t been synchronized since May 3 and February 16 respectively. These two partnerships are therefore candidates to be removed on the basis that they are defunct. Of course, there might be a good reason why the user hasn’t synchronized a device for a long time. For instance, they might keep a device as a backup in case their primary device fails. For this reason, it’s a good idea to check with users before expunging anything.
Get-ActiveSyncDeviceStatistics can also provide an interesting insight into the mobile devices that are in use within the organization. For example, this code forms a collection of user mailboxes, then uses that collection to scan for all the mobile devices that have partnerships with the mailboxes before finally producing a count for each device type. As you can see from the results, Apple is clearly winning the battle for mobile devices in this organization.
$Mbx = Get-Mailbox –RecipientTypeDetails UserMailbox –ResultSize Unlimited
$Mobile = $Mbx | %{Get-ActiveSyncDeviceStatistics –Mailbox $_.Identity}
$Mobile | Group-Object –Property DeviceType –NoElement
Count Name
----- ----
1 WindowsMail
17 WP
21 iPad
113 iPhone
If you substitute “DeviceUserAgent” for “DeviceType” in the last line of code, you’ll get a count of the different versions of operating systems in use. This can be an interesting way to discover whether some obsolete or unusual mobile devices are connected.
Scripting to expunge old devices
Now that we understand the capabilities of the two cmdlets that report information about ActiveSync devices, we can put everything together to create a procedure that can be run on a periodic basis to expunge obsolete device partnership. On the basis that there’s usually some previous work that can be found on the Internet to provide a good start, you use the script provided by MVP Mike Crowley and adapt it to meet your needs. The script features all of the cmdlets that we’ve explored and is as follows:
$DevicesToRemove = Get-ActiveSyncDevice -Result Unlimited | Get-ActiveSyncDeviceStatistics | Where {$_.LastSuccessSync -le (Get-Date).AddDays(“-30”)}
$DevicesToRemove | Remove-ActiveSyncDevice
Going through the code we find:
- A variable is used to collect the set of device partnerships is created ($DevicesToRemove).
- The variable is populated as a result of running the Get-ActiveSyncDevice and Get-ActiveSyncDeviceStatistics cmdlets
- The call to Get-ActiveSyncDevice collects all device partnerships in the organization (-Result Unlimited). In large organizations you might restrict this to look for specific devices (for example, process all iPhones in one run, all iPads in another, Android devices in a third).
- The output from Get-ActiveSyncDevice is piped to Get-ActiveSyncDeviceStatistics, which will process each device in turn and check to see if the last successful synchronization date (LastSuccessSync) is more than 30 days ago. You could increase this interval to be whatever you need.
- Any devices that meet the criteria are added to the variable, which is then piped as input to the Remove-ActiveSyncDevice cmdlet to remove the device partnerships.
If this script doesn’t meet your needs, there are others available on the Internet. For example, here’s some code that takes a slightly different approach by beginning with a call to the Get-CASMailbox cmdlet and filtering the results so that only mailboxes with an ActiveSync device partnership are processed.
Get-CASMailbox -ResultSize unlimited -Filter{(HasActiveSyncDevicePartnership -eq $true) -AND (name -notlike “cas_*”) -AND (name -notlike “DiscoverysearchMailbox*”)} | ForEach {Get-ActiveSyncDeviceStatistics -Mailbox $_.Identity | Where-Object {$_.LastSuccessSync -le ((Get-Date).AddDays(“-7”))} | Remove-ActiveSyncDevice}
As with all scripts, it’s wise to test this code on a non-production server to make sure that it does what you need.
Summary
Exchange ActiveSync has come a long way since it was first released in Exchange 2003 SP2 in 2005. Microsoft’s success in licensing ActiveSync to companies such as Apple and Google has greatly assisted the spread and widespread adoption of the protocol. As we head further into the BYOD era, the need exists to manage ActiveSync more thoroughly than before. Making sure that device partnerships remain current is part of that work. It’s easy to do, once you know what’s happening and have a little PowerShell code to hand.
Follow Tony @12Knocksinna
Thoughtsofanidlemind's Blog 