During a simple migration (cutoff) to Office 365 Exchange Online, I’ve encountered a few errors that prevented the migration batch to complete successfully, and wanted to share in case anyone is struggling with them.
- Active Directory operation failed on AMSPR01A001DC01.EURPR01A001.prod.outlook.com. The object ‘CN=user,OU=tenant.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR01A001,DC=prod,DC=outlook,DC=com’ already exists.
This error states that the migration batch failed to create a new object because that specific name is already taken. sadly enough the value for the CN=xxxx is taken from the alias property of the user/contact/group being migrated from the on-premise server.. and alias is not unique within (most) Exchange deployments.
To Solve this, work with the “alias” property value on your local AD to locate the conflicting objects, work with the results of the migration job and cross-reference until you will eliminate all duplicates of the alias values.
- Failed to overwrite the existing Migration Job Item found for “email@example.com” [Mailbox]; the Job Item was created with different Recipient Type [Contact]. You may delete the newly created Mailbox and recreate the actual Contact for firstname.lastname@example.org.
This error could be a result of your actions to fix duplicates issues, if for some reason the migration batch started with email@example.com being a contact and that object has changed it will fail to “update/sync” and will continue to expect the original object type which was different in this example a contact.
To solve this Connect to Exchange Online Using Remote PowerShell and work with two commands – Get-MigrationUser and Remove-MigrationUser to remove the incorrect object from the migration batch and then resume it. This will make sure the new (correct) object will be synced successfully. Here’s an example of how to use these commands:
Get-MigrationUser -Identity User@Domain.com | FL
Notice the output here and make sure this is indeed the incorrect object that needs to be removed, and then pipe the output to remove that user from the Migration Batch:
Get-MigrationUser -Identity User@Domain.com | Remove-MigrationUser
Once removed, you can resume the migration again and it should now sync correctly your mailboxes.
Hope this helps !
Quick note from the field, if you are moving to Exchange Online / Office 365 you should double check your current office group-policy settings and registry for Outlook.
You should make sure that you did not enable the Closest GC setting, or configured a specific global catalog server with the DS Server registry entries under HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider
Both registry values, errors and methods for resolution are located at:
http://support.microsoft.com/kb/2507626 – Error in Outlook: “The action cannot be completed. The Bookmark is not valid”
http://support.microsoft.com/kb/319206 – How to configure Outlook to a specific global catalog server or to the closest global catalog server
And if we are on the subject, it’s also a good practice to make sure the following when moving to Office 365:
- You do not have Autodiscover related registry settings also – http://support.microsoft.com/kb/2212902 – Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key
- Make sure that the “Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server” option under account settings of the Outlook Profile is indeed selected. Office 365 is restricting clients to encrypt MAPI traffic – see the following KB for additional information (originally written for Exchange 2010 RTM) – http://support.microsoft.com/kb/2006508
I’ve encountered a funny situation the other day with a new Office 365 hybrid deployment with an initial install of ADFS 2.0 for Federation with Office 365 and SSO.
The first attempt of running the “AD FS 2.0 Federation Server Configuration Wizard” ended with a failure:
You do not have sufficient privileges to create a container in Active Directory at location CN=46bd8c28-c299-475b-9853-8176010f4273,CN=ADFS,CN=Microsoft,CN=Program Data,DC=Domain,DC=com for use with sharing certificates. Verify that you are logged on as a Domain Admin or have sufficient privileges to create this container, and try again.
Well, I’ve double checked my logged on user credentials, the built-in Administrator – we have all the required permissions. I’ve opened ADSIedit and looked for the Program Data container under the domain partition, just to make sure no permissions issues are indeed preventing this wizard to complete.
Guess what – no Program Data container !!?
I had the feeling that the container was moved rather then deleted or removed completely.. so I decided made a little search, a custom search for containers with a description starting with the string “default”
Found it (!) and moved it to the root of the Domain tree, then I’ve started the the ADFS configuration wizard again.
Case closed 🙂 happy ADFS and a working federation with Office 365
Happy new year everyone !
I’ve been very busy lately lots of work, especially with Office 365 Hybrid deployments, Office 365 is really a growing demand and presents new technical perspectives which comes down to know knowledge 🙂
Well yeah I am a geek that likes to keep learning new stuff…
Long story short, you have deployed your Hybrid Office 365 topology to your current Exchange 2003, 2007 or 2010 organization and now you move a mailbox enabled user to the cloud (25 GB mailboxes rocks) , everyone is happy, then the CEO sends a “Happy New Year” email to “All Company” DL and for some reason the user which was moved to the cloud did not receive that memo….
So what happened ?
Most “All Company” distribution lists are Dynamic Distribution Groups AKA Query Based Distribution Group , and as such they have a LDAP filter which populates the members auto-magically – most members are Users with Exchange Mailbox, but when you move a user mailbox to Office 365 the original user was transformed to Mail-Enabled user – With an external address !
Yeah, you will need to modify those groups now to have “Users with External e-mail addresses” also checked 🙂
Problem solved – Happy new year !