This is a reminder for some or heads up for new tenants about an issue you might have run across that occurs when you try to change a user’s userPrincipalName in your local AD when using dirsync. If you change the UPN (left side of @) and keep the user in the same domain, dirsync should correctly update it in the cloud account. However, when you change from one domain to another and that domain is also configured as an SSO domain (i.e. federated), dirsync will start squawking about that object with this error, “exported-change-not-reimported”. You’ll see your UPN change trying to update the cloud object but it never does and the error is repeated each cycle until you resolve the problem.
While I’m not sure why dirsync has a problem changing from one SSO domain to another others posting on the O365 Community pages have experienced the same problem. After numerous searches I found someone posting on the forum with the same problem and their suggestion to change the account back to the MS Online default domain first. Apparently they spoke to someone at MS support that gave them a hint about this. Well, it works and that was good enough for me. Here’s what you have to do:
- Connect to the cloud using PowerShell (i.e. Connect-MsolService and remote PowerShell for Exchange Online)
- Run this command which temporarily sets the UPN to the MS domain: Set-MsolUserPrincipalName -UserPrincipalName username@domain1.com -NewUserPrincipalName username@corpdomain.onmicrosoft.com
- Run this command which temporarily sets the UPN to the MS domain: Set-MsolUserPrincipalName -UserPrincipalName username@corpdomain.onmicrosoft.com -NewUserPrincipalName username@domain2.com
- I would then run this command to check the MSOnline account: Get-MsolUser -UserPrincipalName username@domain2.com
- And then check the cloud mailbox for the same value (sometimes this takes a few minutes to update): Get-Mailbox username@domain2.com| FL name,MicrosoftOnlineServicesID
- Next, I would modify the local AD account and match the desired UPN.
- Finally I would run a manual dirsync and monitor its progress. I actually run a few manual sessions in a row and verify there are no more errors reported and the updates have been synchronized everywhere.
I hope this saves someone time troubleshooting this issue.
Yes it’s a weird problem, it’s a shame when you want to align your UPNs with E-mail Addresses or use the E-mail Address as the logon ID and when you have a multi-suffix customer where people move from one company to another and have their E-mail Address changed.
Luckily if you use FIM to replace DIrSync you can plug a PowerShell MA that captures the UPN change and does it properly before the export to the Azure MA tries doing the same. With that, no errors.
Hi great tutorial thanks. I have the same kind of problem that I can’t seem to solve: we use an onmicrosoft.com tenant simply to activate Office licences. I have changed the UPN suffix to match the public domain name, dirsync works fine the licences are activated but the connected services (ie save in SharePoint from Word for example, or OneDrive Enterprise) can’t connect (using either the xxx.onmicrosoft.com address or the new one). Any idea about this because I haven’t found any soluton anywhere). Thanks 😉