Originally posted @ Lucian.Blog. Follow Lucian on twitter @Lucianfrango.


I was rather stuck the other day. Azure AD Connect provisioning has not been the smoothest of installs even following the wizard and successfully completing the mostly automated process. Azure AD Connect has built upon the previous generation sync services and, from what I’ve read, isn’t much of a new app, rather a version upgrade and re-name from the AADSync service still (as of July 2015) the default for Office 365 directory replication from on-premises to Azure AD.

Past versions and previous generation aside, a now generally available app should feature a working and thoroughly tested feature set. Should…

Background

Let me set the scene or paint the picture if you will. I’ve freshly installed Azure AD Connect on a new Windows Server 2012 R2 server hosted in Azure compute. Its not in production yet so its just a little baby standard A1. However the specifications at this stage does the job nicely having nothing else running on the server.

Windows Server 2012 R2 data centre, service packs, patches, security updates and Azure AD Connect. That is all that is running on this brand new server. Theres no current synchronisation apps or service currently in-place or in production in this scenario.

Problem

After successfully completing an install of Azure AD Connect, the AADC wizard has configured replication to Azure AD with a replicated ‘service’ account. This account would likely appear for everyone as follows:

[email protected]

This is the directory synchronisation service account.

When AADC sync services started and attempted full import and full synchronisation processes I unfortunately got stuck with the following error: Event ID 6900:

And as you can see in the screenshot below I also didn’t sync a single user to Azure AD:

Resolution

The resolution though is not to difficult. There’s two options or ways to go about the solution. I chose option 2. So what are the two options?

Option 1 is to simply add the Azure AD Connect sync service account to the global admins in Office 365. This will in turn make it a global admin of Azure AD which will now grant it the write permissions to be able to add object data to Azure AD. Easy!

Option 2 is to update the user account in the AADC sync service with a global admin from Office 365 / Azure AD. I had already created such an account: [email protected] in my tenant. I had done this already as I knew I needed a sync service account. To update the account details I simply:

  • Logged onto my AADConnect server
  • Launched synchronisation service manager from the Server 2012 R2 start menu
  • Navigated to Connections
  • Selected Windows Azure AD connector and right clicked
  • Selected properties
  • Selected connectivity from the left hand menu
  • Updated the user and password with my previously created account
  • Saved and all done!

Ahh but not quite. Now I had to manually run a full import and a full sync not only from ADDS but also to Azure AD. Once this is done my users were all sync’ed up to Azure AD!

PRO TIP: With a fresh install of AADConnect on a new server I also had to manually select my desired OU’s from my Active Directory containers. By default it had selected the entire domain and all OU’s which is not ideal.

Thanks for reading, I hope that helps you out of a bind!


Originally posted @ Lucian.Blog. Follow Lucian on twitter @Lucianfrango.

Category:
Azure Infrastructure, Identity and Access Management
Tags:
, ,

Join the conversation! 8 Comments

    • Hi there,

      The account that I had problems with in this blog post was listed at the bottom of that Microsoft KB article.
      Its the “Azure AD Account for sync”.

      Thanks,
      Lucian

  1. ah
    thanks

  2. Thanks, great article, saved me creating a support case for MS!!!

  3. Thanks, resolved.
    Good Troubleshooting
    JAC

Comments are closed.