We have a single domain here, and at one point someone ran a directory sync that has disastrous results. Somehow they ended up having to recreate every user profile. No one who was involved in that is here anymore, but it concerns me for sure. I cannot find much documentation about where they went wrong.So...I am looking to run the AAD Sync pretty soon, but I want to be sure I can back out of anything bad. I ran IDFIX and cleaned up all my user UPN's, and I have cleaned up as much of the AD as I can. Once I hit START, there is no backing out right? I believe I could put it in staging mode, and not commit any of the sync changes correct?I have read quite a bit about the process, but what I am really trying to find are the things that COULD GO WRONG. Or the consequences of something going badly. This organization is relatively small and there is not test site. I have been wondering if I could install a Virtual Server and test the process there?

If anything goes wrong, you can simply delete the synced users and start fresh. Or if you want to test it, spin a trial tenant and configure the sync to it, then if everything works as expected rerun the AAD Connect setup wizard and configure it to sync with the "real" tenant.

Nothing is synced back, DirSync is one-way process, from on-premises to Azure AD. Only when you have some of the additional features enabled there is (limited) writeback to the local domain. Not sure what you mean by "alternate" UPN, did you perhaps add a new UPN suffix?

Is there any consequence to running against a trial tenant and then later coming back to run against the production tenant? I think the trial tenant idea sounds attractive, but it doesn't actually sync anything back to the local domain if I pick STAGING correct?I added the username@domain.com as an alternate UPN, but it doesn't appear that it will let users log in to the domain with that. If I make the username@domain.com the PRIMARY login, do I then have to create new profiles for each user?

YES, I meant UPN Suffix. They were all xxx.local. I added user@domain.com Can I filter it down to just do a specific user possibly? I could do one of my test accounts and just see how that goes? The issue we have is that our On-Prem users don't have listed managers, etc. All the detail is in the users cloud account. So the Sync isn't going to populate the on-prem account by default correct?

What we would like to do is allow the users to change their own passwords for starters. That will require write-back correct?

Looking to run AAD Sync soon | Microsoft Community Hub

11 Replies

VasilMichev
MVP
Jul 31, 2018
If anything goes wrong, you can simply delete the synced users and start fresh. Or if you want to test it, spin a trial tenant and configure the sync to it, then if everything works as expected rerun the AAD Connect setup wizard and configure it to sync with the "real" tenant.
- Todd Purifoy
  Copper Contributor
  Aug 07, 2018
  Is there any consequence to running against a trial tenant and then later coming back to run against the production tenant?
  
  I think the trial tenant idea sounds attractive, but it doesn't actually sync anything back to the local domain if I pick STAGING correct?
  
  I added the username@domain.com as an alternate UPN, but it doesn't appear that it will let users log in to the domain with that.
  
  If I make the username@domain.com the PRIMARY login, do I then have to create new profiles for each user?
  - VasilMichev
    MVP
    Aug 08, 2018
    Nothing is synced back, DirSync is one-way process, from on-premises to Azure AD. Only when you have some of the additional features enabled there is (limited) writeback to the local domain.
    
    Not sure what you mean by "alternate" UPN, did you perhaps add a new UPN suffix?

Forum Discussion

Looking to run AAD Sync soon

11 Replies

Resources