SOLVED

Duplicate Accounts in O365 from Azure AD Sync

%3CLINGO-SUB%20id%3D%22lingo-sub-218806%22%20slang%3D%22en-US%22%3EDuplicate%20Accounts%20in%20O365%20from%20Azure%20AD%20Sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-218806%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20a%20unique%20situation%20where%20we%20synchronized%20our%20existing%20AD%20domain%20of%20'company.eu'%20to%20our%20O365%20tenant%20'company.com'.%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20O365%2C%20'company.com'%20includes%20everyone%20in%20the%20US%20and%20Europe...all%20Company%20employees%2C%20while%20the%20AD%20domain%20only%20has%20EU%20employees.%3C%2FP%3E%3CP%3EWe%20bought%20the%20'company.eu'%20domain%2C%20and%20I%20added%20it%20to%20O365%20as%20a%20secondary%20domain.%20Some%20users%20got%20the%20secondary%20email%20%22user%40company.eu%22%2C%20and%20some%20have%20not.%3CBR%20%2F%3ESince%20synchronizing%20AD%2C%20some%20users%20have%202%20accounts%20in%20O365%20(user%40company.com%2C%20in%20cloud%20AND%20user%40company.eu%2C%20synced%20from%20AD).%20When%20I%20try%20to%20modify%20any%20aliases%20in%20O365%2C%20I'm%20shown%20its%20controlled%20by%20AD%20sync.%3CBR%20%2F%3EIs%20there%20a%20way%20to%20merge%20the%20duplicate%20accounts%20in%20O365%3F%20We%20have%20to%20keep%20the%20primary%20email%20as%20'company.com'%2C%20but%20also%20have%20their%20AD%20accounts%20synced%20with%20O365%20for%20SSO.%3CBR%20%2F%3EIdeas%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-218806%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAdmin%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOn-Premises%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-218973%22%20slang%3D%22en-US%22%3ERe%3A%20Duplicate%20Accounts%20in%20O365%20from%20Azure%20AD%20Sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-218973%22%20slang%3D%22en-US%22%3E%3CP%3EYes%2C%20that's%20the%20way%20to%20do%20it.%20Anyways%2C%20try%20with%20one%20or%20two%20users%20first%20to%20verify%20the%20process.%20Good%20luck!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-218849%22%20slang%3D%22en-US%22%3ERe%3A%20Duplicate%20Accounts%20in%20O365%20from%20Azure%20AD%20Sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-218849%22%20slang%3D%22en-US%22%3E%3CP%3EYou%20saved%20me%20some%20work%2C%20Nestori.%26nbsp%3B%20Thanks%20again.%3CBR%20%2F%3E%3CBR%20%2F%3EIt%20is%20the%20case%20where%20some%20EU%20users%20linked%20to%20COM%20cloud%20accounts.%20So%2C%20this%20would%20need%20to%20be%20something%20done%20while%20they're%20not%20using%20their%20accounts%20(weekend%2Fafter%20hours).%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3ENobody%20knows%20they%20have%20the%20EU%20email%20address%2C%20so%20no%20mails%20have%20been%20sent%20to%20those%20mailboxes.%3CBR%20%2F%3E%3CBR%20%2F%3ESo%20my%20understanding%20is%20now%20to%3A%3CBR%20%2F%3E1)%20Stop%20syncing%20my%20AD%20accounts%20(with%20.eu%20TLD)%3CBR%20%2F%3E2)%20Force%20sync%20(without%20the%20.eu%20accounts)%20thus%20removing%20them%20from%20O365.%3CBR%20%2F%3E%26nbsp%3B%26nbsp%3B%202a)%20Some%20mailboxes%20would%20be%20soft-deleted.%20Should%20be%20noted%20and%20restored%3CBR%20%2F%3E3)%20Modify%20attributes%20(via%20ADSIEDIT)%20to%20include%20both%20SMTP%2Fsmtp%20addresses%20on-premises.%3CBR%20%2F%3E4)%20Resync%20with%20cloud%3CBR%20%2F%3E%3CBR%20%2F%3EDo%20I%20have%20this%20correct%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-218838%22%20slang%3D%22en-US%22%3ERe%3A%20Duplicate%20Accounts%20in%20O365%20from%20Azure%20AD%20Sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-218838%22%20slang%3D%22en-US%22%3E%3CP%3EIf%20you%20%22unsync%22%20a%20user%2C%20their%20mailboxes%20will%20be%20soft-deleted%20for%2030%20days.%20If%20you%20resync%20the%20user%2C%20the%20mailbox%20will%20be%20returned.%20So%2C%20if%20some%20company.eu%20users%20are%20already%20linked%20to%20company.com%20cloud%20users%2C%20their%20mailboxes%20will%20be%20soft-deleted.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20you%20only%20need%20to%20delete%20the%20duplicate%20accounts.%26nbsp%3BDoes%20those%20duplicate%20company.eu%20accounts%20have%20already%20mail%20in%20their%20mailboxes%3F%20If%20not%2C%20you%20can%20safely%20delete%20them.%20However%2C%20if%20they%20have%20mails%2C%20they%20need%20to%20be%20migrated.%26nbsp%3BYou%20can%20utilize%20%22inactive%20mailboxes%22%20to%20that%2C%26nbsp%3Bsee%20my%20blog%20post%26nbsp%3B%3CA%20href%3D%22http%3A%2F%2Fo365blog.com%2Fpost%2Finactive-mailboxes%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20you%20add%20aliases%20to%20all%20your%20on-premises%20users%20now%2C%20there%20will%20be%20sync%20errors%20due%20to%20existing%20duplicates.%20So%20you%20should%20not%20try%20to%20set%20aliases%20to%20those%20duplicate%20company.eu%20users%20before%20removing%20them%20from%20the%20cloud.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-218834%22%20slang%3D%22en-US%22%3ERe%3A%20Duplicate%20Accounts%20in%20O365%20from%20Azure%20AD%20Sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-218834%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%2C%20Nestori.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20did%20find%20how%20to%20manipulate%20the%20attributes%20via%20ADUC.%20I'm%20leery%20of%20deleting%20the%20accounts%20in%20O365.%26nbsp%3B%3CBR%20%2F%3EAll%20of%20my%20on-premise%20accounts%20are%26nbsp%3B%40company.eu.%20Some%20of%20the%20O365%20users%20already%20have%20this%20as%20an%20alias%2Falternate%20SMTP.%3CBR%20%2F%3EIf%20I%20%22unsync%22%2Fremove%20all%20of%20the%20.EU%20users%2C%20what%20happens%20to%20their%20existing%20.com%20accounts%3F%20Not%20all%20.EU%20users%20are%20duplicates.%3CBR%20%2F%3EIn%20the%20end%2C%20it%20should%20be%20a%20single%20synchronized%20user%20with%20both%20.com%20and%20.eu%20seen%20in%20O365.%3CBR%20%2F%3EFor%20now%2C%20I'm%20setting%20SMTP%20and%20smtp%20for%20all%20users%20via%20ADUC.%3CBR%20%2F%3EDo%20you%20think%20this%20will%20correct%20the%20primary%20accounts%20to%20where%20I%20could%20later%20remove%20the%20duplicates%20(assuming%20they%20would%20be%20EU%20only)%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-218827%22%20slang%3D%22en-US%22%3ERe%3A%20Duplicate%20Accounts%20in%20O365%20from%20Azure%20AD%20Sync%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-218827%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Shaun%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFirst%20you%20need%20move%20those%20duplicate%20company.eu%20users%20to%20an%20OU%20that%20is%20not%20synced%20(in%20on-premises).%20Then%20run%20the%20sync%20manually%2C%20which%20deletes%20those%20users%20from%20the%20cloud.%20Then%20you%20need%20to%20remove%20the%20users%20from%20%22recycle%20bin%22%20using%20PowerShell%3A%3C%2FP%3E%3CPRE%3EGet-MsolUser%20-ReturnDeletedUsers%20%7C%20Remove-MsolUser%20-RemoveFromRecycleBin%3C%2FPRE%3E%3CP%3EFor%20the%20second%20step%2C%20you%20have%20two%20options.%20You%20can%20either%20change%20on-premises%20UPNs%20from%20company.eu%20to%20company.com%2C%20or%20you%20can%20hard-link%20the%20users%20manually.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20the%20latter%20option%2C%26nbsp%3B%20you%20need%20to%20add%20GUID%20of%20on-premises%20company.eu%20user%20as%20the%20ImmutableId%20of%20company.com%20user%20in%20the%20cloud.%26nbsp%3B%20Here%20is%20the%20one-liner%20that%20does%20the%20trick%20for%20one%20user.%3C%2FP%3E%3CPRE%3ESet-MsolUser%20-UserPrincipalName%20user1%40company.com%20-ImmutableId%20(%5BSystem.Convert%5D%3A%3AToBase64String((Get-ADUser%20-Filter%20%22UserPrincipalName%20-eq%20'user1%40company.eu'%22).ObjectGUID.ToByteArray()))%3C%2FPRE%3E%3CP%3EAfter%20fixing%20the%20on-premise%20UPN%20or%20manually%20hard-linking%20the%20users%2C%20move%20them%20back%20OU%20that%20is%20synced%20and%20run%20the%20sync%20manually%20again.%20After%20the%20sync%2C%20on-premises%20company.eu%20users%20should%20be%20linked%20to%20existing%20company.com%20users.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3BTo%20add%20aliases%20to%20synced%20company.eu%20users%2C%20you%20need%20to%20edit%20their%20proxyAddresses%20attribute%20in%20on-premises%20AD.%20The%20following%20example%20sets%20the%20company.eu%20as%20primary%20email%20address%20and%20company.eu%20as%20alias.%3C%2FP%3E%3CPRE%3ESMTP%3Auser1%40company.com%3CBR%20%2F%3Esmtp%3Auser1%40company.eu%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Occasional Contributor

