Exchange 2010 Error “The ActiveSyncDevice Cannot be Found” When Performing a Remote Wipe

In the comments of my article on user-initiated remote wipes for Exchange ActiveSync devices, Jonathan has described a situation in which administrator-initiated remote wipes fail if the user account has been moved to a different OU after the ActiveSync device association was created.

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00
Mahera Bawa\Apple-iPhone2C1/902.206
Failed

Error:
The ActiveSyncDevice exchangeserverpro.net/Company/Head Office/Users/Mahera.Bawa/ExchangeActiveSyncDevices/iPhone§Appl87941C1N3NS cannot be found.
Click here for help… http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.2.309.2&t=exchgf1&e=ms.exch.err.Ex0FBD0C

Exchange Management Shell command attempted:
Clear-ActiveSyncDevice -Identity ‘exchangeserverpro.net/Company/Head Office/Users/Mahera.Bawa/ExchangeActiveSyncDevices/iPhone§Appl87941C1N3NS’

Elapsed Time: 00:00:00

Reproducing the Error

Consider the following scenario:

1. A user connects a new mobile device to Exchange ActiveSync
2. The user object is later moved to a different OU
3. The user leaves the organization
4. A remote wipe is issued for the device by an administrator, using the Exchange Management Console

In this situation the error occurs.

The root cause of the issue, as identified by Jonathan in his comment, is a mismatch between the identity strings returned by two different cmdlets; Get-ActiveSyncDevice and Get-ActiveSyncDeviceStatistics.

Checking for the Problem in Your Exchange Organization

I’ve written this short script to check for the issue.

$easdevices = @(Get-ActiveSyncDevice)

foreach ($easdevice in $easdevices)
{
    $easdevstats = Get-ActiveSyncDeviceStatistics $easdevice

    Write-Host $easdevice.UserDisplayName -NoNewLine

    if ($($easdevice.Identity.ToString()) -eq $($easdevstats.Identity.ToString()))
    {
        Write-Host -ForegroundColor Green " - IDs match"
    }
    else
    {
        Write-Host -ForegroundColor Red " - IDs don't match"
        Write-Host -ForegroundColor Yellow $easdevice.Identity
        Write-Host -ForegroundColor Yellow $easdevstats.Identity
    }
}

Copy that code into Notepad or your ISE and save it as EASDeviceIDs.ps1, then run it from the Exchange Management Shell.

If all is well then you should see a result similar to this:

If there are any mismatches detected you should see this type of result instead:

Looking closer at the two yellow identity strings, the problem is clear. When the user was moved from Head Office to Branch Office the mismatch was created.

Resolving the Problem and Performing a Remote Wipe

The most obvious solution is to move the user object back to its original OU. However this is not always going to be practical, so other options are needed.

According to my testing the different remote wipe options have the following results.

User-Initiated Remote Wipe via Exchange Control Panel

If the user themselves performs a remote wipe via the Exchange Control Panel it still works, and the device is wiped successfully assuming all other requirements are met.

Administrator-Initiated Remote Wipe via Exchange Management Console

A remote wipe issued from the EMC will fail if the user object is not first moved to its original OU at the time the device association was created.

Administrator-Initiated Remote Wipe via the Exchange Control Panel

As with the user-initiated remote wipes this option appears to work fine even if the identity mismatch is occurring.

Administrator-Initiated Remote Wipe via the Exchange Management Shell

If an administrator uses PowerShell and the Clear-ActiveSyncDevice cmdlet to perform the remote wipe, it will be successful as long as the correct identity is specified.

I’ve written a script to detect the mismatch and use the correct identity for the remote wipe.

Firstly, if the user has no ActiveSync devices associated then the script will not do anything further.

If the script detects a device association but the identity values match, then it will let you know and do nothing further.

If the script detects an identity mismatch, then it will let you know and then initiate the remote wipe using the identity that will work. You’ll be prompted to confirm this.

In my own test lab this seems to work fine however there may be real world scenarios where it does not, so please feel free to leave a comment below if you encounter a situation that this doesn’t fix.

Here is the script code.

param (

    [parameter(mandatory=$true, ValueFromPipeline=$true)]
    [string]$user

)

$mailbox = Get-Mailbox $user
$name = $mailbox.Name
$easdevices = @(Get-ActiveSyncDevice | where {$_.UserDisplayName -like "*$name"})

$count = $easdevices.count

Write-Host -ForegroundColor Yellow "$count ActiveSync devices found for $mailbox"

foreach ($easdevice in $easdevices)
{
    $easdevstats = Get-ActiveSyncDeviceStatistics $easdevice

    if ($($easdevice.Identity.ToString()) -eq $($easdevstats.Identity.ToString()))
    {
        Write-Host -ForegroundColor Green "IDs match, normal remote wipe process should work."
    }
    else
    {
        Write-Host -ForegroundColor Red "IDs don't match"
        Write-Host $easdevice.Identity
        Write-Host $easdevstats.Identity

        Clear-ActiveSyncDevice -Identity $easdevice.identity

    }
}

Copy the code into Notepad or your ISE and save it as Clear-EASDevice.ps1. To execute the script run a Get-Mailbox for the mailbox you want to target, and pipe that into the script.

Get-Mailbox mahera.bawa | .\Clear-EASDevice.ps1

You can append an notification email address to the Clear-ActiveSyncDevice command in the script as well, for example:

Clear-ActiveSyncDevice -Identity $easdevice.identity -NotificationEmailAddresses administrator@exchangeserverpro.net

Summary

This appears to simply be a bug in how Exchange detects a user object that has moved between OUs and does not update both identity values correctly.

Or perhaps the issue is that the Clear-ActiveSyncDevice cmdlet as it is executed from the management console is referencing the wrong object’s identity value, since we seem to be able to work around the problem by specifying the correct one in the shell.

You may find it simpler to just use the Exchange Control Panel to initiate your remote device wipes. However the scripted option is available if you prefer that.