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 Active Directory domain controller configuration and DNS, which is critical to any Active Directory deployment.

Whilst the CPU specification for each server running as a domain controller will affect query performance, so can the disk configuration. Active Directory’s disk usage is mostly reads and the few writes are written to transaction logs before being committed to the database. For this reason, the separation of the logs (mostly written) from the database files (mostly read) can improve disk throughput.

Unlike for Exchange Server (where the decision to separate transaction logs from database files is mostly for resilience) with AD’s multi-master replication model providing resilience, the separation of logs and database files on a domain controller is about performance.

Having said that, in the same way that network improvements have allowed for domain controller consolidation, the move to a 64-bit version of Windows Server allows a larger addressable memory space and may even allow the entire AD database to be cached in RAM.

One critical piece of advice relating to domain controllers is when they are running in a virtualised environment. Microsoft recommends that DCs are never snapshotted (even RODCs), due to the potential to re-introduce out of date changes into AD if that snapshot is restored at a later date. Also, DCs should be configured to synchronise their time with the PDC emulator (the default) and not with the virtualisation host.

As I mentioned previously, DNS is critical to the correct operation of Active Directory and, which other DNS servers may be used, Microsoft recommends the use of AD-integrated DNS where possible as this provides a distributed, highly available DNS (effectively, DNS is as available as AD is). This can cause a political debate in some organisations, particularly where there is a heterogeneous network and the non-Windows computers do not use Active Directory. It is possible to configure Windows computers to use Windows DNS (AD integrated) and non-Windows computers to use another DNS implementation but this gets messy where shared subnets are involved (reverse lookup zones will be incomplete). For this reason, wherever possible, consolidation into a single organisational DNS should be considered.

Due to the overhead of managing root hints, Microsoft also recommends the use of the forwarding model and Windows Server 2003 introduced conditional forwarding, which is particularly useful where there are multiple forests, each of which is authoritative for its own zone. Windows Server 2008 improves conditional forwarding by storing conditional forwarding information in AD, rather than on each server (which created additional management overhead) although the standard forwarding is still defined on a per-server basis.