I better get these notes out of my head before I forget them since it took me hours in the lab to figure it out. It seems like I’m not the only one and based on Social Forum discussions I can read there’s a lot of confusion. This is my part to make it somewhat clearer and yes, it almost made me cry figuring it out too…

Consider the following scenario: All your users are in forest corp.local and running Exchange 2010. AutoDiscover is properly configure so that users can start Outlook 2010 both internally and externally and get their profile automatically created? (BTW, here’s my post on how to make first-time-run Outlook really silent).

Now, your company decides to split and 4000 users need to get out both AD and Exchange. That’s where you come in. You setup a new remote.local AD forest and migrate (using ADMT or QMM) over all users and groups. Then the computers and last servers but you decide to leave Exchange 2010 migration for last because you got your hands full – you say: “they can still access their mailbox because of SIDHistory and we can’t cope to re-configure all ActiveSync devices right now which has CORP\username configure”. And I don’t blame you, that’s how we did it back in Exchange 2003 🙂

So you think it works, users can access their e-mail, but a few days (hours?) down the road, Outlook 2007+ user complain they can’t see Free/Busy information nor set Out-Of-Office reply, but it works in OWA. And top of that, AutoDiscover doesn’t work properly – the user has to manually enter their name, e-mail address and password (but sure, when they hit Next> it works, but still not as it should be:

You start googling (hopefully you get here first to save you some headache)…

AutoDiscover working in cross-forest migrations

You probably read about Export-AutoDiscoverConfig so you set:

$a = Get-Credential and set an admin in REMOTE\

Export-AutoDiscoverConfig -DomainController DC1.corp.local -TargetForestDomainController DC1.remote.local -TargetForestCredential $a -MultipleExchangeDeployments $false

Great, that creates an SCP record in AD (BTW, once you’re done you delete this using Export-AutoDiscoverConfig cmdlet and parameter -DeleteConfig $true). Where it’s yellow is where you should find the source domain, here that is corp.local.

But AutoDiscover still doesn’t work? Well, the first thing Outlook does when it starts is to check for the user’s e-mail address and that is the mail attribute and without that it can’t auto configure Outlook. Microsoft’s documentation seem to miss that small but important detail?!

One may ask how you should get the 4000 e-mail addresses from the source to the destination forest? Well, that’s for another post but I would suggest looking into ADModify.NET or use your Powershell skills. So now you should have AutoDiscover working. Next, it’s time to get…

Free/Busy and OOF (Out-Of-Office) working in cross forest migrations

I suppose you just migrated the user over and did nothing to the mailbox? Well, it turns out you have to convert the standard mailbox to a Linked Mailbox. Yes, that is true. Even though they can access their mailbox, you still have to convert it to a Linked Mailbox to get Free/Busy and OOF working – otherwise you will get:

• When checking Free/Busy it says No information.
• When trying to set OOF you get an error message: Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later .

Here’s how to convert a mailbox to a Linked Mailbox. Some caveats before you go ahead and convert thousands of mailboxes:

• Don’t read the comment in the above article and use Set-User instead. As told to me by MS Support:
  First, when you do it the Microsoft way, the source user is Disabled. It will work to disable it manually BUT I want to stress that things might break. Consider that you link an enabled user A to his counterpart in the account forest. Then another user gives some kind of permission on a PF, calendar or mailbox level on user A.This action will take the wrong SID and will not apply the correct permission on the MasterAccountSid (which is the linked user). This is because the user A is still enabled. 
• Since the user in source forest is disabled, this means they no longer can login with the source CORP\ but have to use REMOTE\. That also goes for ActiveSync devices. Sure, many organizations use UPN (which in fact is their e-mail address) to login, but I’ve seen many customers where they either don’t or can’t use UPN.

Now, these are just my findings in my lab… So please comment if you think it works differently!