11-02-2018 02:26 AM
11-02-2018 02:26 AM
I have inherited a hybrid O365/On-Prem solution with my company.
What we have is a local only Active Directory and O365 subscriptions, this means that users currently have one password to logon to the network here and another for their emails etc...
I want to setup the AD connector so that these details are sync'd.
My initial question is what will happen if I setup the AD connector today? I would assume that all my local AD accounts, groups etc... will be copied to my O365 however there will be duplicates i.e. JSmith has an AD account and an O365 subscription usernames will be the same.
Any help much appreciated.
11-02-2018 02:47 AM
I guess what you mean its separated right now and not hybrid (connected) yet..
What you wanna do is setup the ADConnect and probably filter byOU (most common) which objects you wanna sync..You can then only sync the users/groups you want, also test things out..
You have to add the Office 365 UPN to the users you are syncing! Many AD's today have a UPN of email@example.com or such..If you have company.com as a domain in office 365, (your 365 users have a mail of firstname.lastname@example.org for example) company.com must be added as a UPN in AD and set on the users which to be synced ( Same UPN)
Regarding the accounts that exists in your Office 365 tenant today, they can be merged with the accounts in AD.
If UPN's and proxyaddress is matching the 2 users will do a soft match and not end up duplicated
Read more here:
11-02-2018 07:08 AM - edited 11-02-2018 07:09 AM
Hi, Ad connect is made of 3 component, Monitoring,ADSF and Sync services which will ONLY help you do INTEGRATE your on premise AD and Azure AD to SYNC and monitor ONLY the users that you select and pls not to assume that all your local AD accounts, groups etc... will be copied to my O365 ... 2 good hints, is to just make sure those users are routable UPN names and that your SYNC is a one way Traffic...... Another good suggestion I have for you is that, since ADSF is a component of AD Connect I will enable it during the setup of AD connect, because if you decide in the near future to have a ful blown SSO then all you will only need to DO, is to setup ADSF Farm and Trust using Powershell between your On premise AD and Azure AD. Good Luck
11-02-2018 11:17 AM
Whatever you do, do not take installing and configuring Azure AD Connect lightly! I know (from experience, unfortunately) that one wrong checkbox can ruin your weekend, and possibly much longer than that. You'll want to involve any other admins that run Microsoft services at your company, too, as once that sync is made there is no going back and it can greatly affect any and all Microsoft services in your environment.
Make sure you understand all your options around hybrid O365 identities before you decide how to set up your environment. Additionally, make sure you review how Azure AD Connect will "match" your existing user accounts and check for duplicates - this is another one of those things that you can't undo once it is set. And make sure that your user accounts actually meet all the requirements before going too far down that road.
Best of luck!
11-02-2018 11:28 AM
11-02-2018 11:31 AM
11-02-2018 12:30 PM
11-02-2018 12:41 PM
11-02-2018 12:44 PM
11-05-2018 07:19 AM
So in order to test I am going to filter out all OU's except a test OU.
Am I right in saying that so long as the UPN and ProxyAddress match that of the O365 object then the accounts will be merged?
People have mentioned one-way sync, how and where can I check that my connection is in fact one-way only?
11-05-2018 08:13 AM - edited 11-05-2018 08:20 AM
Good call - a small test OU or pilot group is a great idea for this.
Rather than using the express install wizard, you probably will want to go through the custom installation instead. Have a read through all of the options in the custom install wizard before deciding, of course, but by going through the custom install you'll have control over which OU's to sync (or just use a pilot group), and whether any write-back (two way sync) features are enabled.
Something worth noting from my previous experience that may not be apparent from reading all this documentation is that the account in your on-prem Active Directory will become the master account, which means that the on-prem account's details will overwrite any information that may have been set in the cloud identity - so it's not really what I consider a true "merge". In your testing you might want to make sure you check all of the proxy addresses before and after an account is synced to see if there could be any potential interruption to mail flow for users. For instance, if your on-prem account has only the primary SMTP address in it's proxy addresses, but your cloud account has multiple proxy addresses, then when those accounts are synced only the primary SMTP address will remain and all those other proxy addresses will be removed. This also means that you may have to adjust provisioning processes if you had some of that user information being updated in the cloud rather than on-prem, many of the settings will only be able to be managed from your on-prem directory at that point.
Another thing to remember is that when an account in the cloud is synced to an on-prem object, it's always synced to that object. The guid of the on-prem object is encoded and written to the cloud object forming a permanent link between the two objects. It is really hard to unlink those accounts at that point, so just be cautious and test as many scenarios as you can before syncing your whole directory. You might want to also check out the troubleshooting guide to see how you can view exactly what attributes are being written and where in your testing.
11-05-2018 08:16 AM
Let me know if you still have any queries.