The global catalog is an index of the Active
Directory database that stores a full replica of all objects in the
directory for its host domain, and a partial replica of all objects
contained in the directory of every domain in the forest. In other
words, a global catalog contains a replica of every object in Active
Directory, but with a limited number of each object’s attributes.
Global catalog servers, often referred to as GCs,
are Active Directory domain controllers that house a copy of the global
catalog. A global catalog server performs two key roles:
Provides universal group membership information to a domain controller when a logon process is initiated
Enables finding directory information regardless of which domain in the forest contains the data
Access to a global catalog server is necessary
for a user to authenticate to the domain. If a global catalog is not
available when a user initiates a network logon process, the user is
only able to log on to the local computer, and cannot access network
resources.
With such an important role to play, it is a
common practice to locate at least one global catalog server in each
physical location, as it is referenced often by clients and by
applications such as Exchange.
Understanding the Relationship Between Exchange Server 2007 and the AD Global Catalog
In the past, an Exchange server could continue
to operate by itself with few dependencies on other system components.
Because all components of the mail system were locally confined to the
same server, downtime was an all-or-nothing prospect. The segregation of
the directory into Active Directory has changed the playing field
somewhat. In many cases, down-level clients no longer operate
independently in the event of a global catalog server failure. Keep this
in mind, especially when designing and deploying a domain controller
and global catalog infrastructure.
Note
Because Outlook clients and Exchange can behave
erratically if the global catalog they have been using goes down, it is
important to scrutinize which systems receive a copy of the global
catalog. In other words, it is not wise to set up a GC/DC on a
workstation or substandard hardware, simply to off-load some work from
the production domain controllers. If that server fails, the effect on
the clients is the same as if their Exchange server failed.
Understanding Global Catalog Structure
The
global catalog is an oft-misunderstood concept with Active Directory.
In addition, design mistakes with global catalog placement can
potentially cripple a network, so a full understanding of what the
global catalog is and how it works is warranted.
As mentioned earlier, Active Directory was
developed as a standards-based LDAP implementation, and the AD structure
acts as an X.500 tree. Queries against the Active Directory must,
therefore, have some method of traversing the directory tree to find
objects. This means that queries that are sent to a domain controller in
a subdomain need to be referred to other domain controllers in other
domains in the forest. In large forests, this can significantly increase
the time it takes to perform queries.
In Active Directory, the global catalog serves
as a mechanism for improving query response time. The global catalog
contains a partial set of all objects (users, computers, and other AD
objects) in the entire AD forest. The most commonly searched attributes
are stored and replicated in the global catalog (that is, first name,
username, email address). By storing a read-only copy of objects from
other domains locally, full tree searches across the entire forest are
accomplished significantly faster. So, in a large forest, a server that
holds a copy of the global catalog contains information replicated from
all domains in the forest.
Using Best Practices for Global Catalog Placement
All users accessing Exchange resources should
have fast access to a global catalog server. At least one global catalog
server must be installed on each domain that contains an Exchange
server; however, to achieve the best performance in larger
organizations, additional global catalog servers should definitely be
considered.
As a starting point, per site, there should be a
4:1 ratio of Exchange processors to global catalog server processors,
assuming, of course, the processors are of comparable models and speeds.
So, if you have four Exchange servers, each with four processors, you
should have four processors running your global catalog servers.
Bear in mind, however, that increased global
catalog server usage, very large Active Directory implementations, or
the use of extremely large distribution lists might necessitate more
global catalog servers.
Note
With respect to the global catalog processor
ratio rule, the 4:1 processor ratio rule from prior versions of
Exchange, which assumes a result of one global catalog server being
deployed for every two mailbox servers, applies to any environment where
the database file (the .dit file) for Active Directory is
larger than 1GB, and, therefore, cannot fit into memory. Exchange 2007
is undergoing a variety of performance tests, and more prescriptive
guidance is expected in the RTM version of Exchange 2007.
Promoting a Domain Controller to a Global Catalog
Although
any domain controller can easily be promoted to a global catalog
server, the promotion can have a significant impact on network
operations and performance while the topology is updated and the copy of
the catalog is passed to the server.
During the promotion, the server immediately
notifies DNS if it’s new status. In the early days of Active Directory,
this often caused problems, as the Exchange servers would immediately
begin utilizing the global catalog server before it had finished
building the catalog. This problem was rectified in Exchange 2000,
Service Pack 2, with the addition of a mechanism that detects the
readiness of a global catalog server and prevents Exchange from querying
new servers until a full copy of the catalog has been received.
The procedure to promote a domain controller to a global catalog server is as follows:
1. | On
the domain controller, click Start, point to Programs, click
Administrative Tools, and then click Active Directory Sites and Service.
|
2. | In the console tree, double-click Sites, double-click the name of the site, and then double-click Servers.
|
3. | Double-click the target domain controller.
|
4. | In the details pane, right-click NTDS Settings, and then click Properties.
|
5. | On the General tab, click to select the Global Catalog check box, as shown in Figure 1.
|
6. | Click OK to finalize the operation.
|
In
older versions of the Windows Server operating system, it was necessary
to restart the domain controller after a promotion to a global catalog;
however, as of Windows Server 2003, this step is no longer necessary.
Verifying Global Catalog Creation
When a domain controller receives the orders to
become a global catalog server, there is a period of time when the GC
information will replicate to that domain controller. Depending on the
size of the global catalog, this could take a significant period of
time. To determine when a domain controller has received the full subset
of information, use the replmon (replication monitor) utility from the Windows Server 2003 support tools. The replmon
utility indicates which portions of the AD database are replicated to
different domain controllers in a forest, and how recently they have
been updated.
Replmon enables an administrator to
determine the replication status of each domain naming context in the
forest. Because a global catalog server should have a copy of each
domain naming context in the forest, determine the replication status of
the new GC with replmon. For example, the fully replicated global catalog server in Figure 2
contains the default naming contexts, such as Schema, Configuration,
and DnsZones, in addition to domain naming contexts for all domains. In
this example, the companyabc.com domain has been replicated successfully to the VMW-DC2 domain controller.
Exploring Global Catalog Demotion
Removing
a global catalog server from production can also have a detrimental
effect in certain cases. Outlook 2000 and older clients, for example,
experience lockup issues if the global catalog server they have been
using is shut down or removed from GC service. The loss of a GC server
is the equivalent of the loss of an Exchange server, and should,
therefore, not be taken lightly. Outlook 2002 and greater clients,
however, automatically detect the failure of their global catalog server
and reroute themselves within 30 seconds. Scheduling global catalog or
domain controller demotions for the off-hours, therefore, is important.
Note
If a production global catalog server goes
down, down-level (pre-2002) versions of Outlook can regain connectivity
via a restart of the Outlook client. In some cases, this means forcing
the closure of OUTLOOK.EXE and MAPISP32.EXE from the Task Manager or rebooting the system.
Deploying Domain Controllers Using the Install from Media Option
When deploying a remote site infrastructure to
support Exchange Server 2007, take care to examine best-practice
deployment techniques for domain controllers to optimize the procedure.
In the past, deploying domain controller and/or global catalog servers
to remote sites was a rather strenuous affair. Because each new domain
controller would need to replicate a local copy of the Active Directory
for itself, careful consideration into replication bandwidth was taken
into account. In many cases, this required one of these options:
The domain controller was set up remotely at the start of a weekend or other period of low bandwidth.
The
domain controller hardware was physically set up in the home office of
an organization and then shipped to the remote location.
This procedure was unwieldy and time-consuming
with Windows 2000 Active Directory. Fortunately, Windows Server 2003
addressed this issue through use of the Install from Media option for
Active Directory domain controllers.
The concept behind the media-based GC/DC
replication is straightforward. A current, running domain controller
backs up the directory through a normal backup process. The backup files
are then copied to a backup media, such as a CD or tape, and shipped to
the remote GC destination. Upon arrival, the dcpromo command can be run with the /adv switch (dcpromo /adv), which activates the option to install from media, as illustrated in Figure 3.
After the dcpromo
command restores the directory information from the backup, an
incremental update of the changes made since the media was created is
performed. Because of this, you still need network connectivity
throughout the dcpromo process, although the amount of replication required is significantly less. Because some dcpromo operations have been known to take days and even weeks, this concept can dramatically help deploy remote domain controllers.
Note
If the copy of the global catalog that has been
backed up is older than the tombstone date for objects in the Active
Directory (which by default is 60 days), this type of dcpromo
will fail. This built-in safety mechanism prevents the introduction of
lingering objects and also assures that the information is relatively up
to date and no significant incremental replication is required.
Understanding Universal Group Caching for AD Sites
Windows Server 2003 Active Directory enables the
creation of AD sites that cache universal group membership. Any time a
user uses a universal group, the membership of that group is cached on
the local domain controller and is used when the next request comes for
that group’s membership. This also lessens the replication traffic that
would occur if a global catalog was placed in remote sites.
One of the main sources of replication traffic
is group membership queries. In Windows 2000 Server Active Directory,
every time clients logged on, their universal group membership was
queried, requiring a global catalog to be contacted. This significantly
increased logon and query time for clients that did not have local
global catalog servers. Consequently, many organizations had stipulated
that every site, no matter the size, have a local global catalog server
to ensure quick authentication and directory lookups. The downside of
this was that replication across the directory was increased because
every site would receive a copy of every item in the entire AD, even
though only a small portion of those items would be referenced by an
average site.
Universal group caching solved this problem
because only those groups that are commonly referenced by a site are
stored locally, and requests for group replication are limited to the
items in the cache. This helps limit replication and keep domain logons
speedy.
Universal group caching capability is established on a per-site basis, through the following technique:
1. | Open Active Directory Sites and Services.
|
2. | Navigate to Sites, sitename.
|
3. | Right-click NTDS Site Settings, and choose Properties.
|
4. | Check the Enable Universal Group Membership Caching check box, as shown in Figure 4.
|
5. | Click OK to save the changes.
|
Note
Universal group (UG) caching is useful
for minimizing remote-site replication traffic and optimizing user
logons. Universal group caching does not replace the need for local
global catalog servers in sites with Exchange servers, however, because
it does not replace the use of the GC port (3268), which is required by
Exchange. UG caching can still
be used in remote sites without Exchange servers that use the site
consolidation strategies of Exchange Server previously mentioned.
