Score:0

Overwriting existing users in MS 365

in flag

I inherited the management of a MS365 (former Office 365) and local Active Directory system. The old server was toast and I created a whole new Active Directory domain on new hardware.

On the new AD domain many users have the same email adresses as on the old domain and it seems that this causes problems.

My goal

Is to overwrite all users on MS 365 with my new users on my AD.

The Problem

When I installed AD Sync it did create all new users but now I'm getting daily emails of failed sync of 100+ users.

Azure Active Directory is reporting them as "duplicate attirbutes" Duplicate Attributes by AAD

Detailed view of duplicate "ProxyAdresses"

AAD is reporting duplicate ProxyAdresses for almost all users who were present on the old domain. Strangely, none of the users do have a value in the proxyAdresses field in the local AD

no proxyAdresses defined

When I dig deeper into the individual errors it states that a user like the following has the same SMTP address on premises and on Azure

Detailed user comparison with conflicting attributes

I would like to merge these two into one or overwrite the new one (from AD) to AAD

MS official guide suggests using idfix which after querying is not showing anything wrong with the AD Domain.

Empty after Query

Questions

  1. Is there a way I can "overwrite" the users on MS365 with my new users with the same email adresses?
  2. If not, can I "clean" my MS365 domain so I can start a fresh sync with no users (I understand that this means all existing users will lose their data)
joeqwerty avatar
cv flag
**MS official guide suggests using idfix which I did use but it's always trying to sync the users from MS365 back to the local AD.** - No, it isn't. User account synchronization is one-way, from on premises AD to Office 365. **The tool also tries to automatically fix things which did not work.** - The tool only attempts to fix things if you tell it to. You can use the tool to create a report and export the results and review and fix them manually. Open a support case from your Office 365 tenant. It's free and they'll help you solve the problem.
in flag
Thanks for your answer. I did run idfix again (this problem is ongoing for quite some time. idfix didn't show anything after query. I added more details and images of the errors. It doesn't make sense to me since the field that AAD is complaining about being duplicate is not even used in local AD
Score:0
cv flag

IDFix doesn't validate the users across directories. It only queries the local AD to find objects that may not sync due to errors, like invalid characters in the local or domain part of the name, etc.

Here's what I'd suggest:

  1. Reconfigure Azure AD Connect to sync an empty OU. This will put all of your AD accounts out of scope and will cause them to be deleted in Office 365. Note that this will only affect the user accounts that have been synced from on premises AD. It will not affect your existing Office 365 "cloud only" users.

  2. Add your Office 365 verified domain as a UPN suffix in AD.

  3. For one AD user account set the new UPN suffix on their user account. Make sure that the User Logon Name matches the Office 365 username for an existing Office 365 "cloud only" user ([email protected]). If it doesn't, change the AD User Logon Name to match the Office 365 username. This won't affect the AD users ability to logon to the domain, unless they're logging on with their User Logon Name.

  4. Permanently delete the Office 365 account for this user. - https://practical365.com/permanently-remove-deleted-microsoft-365-users-from-azure-ad/

  5. Move this user in AD to your empty OU and initiate an Azure AD Connect delta sync cycle. The user should now be synced to the existing Office 365 user account. If it is, then repeat the above for all of your AD users. If it isn't then open a support case in your Office 365 tenant.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.