Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for placement of Active Directory domain controllers and the associated site links.

Domain controller (DC) placement can have a huge impact on user experience (e.g. the impact on logon times) but generally the choices are for placement on hub sites or at satellite (branch) locations and these should each be considered on a case-by-case basis, looking at the network and application requirements.

It’s worth mentioning that available network bandwidth has generally increased considerably since early Active Directory deployments were designed and this will allow for consolidation of the overall number of domain controllers in many cases.

With regards to global catalog (GC) servers, there are very few reasons not to make all domain controllers global catalog servers. Indeed, in a single-domain forest, all domain controllers are effectively GCs. In particular, multi-domain forests using user principle names (UPNs) for logon should consider making each DC a GC.

Read-only domain controllers (RODCs) are new in Windows Server 2008 and provide read-only access to Active Directory. Many people (myself included) have compared this functionality with Windows NT backup domain controllers (BDCs) but that’s not a true comparison as no passwords are stored locally and an RODC cannot be promoted to a full DC. The introduction of RODC functionality is really a security feature to mitigate against the theft of a DC on a high-risk site (e.g. a branch location without a physically secure computer room) and is not really intended for DMZ access to AD. RODCs can reduce replication, as they only replicate inbound traffic; however where users travel between several remote sites they can increase logon traffic as the users details may not be available on the RODC.

The decision as to whether to deploy an RODC or a full DC will depend on:

• Application requirements (e.g. does the application need to write to the directory).
• Site topology (e.g. site link bridging turned off – see below).
• Password replication policy (no account caching will lead to increased WAN/hub DC traffic).

Further details may be found in Microsoft’s RODC planning and deployment guide.

AD site design is closely linked to DC placement and there are two basic models:

1. A logical site for every physical location, assigning subnets for each physical location to the corresponding site.
2. A logical site for every physical location that has one or more DCs, assigning subnets for physical locations to the most appropriate site (based on the underlying network).

Both approaches work well; however with the first option, DNS site coverage must be considered (i.e. ensure that that appropriate name server records are in place). With the second option, clients are automatically referred. It’s also worth considering other applications (e.g. DFSR) and if there is no DC on site then option 1 may make more sense.

Site links should map to the underlying physical network with appropriate costs and replication schedules applied. According to Microsoft, one common mistake is to assign all sites to the DEFAULTIPSITELINK – effectively using a single link for replication and preventing the application of appropriate costs for least-cost routing.

Also, the option to bridge all site links is on my default and, although this is appropriate on a fully routable network (i.e. one where all DCs can communicate freely) it is not recommended for branch offices (due to the overheads associated with the intersite messaging transport and calculating site links) and can be disabled using repadmin /siteoptions (which still allows DFSR to calculate site link costs).

Custom site link bridges may be used where a network is not fully routable (e.g. if firewalls restrict communication between DCs).

The AD replication topology is automatically managed by the knowledge consistency checker (KCC) based on the site link design, automatically creating the connection objects that are required for replication. The KCC-generated topology is used for AD and sysvol replication using the file replication service (FRS); however in Windows Server 2008 sysvol is replicated using DFSR, once the domain functional level is at Windows Server 2008. This increases scalability (removing inefficiencies around FRS version vector joins). For new Windows Server 2008 native domains, replication of sysvol via DFSR is automatic but for upgraded domains there is a migration process to follow.

In the next post in this series, I’ll take a look at the design considerations for domain controller configuration.