We have a unique situation where we synchronized our existing AD domain of 'company.eu' to our O365 tenant 'company.com'. 

In O365, 'company.com' includes everyone in the US and Europe...all Company employees, while the AD domain only has EU employees.

We bought the 'company.eu' domain, and I added it to O365 as a secondary domain. Some users got the secondary email "user@company.eu", and some have not.
Since synchronizing AD, some users have 2 accounts in O365 (user@company.com, in cloud AND user@company.eu, synced from AD). When I try to modify any aliases in O365, I'm shown its controlled by AD sync.
Is there a way to merge the duplicate accounts in O365? We have to keep the primary email as 'company.com', but also have their AD accounts synced with O365 for SSO.
Ideas?

5 Replies
Highlighted
Best Response confirmed by Shaun Delorez (Occasional Contributor)
Solution

Hi Shaun,

 

First you need move those duplicate company.eu users to an OU that is not synced (in on-premises). Then run the sync manually, which deletes those users from the cloud. Then you need to remove the users from "recycle bin" using PowerShell:

Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin

For the second step, you have two options. You can either change on-premises UPNs from company.eu to company.com, or you can hard-link the users manually.

 

For the latter option,  you need to add GUID of on-premises company.eu user as the ImmutableId of company.com user in the cloud.  Here is the one-liner that does the trick for one user.

