How do i setup AD site links and Cost

Brass Contributor


Hi AD Guys,

France Branch office DC died and We have set the London DNS on  France DHCP scopes.

users are accessing the AWS file servers but very slowly.


What is the best way to configure that site link for better access?


Do I need to create a new link to France—AWS? or has nothing to do with AD?


3 Replies



The short answer is "nothing to do with AD".


There's stuff you can do to influence domain controller selection while France is brought back online (which is only worth talking about if France will be offline for some time), but for files, this only relates (normally) to SYSVOL content, which in principle should only in turn relate to things like group policy files and such.


Given people shouldn't be storing "normal work" files on the SYSVOL, this is why AD shouldn't have any bearing on accessing the AWS-UK files.




Thanks, Lain,

Noticed those site link costs are set up like 500 and 225 will that makes any effect? i have 40-50 sites and all are set up at different costs. also, noticed that sites are connected to the default site links? how do we clean up those messes properly to make the replication and healthy environment?



The actual siteLink cost values aren't important on their own.


My best guess is that "large" (large being subjective) values were used between countries to promote regionally-local sites ahead of crossing international boundaries, in which case those large values make total sense.


What matters is their relative weighting compared to other siteLink objects coming from the same site (if there are multiple, that is.)


The cost attribute is an INTEGER that has no upper or lower limit bounds meaning it can accept ridiculously large values, so there's really nothing to worry about.



There are other influential control points outside of the siteLink cost value, too, such as whether automatic site bridging has been left enabled (uncommon in larger environments but definitely possible) and whether siteLinkBridge objects have been defined (rarely used, which is sad because they're incredibly useful from a disaster recovery perspective - which is exactly the situation you're now in.)



One thing to watch out for is where the site design isn't done very well and lots of inappropriately-configured perimeter firewalls exist. The outcome from this kind of misconfiguration is unhappy users as authentication functions frequently time out as their client randomly tries to talk to domain controllers blocked by intermediate firewalls.


If this is happening, you can run the following statement in PowerShell on one of the affected clients - assuming they're Windows domain-joined clients - to get a brief overview of what that client believes it are the next closest (i.e. value in "AdjacentSites".) You do not need administrative rights to do this.


[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite() | Select-Object -Property Name, AdjacentSites


Proper site design is a big topic, filled with "it depends"-style answers. But for your file server issue, it's mostly unrelated - the obvious overlap being authentication (which would mostly incur infrequent, up-front overhead for the France clients when accessing a new file server or their current Kerberos ticket expires, etc.)


Getting back to your file server situation.


File servers that use DFS-N to point to underlying hosts in different locations will still continue to work, since clients choose what they think is the most appropriate server based on data stored in Active Directory, which you don't lose just because one domain controller disappeared. The pain point for the clients is that they can't query a local domain controller to get that information: it has to come from another domain controller elsewhere. But, since the data does still exist, they will arrive at the same conclusion as when the local domain controller existed.


So long as the local DFS-N target is still working, the user might experience a longer time in opening the file while the local domain controller is offline, but once opened should perform normally.


As my previous post alluded though (via the SYSVOL comment, but it could be any other DFS-N namespace using the domain controllers as a target), this is assuming the files don't live on the domain controllers themselves (which they shouldn't.)


However, the understanding I got from your original post is the file servers only live exclusively in AWS-London, in which case the DFS-N points above, while interesting, would have nothing to do with your current domain controller issue in France.