AD Sites – a common misconfiguration

Over the past few weeks, i’ve been disturbed to run into a number of corporates that have configured their AD sites in strange ways… 

an example – Multiple sites around the country, DC’s in 10 locations, therefore 10 AD sites are defined and all subnets made a member of those 10 AD sites (irrelevant of if their LAN connected or not) – even though they cover 50+ physical sites.

First up – lets consider what AD Sites are used for

1) Replication between DC’s

2) Client location of DC’s

3) Applying group policy

4) Exchange 2007 (and probably 2010) routing

5) SCCM Boundaries (optional, but preferable IMO)

All geographical sites in your organisation should have their own AD site defined (even if there is no DC or other server at that site), this allows us to control AD and exchange traffic (via site link cost), apply group policy to specific locations (common location based policies are IE settings or WSUS policy) and setup SCCM boundaries which are updated centrally (via AD sites).

On a side note to this – applying GPO via AD Site is massively underused. All to often, admins go through the process of creating OU’s to put computer objects in based on location, all to apply WSUS settings. Not only does this require constant admin, but when a roaming user goes to office B for the week, they still pull their updates from office A!

AD Sites are there for a good reason – use them appropriately to reduce your network bandwidth usage.