Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Looking to run AAD Sync soon

Brass Contributor

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?

11 Replies

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.

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?

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?

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?

Yes, that requires password write-back which in turn requires Azure AD premium. However, Azure AD premium is not included in Office 365 license so you need to buy it separately.

Ok...thanks for the info.

 

One last thing, I did create an OU and sync it, and I threw a test account in there.  It appears to have gone smoothly, but I can't really tell how to judge success.  Is there a log or some way to tell that a user is now in sync?

I used to see status as "in cloud" I believe, but now I just see the license information in Status field.  None of the user info or detail actually seemed to change although the local AD account would have much less info than the cloud account.  I would assume it would overwrite the cloud info?

 

Not sure how to test success.  The local account has a different password than the cloud account, and if I understand the documentation correctly, the password hash should cause the cloud password to reset to the local one?

You may need to logout and in again, as admin center is not aware that you turned the sync on. After logging in, there should be column showing the sync status cloud/synced with on-prem directory.

 

Easiest way to test is to create a new test user to the synced OU and see whether it is synced to cloud or not.

 

You can see the what happens under the hood if you start the Synchronization Service app (aka miisclient) and see the operations tab. There are export events with your Office 365 tenant name, click that and you'll see how many objects are created/updated/deleted.

 

The password is updated from on-prem to existing cloud user only if the users are matched during the sync (same upn/email).

Thanks for the help.  It looks like I am striking out.  I can see that it IS picking up deltas from the domain, but when it comes to the export portion, nothing is actually being written to Azure.  

In Synchronization Service, I do a FULL IMPORT, and I can see 8 UNCHANGED, and 1 UPDATE (The update is a user I added to the OU)

Immediately following is an EXPORT, but there are 0 adds, updates, renames, deletes, or delete adds

So I feel like I am getting closer, but not quite there yet.  There are no errors though.

 


@Nestori Syynimaa wrote:

You may need to logout and in again, as admin center is not aware that you turned the sync on. After logging in, there should be column showing the sync status cloud/synced with on-prem directory.

 

Easiest way to test is to create a new test user to the synced OU and see whether it is synced to cloud or not.

 

You can see the what happens under the hood if you start the Synchronization Service app (aka miisclient) and see the operations tab. There are export events with your Office 365 tenant name, click that and you'll see how many objects are created/updated/deleted.

 

The password is updated from on-prem to existing cloud user only if the users are matched during the sync (same upn/email).


 

Do not run the those import etc. in Synchronization Service, you might end up messing everything. Instead, to manually run the synchronization, use the following PowerShell cmd:

Start-AdSyncSyncCycle

Because you have tried to sync things directly from the Synchronization Service, run the full-sync first time:

Start-AdSyncSyncCycle -PolicyType Initial 

 Edit: After running the PowerShell cmd, you can follow the progress in Synchronization Service

You should get emails about errors in sync if you have provided your email in the organization profile. Other than that i think it is enough to check if user appears in adnin center and its details are correct. Export won't sync anything if only deltas are needed to sync.