Recently a question came up in the newsgroups about what the difference is between the set of partitions on a domain controller and the set of partitions on a global catalog server.  I wanted to take the opportunity to include the answer here and expand upon it slightly.

The question specifically was, “In a multi-domain environment, what is the main difference between the partitions on a domain controller that is also a global catalog server, versus other domain controllers that are not configured as global catalog servers?”

The difference is that global catalogs will have a different set of partitions.  Really, it’s an additional set of partitions.  In a Windows 2003 (or later) single-domain forest (we’ll call our domain fed.gov), there are 5 partitions (or naming contexts), by default:

  1. domain (fed.gov)
  2. config
  3. schema
  4. domainDNS [app partition] (fed.gov)
  5. forestDNS [app partition] (_msdcs.fed.gov)

When we add another domain (say childa) as a child domain, two new partitions are added:

  1. domain (childa.fed.gov)
  2. domainDNS [app partition] (childa.fed.gov)

A standard (non-GC) DC in the childa.fed.gov domain (let’s call him CHILDA-DC1) would have these 5 default partitions (assuming he’s also a DNS server):

  1. domain (childa.fed.gov)
  2. config
  3. schema
  4. domainDNS [app partition] (childa.fed.gov)
  5. forestDNS [app partition] (_msdcs.fed.gov)

Now, if we were to turn CHILDA-DC1 into a global catalog, he will pick up a partial attribute set (PAS) of all objects in the domain partition for every other domain in the forest.  The PAS is extensible by modifying the systemFlags attribute in the schema on the attributeClass object you want to include.  [Thanks Tony for catching this oversight in my newsgroup response].  This copy of the other domain partitions will be marked as read-only on CHILDA-DC1.  In this case, CHILDA-DC1 will pick up the fed.gov domain partition.  Now the partitions on CHILDA-DC1 will look like this:

  1. domain (childa.fed.gov)
  2. config
  3. schema
  4. domainDNS [app partition] (childa.fed.gov)
  5. forestDNS [app partition] (_msdcs.fed.gov)
  6. domain (fed.gov)  <– read-only copy of all objects

One thing that I want to point out is that CHILDA-DC1 did not pick up the domainDNS partition for fed.gov.  That’s because NDNCs (non-domain naming contexts) are excluded from the global catalog.  This is a great advantage of moving DNS data to application partitions as it means that your domain controllers will not have to endure the overhead of replicating and storing DNS data for a zone that they do not host.

Of course, the more domains you have, the more partitions that a GC will hold.  While this does mean some replication and storage overhead (which varies by size and volatility of the domain), generally speaking, it is a good idea to start with the goal of making all DCs into global catalog servers.  And since in any modern domain, global catalogs are required for logon authentication, you may find the savings from authentication traffic outweighs the cost of the replication traffic.