Domain Controller Placement
You should avoid making every Windows Server 2003 into a domain controller. This hurts performance by taking CPU cycles for replication and directory management. It also makes the replication topology unnecessarily complex.
The initial number of domain controllers depends primarily on fault tolerance. You should always have at least two domain controllers in a domain to ensure that you have a full copy of Active Directory ready for action in case either server should fail. I recommend having three so that you can do maintenance on one server while the other two are up and ready for work.
Reliability and performance then become the primary criteria for selecting domain controllers. Plan on putting at least two domain controllers in every large office (1000+ users) to get acceptable performance during morning logon and for fault tolerance.
Put at least one domain controller in every office where you do not want users authenticating over the WAN. If you have a solid, fast network infrastructure, you might be able to draw the line at 50 users. If your infrastructure is slow or prone to failure, you might want to reduce the number to 10.
If you do not have a domain controller in an office with member servers, a network WAN failure will eventually cut the users off from their local servers. This is because the Kerberos tickets eventually expire (10-hour default lifetime). You don't want to put the production floor of a factory down because some construction worker put a backhoe through the communication link to your domain controller. In these instances, you'll need a local domain controller.
Global Catalog Servers
Global Catalog servers are a vital component of your Active Directory architecture. The Windows authentication system relies on the Global Catalog to obtain Universal group membership. Client/server applications like Exchange 2000 rely on the GC for information. Many LDAP queries take a lot longer if the client is forced to walk the tree rather than query the GC.
If a site has no GC server available, users will only be allowed to log on to the domain if a local domain controller has been configured to cache the GC information. Otherwise, they will get an error saying that no GC server can be contacted and logon has been denied. This restriction does not apply to administrators.
Designating a domain controller as a GC server can significantly increase the hardware requirements for the server in a big network. If you have 200,000 users in your forest but only 20,000 or so in any one domain, the GC servers in each domain will have a fairly hefty Ntds.dit file to handle. You must size your server hardware accordingly.
Place at least one GC in every large office. Smaller offices can either have a GC or a standard domain controller configured to cache GC information.
If you have only one domain, you should enable the Global Catalog on every server. This ensures that a client can send a query to port 3268 on any server and get a response. There is no additional overhead or performance decrement for taking this action.
The stability and reliability of a Windows Server 2003 domain absolutely depends on the stability and reliability of the dynamic DNS system that provides name resolution services for that domain. It does no good to put a domain controller in a branch office to achieve fault tolerance without placing a dynamic DNS secondary for the zone in the same office.
The most straightforward way to distribute DNS services in conjunction with Active Directory is to use Active Directory Integrated zones (see Chapter 5, "Managing DNS," for details). This places the DNS records directly into Active Directory where every domain controller can reach them. All you need to do is install DNS on a domain controller and that's that. It will see the integrated zones and display them automatically. And thanks to the multiple-master nature of Active Directory, every domain controller running DNS can make changes to the zone.
A few caveats apply when using Active Directory Integrated DNS zones. Foremost is the requirement that the DNS servers must also be domain controllers. You can, if you want, create standard secondaries that pull a copy of the zone from an Active Directory Integrated primary. As with standard DNS, this secondary copy will be read-only. You should always have at least one standard secondary DNS server so you can quickly recover a zone should there be a problem with Active Directory replication. You do not need to point any clients at this server. It's just there as an online backup.
If a domain controller is running DNS, you should always configure the TCP/IP properties to point at another DNS server for name resolution. Pointing a domain controller at itself can result in a Catch-22 situation where the domain controller cannot replicate changes because it cannot find the IP address of its replication partners and it cannot update its copy of the zone to get those IP addresses because of the replication failure. You could also encounter problems during boot in which the Active Directory services start before DNS starts.