Synchronize AD to an existing Office 365 Tenant

Copper Contributor

So we have a company that we took over IT support for.  They have an AD environment and Office 365 but there is no synchronization.  We have been managing them seperately and they have recently hired a new IT manager who wants to do synchronization.


The user UPNs should match up with the login names in O365 so I should be good there.  If I just setup the synchronization and let it rolll I am thinking if we aliases and such those woul get overwritten in the synch if we did not prep if first on the AD side?


I also believe i can setup a SynchUsers group and have the tool only synch users that I assign to that group which in my thinking that might be a good way to go.


Also the supported method of management is to have an on-premise exchange server which they do not currently have but thinking we should be able to manage everything through Users & Computers modifying ProxyAddress attributes from there.


Just looking for the caveats so I do not totally screw something up in making this change.




7 Replies

Hey @Mwkirk,


There is a good chance that you might loose the aliases you have added manually in office 365 account when you force a sync from on-premises. The behavior is sort of unpredictable on that part, in some cases i have seen them stay, while lost in other cases. The ones stamped by office 365 services for example, which is for skype, should still remain intact even after the user is synced from on-premises, for other aliases you added manually you can't say. Best is to first take out a backup of all the aliases you have stamped against the office 365 mailboxes : 


Get-Mailbox -resultsize unlimited | select Displayname,Userprincipalname,PrimarySmtpAddress,RecipientTypeDetails,@{Name='ProxyAddresses'; Expression={$_.EmailAddresses -join ","}} | Export-Csv MailboxEmailAddresses.csv -nti


Next you can test with one account to see if it retains the addresses.

Group synchronization should work fine.

On-premises exchange is not a hard bound requirement if you have never had one. You would be able to manage the attributes from users and computers, you can consider expanding the schema though for exchange attributes.


Even when you have all your ducks in a row, some users still might fail merging. And you might see duplicate accounts instead of one consolidated account. Ensure that the UPN, Primary SMTP address, Mail are not being used else where. If you are good on that part and still a user is failing to match, attempt a forced match after deleting the duplicate incorrect account completely:

Via command prompt on DC:

ldifde -f export.txt -r "(Userprincipalname=*)" -l "objectGuid, userPrincipalName"

This would give you the ObjectGuid for all the users.

Next you can stamp it against the user:

Set-MsolUser -UserPrincipalName -ImmutableId ObjectIDobtainedAbove  

Run a full sync.





@harveer singh 


Ok that is definitely helpful.  I started looking at their ProxyAdresses in their O365.  They apparently had on premise Exchange before because there is a parameter defined for MSEXCHMAILBOXGUID.  Looks like at some point they had Lotus Notes as well becuase I see ProxyAddress values that start with with CCMAIL.


What I am thinking of doing is just blanking out all the ProxyAddress values on the local AD then take the export from O365 and import it in so that the ProxyAddress values match up in the local AD and O365.


Also, regarding the msexchmailboxguid value which I am thinking I either need to clear that value in the local AD or filter it from the synch.  I have used tools like Skykick in the past for migrations and if you let that value synch then normally it would not let you create a mailbox.  I have no idea what it would do if the user already has a mailbox in O365.






Yup, you are right if you sync the mailbox GUID from on-premises, office 365 will treat you as mail user and won't provision your mailbox. You can either clear all exchange related attributes or simply exclude mailbox guid/Archive guid from synchronization.

Even if you already have a mailbox in office 365, you would still be able to soft match/hard match the users preserving the mailbox, just don't sync the mailbox guid though. And as always, Test with a few users !

@Mwkirkfrom what you have said they have had Exchange onprem in the past, first thing I would do is Active Directory schema to make sure they are current.


You then want to export the current users from M365 and add the user details to the Active Directory users (name, display name, department, proxy address etc) once you run a sync the account in M365 will be matched with the onprem account and so if a user does not have for example a department defined in onprem but does in the cloud the cloud user will get updated with no department as onprem will over write.


When you install azure AD connect match based on UPN and the accounts should match, don't forget the users cloud password will be changed to the users onprem password and I would sync a single OU at a time and drip feed the users into this OU so you only test with 1 user at a time.


One thing to point out is that while you can edit the users onprem via AD users and computers you are now going to be in an unsupported model with syncing users but having no Hybrid to manage them. if the company have E1, E3 Licenses then just install an Exchange 2016 hybrid as the license is free

So I am going through the process of installing AADConnect this morning.  So, I was going to do the group filtering.  The screen specifically says this should be used for pilots only.  I am technically piloting right now but is it just for performance reasons it should not be used in production?  I guess the best options are OU filtering or attribute filtering.  Has anyone had issues using the group filtering or should I just use it initally her while I am figuring things out and then remove the group filtering in favor off a different method later on?




Hey @Mwkirk , 

Group based filtering gets a bit unmanageable when you have large number of users, thus it is often suited if you are synchronizing a small subset of users, hence other options like OU based filtering are more popular. Here is reference article talking about the same, check out the section for group based filtering :