Migration Issues to Office 365

I’ve written a few blog posts on problems I’ve seen while moving users to the cloud. Recently a client of mine experienced the normal one or two issues connecting mailboxes to the cloud. However, he went through our check list of updates, new profile and checking attributes (remote mailbox – email address, email addresses in Office 365, UPN (office 365), remote routing address, mail, and primarysmtpaddress). No luck. He called me and we dug into the issue. Here is what we tried:

• Re-verified all the attributes
• Tried logging in with his computer (known working with Office 365)
• Tried profile auto-creation using Outlook (AutoDiscover had no issues locating the mailbox)

I then heard that these same users had been either married or had an incorrect name when they were initially created. Most if not all attributes had been cleaned up. The only attributes that were not were Proxy Addresses – an only SMTP address existed for one and both had x.500 addresses that reflected a name different from the user.


Removing the old SMTP address did not help. However, removing the wrong X.500 and making sure that a different X.500 address was the solution. These addresses were modified in Office 365. Once a full Dirsync occurred, waiting a few minutes (up to 15?), the users were able to connect to their mailboxes once more.
The thing to remember here is that cleanup is sometimes necessary prior to migration not just of the mailbox content, but also the user accounts themselves. I cannot count the times that old, non-routable domains prevent a user migration to the cloud.
Issue Two
The second issue was a security group that had replicated to the cloud (DirSync) and was causing confusion with the end users as it had a similar display name as an existing Distribution Group. Why would this replicate to the cloud? or more importantly, how can we hide it from the GAL so as to not confuse the users? It was not defined as a DL in Exchange (2007 on premises). I had previously hidden objects using these attributes:

• AddressListMembership
  Normally set to something like “\All Users, \Default Global Address List”
  Change the value to $null
• HiddenFromAddressListsEnabled – Set this to $true

However these were not valid on the security group as it was not a mail enabled group. After a bit of research, I stumbled up THIS LINK and found the attribute I was looking for “msExchHideFromAddressLists”. When set to true, it will hide the security group from the GAL. Once set, the ‘live view’ of the address book will no longer display the group. For any Outlook client, a download of the changes to he OAB (about once per day) will need to occur before an end-user sees the change.
How these two new troubleshooting tips help you with your migration to Office 365.