Placing the Domain Naming Master on a GC Server
The Domain Naming Master FSMO role holder makes changes to the forest's domain namespace, such as when you add or delete a domain. When you create new domains, the Domain Naming Master must ensure that no other domain (or any other domain object) has the same name. It does so by checking the local (i.e., collocated) GC server. If the GC isn't local, the change will fail. To avoid this scenario, collocate the Schema Master FSMO role with the Domain Naming Master role holder.
One Site, At Least One GC
In native-mode domains, the GC plays an important role during user logon. The Key Distribution Center (KDC) on the authenticating DC will contact a GC to enumerate universal group membership and will add to the user's token the SIDs of the universal groups to which the user belongs. If a client can't contact a GC to access this universal group information, the logon will fail. The logon isn't required in mixed-mode domains because universal groups are enabled only in Win2K native mode. Windows 2003 removes the requirement for GC availability during logon by introducing universal group membership caching. The cache is populated at first logon, and subsequent logons use the cached information. DCs refresh the cache periodically from the nearest GC.
People sometimes ask whether each domain should have its own GC. Because all GCs in the forest hold the same information irrespective of domain, the answer is clearly no. Each AD site should have at least one GC, however. GCs are located through DNS SRV records. As a result, site-aware clients will contact "close" GCs (i.e., those within the same site) in preference to those in other sites. If no GC is available within a site, any queries will be directed to GCs in other sites that might be on the other end of a slow WAN link, which is clearly undesirable.
Should all DCs be configured as GCs? This approach has the advantage of ensuring maximum GC redundancy, as well as providing a simple solution to the Infrastructure Master FSMO role question. The downside is the performance hit to both the network and the DCs as a result of the increased replication traffic. Obviously, this performance overhead increases with the number of domains, DCs, and GCs. The trick is to strike a balance between achieving a good level of redundancy and reducing the performance overhead. In a single-domain environment, you should configure all GCs as DCs because there's no overhead in doing so.
You might argue that a single-domain environment doesn't need GCs because the DCs already contain all the information relating to objects in the forest. This statement might be true, but I recommend that you have GCs available to service applications that specifically look for a GC. Exchange 2000 is an obvious example of such an application. And client logons still require a GC (at least in Win2K AD) regardless of how many domains you have.
Deploying GCs for Exchange 2000
The GC requirements for Exchange 2000 have been covered elsewhere, particularly in "The Importance of the Global Catalog," February 2001, http://www.exchange
admin.com, InstantDoc ID 16374. The point I'd like to stress is that both Exchange 2000 and the Microsoft Outlook client make heavy use of the GC. Exchange 2000 references the GC for information about users, contacts, and distribution lists (DLs), as well as for essential configuration data. Without access to a GC, most Exchange operations won't function. The Outlook client requires access to a GC to perform Global Address List (GAL) lookups.
I strongly recommend that you have at least one GC available in every AD site in which an Exchange 2000 server is located. Another general recommendation is to add an additional GC for every four Exchange servers. Basically, if you want a reliable messaging network, have the available budget, and your network can cope with additional replication data, consider deploying a few more GCs.
Points to Remember
Although some hard and fast rules govern GC placement, ultimately you have a great deal of flexibility about how you deploy GC servers. Remember that each AD environment is unique and that what works for you might not be suitable for another organization.
Being overly enthusiastic with GC deployment has some disadvantages, such as increased network and DC performance hits, but being too miserly doesn't pay, either. Make sure that you have at least some redundancy, and remember that if you miscalculate, you can easily enable or disable GC servers on the fly.
The final and most important point is that GC placement is not a "fire-and-forget" activity. You'll need to regularly revisit placement decisions as your forest changes and evolves. Monitoring your DC and network infrastructure resources will help with this decision-making process.
End of Article
)
Sergio Fonseca March 14, 2004