A Closer Look at Azure AD Connect – Part 4
Welcome to the fourth part of this article series about Azure AD Connect. In the previous article,...
Consider the following scenario: you are about to implement directory synchronization for Office 365. You have multiple Active Directory sites across several, geographically dispersed, locations all over the world. Unsurprisingly, some of these locations have better connectivity than others and you might not want AAD Connect to connect to Domain Controllers in locations with a slow or high latency connection at the risk of slowing down the entire process.
When Azure AD Connect connects to a new forest, it uses DNS to locate domain controllers it needs to connect to. Without additional configuration, it is very difficult to control or know exactly which Domain Controllers AAD Connect will connect to. I believe that within the domain it is installed in, AAD Connect will try and connect to Domain Controllers within the same site first –but I’m still waiting on getting that confirmed. Even if that is true, that would not necessarily be the case for remote forests as there is no way for AAD Connect to know which site in the remote forest is closest.
Once AAD Connect is installed, you will find that it is relatively easy to define a (static) list of Domain Controllers that AAD Connect should connect to.
And that’s all there is to it. Now, Azure AD Connect will only talk to the Domain Controllers you have specified.
Michael Van Horenbeeck is a Microsoft Certified Solutions Master (MCSM) and Exchange Server MVP from Belgium, with a strong focus on Microsoft Exchange, Office 365, Active Directory, and a bit of Lync. Michael has been active in the industry for about 12 years and developed a love for Exchange back in 2000. He is a frequent blogger and a member of the Belgian Unified Communications User Group Pro-Exchange. Besides writing about technology, Michael is a regular contributor to The UC Architects podcast and speaker at various conferences around the world.