MRS v’s Third Party Tools Part 2. Outlook Profile Redirection

Outlook Profile Redirection is probably one of the most commonly discussed topics when it comes to Office 365. It’s certainly a conversation I have repeatedly.

How do I make my Outlook profile point at my Exchange Online mailbox?

MOVING MAILBOXES WITH MRS

Well, if you have moved mailboxes with the MRS, you’re done.

It just works if you have things set up correctly.

I have AAD Sync set up to include the msExchMailboxGUID, and Exchange 2010 on prem in hybrid mode.

I have a mailbox configured locally in cached mode with an OST file.

CachedwithOST

I set up a migration batch, and move this mailbox to Office 365.

After the mailbox move has been completed, I get the familiar warning pop up in Outlook.popup

I close Outlook and when I re-open I’m now connected to Office 365 with the same OST file.

OST after move

This is quite significant. The fact that I have the same profile means I keep things like folder views, delegates and PST files.

The fact that I retain the OST file negates the need for Outlook to re-cache mailbox data post migration.

In a recent migration from Notes to Exchange, we found that it took the clients eight hours to cache the data we could move server side in two.

I have glossed over some steps, password sync, licensing mailboxes, but essentially you get the gist.

The MRS log file is quite interesting, and explains a little bit about what happens in the background.

04/12/2014 20:35:36 [DB4PR04MB313] Mailbox signature will not be preserved for mailbox ‘BlendedSponges.onmicrosoft.com\7984da39-5388-4816-98d9-2550248694e6 (Primary)’. Outlook clients will need to restart to access the moved mailbox.

04/12/2014 20:37:58 [DB4PR04MB313] Move has completed and final cleanup has started.

04/12/2014 20:38:10 [BSEX] The mailbox was converted into a mail user using domain controller ‘BSDC2.BlendedSponges.com’.

After the move is complete, the mailbox is removed from the user on prem, and the user is mail enabled with targetAddress set.

The targetAddress is the key to the profile update and redirection.

targetAddressRedirection

Because there is no on prem mailbox, the profile for the user is now redirected to the value set in targetAddress (as is mail flow and free busy lookup) but what makes this all hang together is the msExchMailboxGuid

This is tied to the OST file, and it’s what allows the OST and the profile to recognise that the mailbox is essentially the same.

MOVING MAILBOXES WITH THIRD PARTY TOOLS

We’re at a disadvantage here from the start if we’re using DirSync or AAD Sync with third party tools, because as soon as we filter msExchMailboxGuid we essentially break the OST link with the new mailbox we create in Office 365, and as such we can never retain the OST file or the existing profile post migration.

At a minimum, you now have to factor Outlook cache into your migration logistics.

It’s also more complicated than that.

Third party tools typically require both source and target mailboxes to exist at the same time, in order to move data between them.

More often than not, the source mailbox is retained post migration.

Outlook profile redirection using targetAddress only works for mail enabled users or contacts, it doesn’t work with mailboxes.

If the source mailbox is still there Outlook just opens it, regardless if the targetAddress is set or not.

Remove the Source Mailbox

So option one here is to remove the mailbox post migration and mail enable the user object. This will set targetAddress and if we use the user@tenant.onmicrosoft.com address space this will partially work.

It will work for a new profile.

It won’t update the existing one, because the mailbox in Office 365 has a new GUID, and the old profile won’t connect to the new mailbox.

Redirect the Autodiscovery Process

Not everybody wants to remove the source mailboxes post migration. I get that.

So what other options do we have here.

We can leverage the complexity of the Autodiscovery process, so that membership of a domain security group applies a Group Policy that restricts access to the Server Connection Point (SCP) in AD, and forces autodiscovery to work using a DNS Alias.

Migrated users that are members of the group get the policy applied that forces Outlook to find Office 365 via DNS (or local XML), where non migrated users use an on prem autodiscovery endpoint via SCP.

I’ll write that up separately, as it’s quite lengthy to walk through.

Again, this only works with new profiles.

There are some products that can help with profile update, such as Migration Manager for Exchange (formerly QMMEx), and there are other products that can specifically manipulate the profile.

You may be rolling out new hardware or you may be in a position to create new profiles for all of your Outlook users,  but I can’t help feeling that MRS triumphs here over most third party migration products for the simple reason that it allows you to minimise the desktop disruption to the users, and happy users = successful migration.

MRS: 2 – Third Party Products: 0