DiscoverySearchMailbox in an Exchange 2007/Office 365 Hybrid environment causes DirSync errors
Whilst working on an Office 365-Exchange 2007 hybrid environment, you may experience errors similar to those shown below from the Directory Synchronization Error Report email and in Forefront Identity Manager:
|
Identity |
Error Description |
|
DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}@exchangelabs.co.uk |
Unable to update this object in Microsoft Online Services, because the attribute Username is not valid. Update the value in your local Active Directory. |
Why does this happen?
This is because as part of building your Hybrid environment, you’ll introduce Exchange 2010 servers into your environment as your Hybrid co-existence servers, running both the Client Access, Hub Transport but not the Mailbox role. When running the pre-requisite Active Directory Preparation a Discovery Search Mailbox, used in Exchange 2010 for storing the results of multi-mailbox searches.
In an full Exchange 2010 – Office 365 hybrid environment you won’t see this issue, because DirSync filters out any Discovery Mailboxes within the organization by checking (amongst other things) the mxExchMailboxTypeDetails attribute and if it’s set to the hexadecimal value 0x20000000, it will not exclude it from synchronization:
However the reason why it isn’t included within an Exchange 2007 hybrid environment is because the mailbox is never enabled – Discovery Search mailboxes do not exist in Exchange 2007. So as a “standard” user object, DirSync attempts to export it.
Correcting the issue in your Exchange 2007 Hybrid environment
Unfortunately, it’s not possible to enable the Discovery Search mailbox with the correct type from either the Exchange 2007 management console (you’ll just enable it as a normal mailbox) or the Exchange 2010 Hybrid Servers (you don’t have Exchange 2010 mailbox servers).
What you can do though is simply delete the Discovery Search Mailbox from the Users container of Active Directory.
Once deleted, synchronization will complete without an error about the Discovery Search Mailbox.. And that’s all there is to it until you decide to migrate your Exchange 2007 environment to Exchange 2010…
Re-creating the Discovery Search Mailbox if you install Exchange 2010 Mailbox Servers into your Hybrid environment.
If you need to re-create the Discovery Search Mailbox at a later date, it’s fairly straightforward – all you need to do is re-run the AD preparation for Exchange 2010. Let’s just walk through that process:
Locate the Exchange 2010 Service Pack 2 media and run the following command:
setup.com /PrepareAD
If at this point you have Exchange 2010 mailbox servers and wish to enable this as a proper Discovery Search Mailbox, first, check you can find the Discovery Search user from an Exchange 2010 Management Shell:
Get-User DiscoverySearchMailbox*
Assuming a single user is returned, simply enable it using the Enable-Mailbox cmdlet with the –Discovery parameter:
Get-User DiscoverySearchMailbox* | Enable-Mailbox –Discovery
And at this point, because you’ve got Exchange 2010 mailbox servers and enabled the Discovery Search Mailbox correctly (which will set the msExchRecipientTypeDetails attribute in Active Directory) you won’t see any DirSync errors either.
Steve
Solving iPhone and Exchange 2010/2007 coexistence issues
During my testing of our Exchange 2010 implementation I came across a rather annoying issue - iPhones users with Exchange 2007 mailboxes no longer can connect after moving the client access across to 2010.
So - what is supposed to happen? Well - as iPhone is supposed to implement EAS protocol version 12.1 (i.e. it supports AutoDiscover), it should be redirected to the legacy Exchange 2007 Client Access array. Problem is, it doesn't work.
Of course not all ActiveSync clients support AutoDiscover and those that implement EAS protocol 12.0 or lower are automatically proxied by the Exchange 2010 Client Access array back to Exchange 2007 client access servers.
This is all explained in more detail (including an acknoledgement not all clients implement EAS protocol 12.1 correctly!) over at the Microsoft Exchange Team blog in their article, Upgrading Exchange ActiveSync to Exchange 2010.
Whilst looking for solutions, I've unfortunately only came across verification this is a known issue, with the solution to simply wait for Apple to fix the iPhone. However I have a deadline to meet and getting IT staff to visit hundreds of iPhone users to change EAS settings isn't an option, it's not an option to move all those mailboxes at the same time, and we can't wait for a fix from Apple.
The most simple solution, as it stands - is to force all ActiveSync clients to be proxied. As noted in the MS Exchange Team blog article above, all non-internet facing site mailbox ActiveSync access is proxied anyway, so it will work. And thankfully, the proxying isn't based on AD sites. It's simply based on the ExternalURL on the ActiveSync virtual directory - if it's set to $null on the Client Access servers in the site of the user's Mailbox it will proxy instead of redirect.
If you want to do this via the Exchange Management Shell - it's simple - do this for each Internet facing client access server during the switchover:
Get-ActiveSyncVirtualDirectory -Server E2007CA | Set-ActiveSyncVirtualDirectory -ExternalURL:$nullThe implication of this is that there will be extra overhead associated with proxying Exchange 2007 ActiveSync users, so this would need to be factored into your plans should you implement my solution.




