Unable to Remove an ActiveSyncDevice from an Account

I’ve noticed an issue sometimes occurs when attempting to remove an activesync device relationship from a user’s mailbox. This behavior happens frequently with users who have left the company recently. All attempts to remove the device via the Manage Mobile Phone action in the Exchange console results in a device not found error. I hadn’t noticed a pattern to this behavior until today.


When a user leaves the company, the help desk usually moves the user’s account to the different OU in Active Directory (in our case, it's the "Disabled" OU). Although each device’s Identity and DistinguishedName properties reflect the new location of the account, it would appear that the Remove-ActiveSyncDevice command only looks at the UserDisplayName property, and that property does not get updated – it continues to reflect the location of the account at the time the device relationship was created. This causes the command to fail, since the object no longer exists at that location in AD. Here’s an example of a device that belongs to a former associate. Notice the highlighted fields, which show two very different locations.

UserDisplayName : domain.local/Field Management/District Managers/Joe Blow
Name : MOTOBLUR30
DistinguishedName : CN=MOTOBLUR30,CN=ExchangeActiveSyncDevices,CN=Joe Blow,OU=Disabled,DC=domain,DC=local
Identity : domain.local/Disabled/Joe Blow/ExchangeActiveSyncDevices/MOTOBLUR30
Guid : e6078fc3-bcff-43c9-a334-8c74e075d558
ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Active-Sync-Device

To work around the problem and remove the device, go to the Exchange shell and run the following command:

Get-ActiveSyncDevice | where {$_.userdisplayname –like “*Joe Blow”} | Remove-ActiveSyncDevice

You will be prompted to confirm each device to be deleted, which is handy if the user has multiple devices and you only want to delete a particular device.

Auditing Administrative Changes in Exchange 2010

Exchange 2010 maintains a hidden mailbox that logs all administrative changes. The "Hey Scripting Guy" blog recently published an article that explains how to retrieve that information with powershell. If you ignore the remoting stuff at the top of the article (that can confuse or discourage some people), the auditing commands can be run directly from the management shell on any of the Exchange 2010 servers. I've always wanted this sort of visibility into who's doing what in Exchange, so I wanted to talk about it some more. But go read this article first:

http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/25/use-powershell-to-audit-changes-made-to-exchange-server-2010.aspx

For example, to get a list of all the new mailboxes created in the last day, use this command:

Search-AdminAuditLog -StartDate (get-date).adddays(-1) -EndDate (get-date) -Cmdlets enable-mailbox

Which produces this output:

RunspaceId         : 7d4bc202-de70-4c2f-a146-263d05445ea8

ObjectModified     : domain.local/Headquarters/Contractors/Cristin Broom

CmdletName         : Enable-Mailbox

CmdletParameters   : {Identity, Alias}

ModifiedProperties : {Extensions, PoliciesIncluded, EmailAddressPolicyEnabled, PoliciesExcluded, RecipientTypeDetails,

                     RejectMessagesFrom, RecipientTypeDetailsValue, AcceptMessagesOnlyFromDLMembers, ArchiveName, UseDa

                     tabaseQuotaDefaults, OriginalPrimarySmtpAddress, ElcExpirationSuspensionEnabled, ServerLegacyDN, I

                     sMailboxEnabled, ReadOnlyPoliciesIncluded, IsValidSecurityPrincipal...}

Caller             : domain.local/Headquarters/Information Systems/Operations/Don Drieberg

Succeeded          : True

Error              : None

RunDate            : 1/26/2012 9:20:46 AM

OriginatingServer  : EXCH01 (14.01.0323.001)

Identity           : RgAAAACsFGTJn7mcTJ0+hnPZuWZoBwCmwLQTE/orS6kUJLJIy+JCAAAAkH9zAACmwLQTE/orS6kUJLJIy+JCAAAQcrvYAAAJ

IsValid            : True

From this, we can see that Cristin Broom's mailbox was created on 1/26 at 9:20 am by Don Drieberg.

The audit mailbox retains data for 90 days by default, and contains records of changes to all Exchange objects – mailboxes, distribution groups, contacts, connectors, inbox rules, etc. It doesn't log all of the details, though. For instance, although it logs mailbox changes, including which properties were changed, it doesn't include the value (before or after) of those properties. You just know that it was changed somehow. Still could be very handy for auditing. A simple command like this:

Search-AdminAuditLog -StartDate (get-date).adddays(-7) -EndDate (get-date) -Cmdlets new-distributiongroup | fl objectmodified, caller

Can show me any new distribution groups that were created in the past week:

ObjectModified : domain.local/Distribution Lists/CORP - IS-QA for Trade Hold

Caller         : domain.local /Headquarters/Information Systems/Operations/Don Drieberg

ObjectModified : domain.local/Ireland/Distribution Lists/Tax

Caller         : domain.local/Ireland/Users/IT/Admin. Accounts/Sarah Monet

If you don't supply a StartDate or EndDate, your query will return matches for the entire retention period (90 days, by default), which could be quite a lot of information.
If you don't supply a Cmdlets parameter, your query will return matches for all cmdlets.

Of course, you can always pipe the output through a Where-Object clause, to filter the results.

For more information about audit logging, see the Administrator Audit Logging section of the TechNet library.

- Mike

Quickly Retrieving Send-On-Behalf-Of Users

This morning, I needed to verify and provide a list of users with Send-On-Behalf-Of rights to a particular mailbox, and all the usual powershell methods showed the field, but ended with an ellipsis, so I couldn’t be certain that there weren’t more users than what I was seeing. I needed a quick way to view the complete list. After some playing around, I ended up with this nifty one-liner:

[PS]>foreach ($sender in (get-mailbox Mailbox2BeChecked).GrantSendOnBehalfTo) { $sender.tostring() }

This resulted in a nice, complete list of user DNs.

domain.local/Ireland/Users/IT/User1

domain.local/Ireland/Users/IT/User2

domain.local/Ireland/Users/IT/User3

domain.local/Ireland/Users/IT/User4

Search For A Specific Folder

A recent snafu in our deployment of managed folders for email archiving resulted in duplicate folders in a few dozen mailboxes. I didn't know about the duplicate folders at the time it occurred, and none of the affected users reported the "extra" set of folders for over a month.

We use an Exchange managed folder mailbox policy to push a set of managed folders to each mailbox. When created by Exchange this way, the folders can't be modified by the user, which allows Enterprise Vault to apply a consistent archiving and retention policy to the contents of these folders.

If the Enterprise Vault (EV) provisioning process runs before the managed folders are created by Exchange, it causes two problems - (1) the EV-created folders are not managed by Exchange, which means that users can modify or even delete them, (2) and when Exchange tries to create the managed folders, it finds those folder names already exist, so Exchange creates a new set of folders with a slightly different name ("Managed Folders1"). The result is one set of folders targeted for archiving by EV, and another set of folders being managed by Exchange.

If we catch the problem early enough, before the user has moved any messages into either set of folders, then the fix is fairly easy.

1. Open the mailbox in Outlook or OWA, and delete the Managed Folder hierarchy that was created by Enterprise Vault
2. From an EMS prompt, remove the managed folder mailbox policy and folders.
       Set-Mailbox -Identity "mailboxID" -RemoveManagedFolderAndPolicy
3. If the folders are empty, the previous command will delete the entire managed folder hierarchy. Then all we have to do is set the policy again.
       Set-Mailbox -Identity "mailboxID" -ManagedFolderMailboxPolicy
4. And then run the assistant to actually push the new set of managed folders to the mailbox.
       Get-Mailbox -Identity "mailboxID" | Start-ManagedFolderAssistant

What does all that have to do with searching for a folder? Well, after fixing the reported mailbox, I was curious about how many others were out there that hadn't been reported. I needed to find every mailbox that had a "Managed Folders1" folder in it. Here's what I came up with.

$mbxs = Get-MailboxDatabase | Get-Mailbox -ResultSize unlimited

$y = @()

foreach ($mb in $mbxs)

{

    $x = Get-MailboxFolderStatistics $mb | where {$_.Name -match "Managed Folders*"} | Select Name

    $x | Add-Member -MemberType NoteProperty -Name "DisplayName" -Value $mb.DisplayName

    $y += $x

}

$y | where {$_ -AND $_.Name -eq "ManagedFolders1"} | sort DisplayName

It took a few minutes to run through our 3000+ mailboxes, but in the end, I discovered another 72 mailboxes that had Managed Folders that had been deployed incorrectly. Now, the time-consuming task of fixing them, as detailed above, begins. Bummer.