Set-MsolUser -UserPrincipalName user1@company.com -ImmutableId ([System.Convert]::ToBase64String((Get-ADUser -Filter "UserPrincipalName -eq 'user1@company.eu'").ObjectGUID.ToByteArray()))

After fixing the on-premise UPN or manually hard-linking the users, move them back OU that is synced and run the sync manually again. After the sync, on-premises company.eu users should be linked to existing company.com users.

 

 To add aliases to synced company.eu users, you need to edit their proxyAddresses attribute in on-premises AD. The following example sets the company.eu as primary email address and company.eu as alias.

SMTP:user1@company.com
smtp:user1@company.eu

 

Highlighted

Thanks, Nestori.

 

I did find how to manipulate the attributes via ADUC. I'm leery of deleting the accounts in O365. 
All of my on-premise accounts are @company.eu. Some of the O365 users already have this as an alias/alternate SMTP.
If I "unsync"/remove all of the .EU users, what happens to their existing .com accounts? Not all .EU users are duplicates.
In the end, it should be a single synchronized user with both .com and .eu seen in O365.
For now, I'm setting SMTP and smtp for all users via ADUC.
Do you think this will correct the primary accounts to where I could later remove the duplicates (assuming they would be EU only)?

 

Highlighted

If you "unsync" a user, their mailboxes will be soft-deleted for 30 days. If you resync the user, the mailbox will be returned. So, if some company.eu users are already linked to company.com cloud users, their mailboxes will be soft-deleted.

 

However, you only need to delete the duplicate accounts. Does those duplicate company.eu accounts have already mail in their mailboxes? If not, you can safely delete them. However, if they have mails, they need to be migrated. You can utilize "inactive mailboxes" to that, see my blog post here

 

If you add aliases to all your on-premises users now, there will be sync errors due to existing duplicates. So you should not try to set aliases to those duplicate company.eu users before removing them from the cloud.

Highlighted

You saved me some work, Nestori.  Thanks again.

It is the case where some EU users linked to COM cloud accounts. So, this would need to be something done while they're not using their accounts (weekend/after hours).

Nobody knows they have the EU email address, so no mails have been sent to those mailboxes.

So my understanding is now to:
1) Stop syncing my AD accounts (with .eu TLD)
2) Force sync (without the .eu accounts) thus removing them from O365.
   2a) Some mailboxes would be soft-deleted. Should be noted and restored
3) Modify attributes (via ADSIEDIT) to include both SMTP/smtp addresses on-premises.
4) Resync with cloud

Do I have this correct?

Highlighted

Yes, that's the way to do it. Anyways, try with one or two users first to verify the process. Good luck!