Office 365 Migrations – Helpful Tips (3)

In part 3 in my series on helpful tips for Office 365 migrations, I cover what can be done for a successful mailbox migration but the end user is experiencing issues with their Calendar.
The Issues Continue
In my previous parts of this series I covered some issues that occurred with a bad Office 365 migration due to some Active Directory replication issues. The same users that were hard to migrate are able to send and reply to emails (on-prem and Office 365 recipients). However, when a calendar appointment is moved the end user receives an NDR message saying it could not be delivered to the recipient. Normally I would assume a names cache or OAB issues. The end user’s Outlook was Outlook 2010 and we cleared the Names cache which can be done by clicking on File, Options, Mail and under ‘Send Messages’ click on Empty Auto-Complete List.

Once cleared, we closed and re-opened Outlook. Once again a meeting was moved and again an NDR was received. We then closed Outlook. Created a new profile and tested once more. Same results. Next, I closed Outlook, deleted the Offline Address Book directories under the Outlook file folder.
(For reference)
None of these steps worked.
What next?
Time to check out the appointment itself to see if there are any issues with the way the appointment was created or information contained in the appointment. Specifically we want to look at the attendees and organizer of the meeting to see if something is corrupt there. When we opened the offending appointment, click on the ‘Scheduling Assistant’

Right click on the organizer (the user who’s mailbox you have open) and select ‘Outlook Properties’.

Notice the Outlook Properties box contains x500 Addresses and not the normal information:

A normal Organizer would look something like this:

So our entire problem is a missing X500 reference value on the users AD account. This value is store in the ProxyAddresses of the users account. While investigating this issue I also noticed that the Exchange GUID value on the RemoteMailbox object in the on-prem AD was incorrect. If I ran this Powershell command

get-remotemailbox 'alias' | ft ExchangeGuid

I would get:

Which isn’t normal. Running a similar command in Office 365 to check the ‘cloud object’ for the mailbox revealed the ExchangeGUID:

The Solution for missing Exchange GUID and x.500 Address
The fix for this issue is simple, all we need is to assign the same GUID using the RemoteMailbox PowerShell command so that on-prem and cloud mailbox objects match.

get-remotemailbox 'alias' | set-remotemailbox -ExchangeGuid (GUID from cloud object)

Now that this is fixed, lets fix the x500 value. To do this, open up ADSIEdit (WARNING THIS IS DANGEROUS) and add the value to the user account:

After this change is made, do the following:

• Start on-prem Active Directory replication.
• The run a DirSync from your DirSync server to Office 365.
• Wait 150-30 or so.
  The verify this is showing up in the Portal.Micorsoftonline.com interface (must be done in the Exchange portion):
  
  Now that the x500 value is in the cloud, we need to visit the client and refresh the Offline Address Book, close Outlook and reopen Outlook. Now the meeting organizer will be correct.
  This is the end of my series on Office 365 migration helpful tips/fixes.