http://technet.microsoft.

com/en-us/library/how-
global-catalog-servers-work(WS.10).aspx

Global Catalog

A. What Is the Global Catalog?

B. How the Global Catalog Works

C. Global Catalog Tools and Settings

 A .What Is the Global Catalog?
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows
Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

In this section

• 1.Common Global Catalog Scenarios

• 2.Global Catalog Dependencies and Interactions

The global catalog is a distributed data repository that contains a searchable, partial representation of
every object in every domain in a multidomain Active Directory Domain Services (AD DS) forest. The
global catalog is stored on domain controllers that have been designated as global catalog servers and is
distributed through multimaster replication. Searches that are directed to the global catalog are faster
because they do not involve referrals to different domain controllers.

Note

In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named
Active Directory. In Windows Server 2008 R2 and Windows Server 2008, the directory service is named
Active Directory Domain Services. The rest of this topic refers to AD DS, but the information is also
applicable to Active Directory.
In addition to configuration and schema directory partition replicas, every domain controller in a forest
stores a full, writable replica of a single domain directory partition. Therefore, a domain controller can
locate only the objects in its domain. Locating an object in a different domain would require the user or
application to provide the domain of the requested object.

The global catalog provides the ability to locate objects from any domain without having to know the
domain name. A global catalog server is a domain controller that, in addition to its full, writable domain
directory partition replica, also stores a partial, read-only replica of all other domain directory partitions in
the forest. The additional domain directory partitions are partial because only a limited set of attributes is
included for each object. By including only the attributes that are most used for searching, every object in
every domain in even the largest forest can be represented in the database of a single global catalog
server.

Note

A global catalog server can also store a full, writable replica of an application directory partition, but
objects in application directory partitions are not replicated to the global catalog as partial, read-only
directory partitions.
The global catalog is built and updated automatically by the AD DS replication system. The attributes that
are replicated to the global catalog are identified in the schema as the partial attribute set (PAS) and are
defined by default by Microsoft. However, to optimize searching, you can edit the schema by adding or
removing attributes that are stored in the global catalog.

In Windows 2000 Server environments, any change to the PAS results in full synchronization (update of
all attributes) of the global catalog. Later versions of Windows Server reduce the impact of updating the
global catalog by replicating only the attributes that change.

In a single-domain forest, a global catalog server stores a full, writable replica of the domain and does not
store any partial replica. A global catalog server in a single-domain forest functions in the same manner as
a non-global-catalog server except for the processing of forest-wide searches.
 1. Common Global Catalog Scenarios
The following events require a global catalog server:

• Forest-wide searches. The global catalog provides a resource for searching an AD DS forest.

Forest-wide searches are identified by the LDAP port that they use. If the search query uses
port 3268, the query is sent to a global catalog server.

• User logon. In a forest that has more than one domain, two conditions require the global

catalog during user authentication:

• In a domain that operates at the Windows 2000 native domain functional level or higher,

domain controllers must request universal group membership enumeration from a global
catalog server.

• When a user principal name (UPN) is used at logon and the forest has more than one

domain, a global catalog server is required to resolve the name.

• Universal Group Membership Caching: In a forest that has more than one domain, in sites that

have domain users but no global catalog server, Universal Group Membership Caching can be
used to enable caching of logon credentials so that the global catalog does not have to be
contacted for subsequent user logons. This feature eliminates the need to retrieve universal
group memberships across a WAN link from a global catalog server in a different site.

Universal groups are available only in a domain that operates at the Windows 2000 native domain
functional level or higher.

• Exchange Address Book lookups. Servers running Microsoft Exchange Server rely on access to

the global catalog for address information. Users use global catalog servers to access the global
address list (GAL).

Search Requests
Because a domain controller that acts as a global catalog server stores objects for all domains in the
forest, users and applications can use the global catalog to locate objects in any domain within a
multidomain forest without a referral to a different server.

When a forest consists of a single domain, every domain controller has a full, writable copy of every object
in the domain and forest. However, it is important to retain the global catalog on at least one domain
controller because many applications use port 3268 for searching. For example, if you do not have any
global catalog servers, the Search command on the Start menu cannot locate objects in AD DS.

The replicas that are replicated to the global catalog also include the access permissions for each object
and attribute. If you are searching for an object that you do not have permission to access, you do not
see the object in the list of search results. Users can find only objects to which they are allowed access.

User Logon Support

In addition to its role as a search provider, in a forest that has more than one domain, the global catalog
has a role as an identity source during the user logon process. Universal groups can provide access to
resources outside of the users domain. User principal names (UPNs) can specify a domain other than the
domain of the user. By making universal group membership and UPN domain-user mapping information
available on all global catalog servers, the global catalog provides the definitive source for groups that are
capable of providing access in more than one domain and names that do not unequivocally identify the
domain of the user.

Universal Group Membership

During the domain logon process, the user must be authenticated. During the authentication process, the
user is validated (the domain controller verifies the identity of the user) and the user receives
authorization data for access to resources. To provide authorization data of a user, the authenticating
domain controller retrieves the security identifiers (SIDs) for all security groups of which the user is a
member and adds these SIDs to the user’s access token. In a forest that has more than one domain, the
global catalog is the only location where memberships of all universal groups in that forest can be
ascertained. For this reason, access to a global catalog server is required for successful authentication in a
domain that can have universal groups.

The global catalog stores the membership (the member attribute) of only universal groups. The
membership of other groups can be ascertained at the domain level.

Because a universal group can have members from domains other than the domain where the group
object is stored and can be used to provide access to resources in any domain, only a global catalog
server is guaranteed to have all universal group memberships that are required for authentication.

For example, a user might be a member of a universal group that has its group object stored in a different
domain but provides access to resources in the user’s domain. To ensure that the user can be authorized
to access resources appropriately in this domain, the domain controller must have access to the
membership of all universal groups in the forest.

If a global catalog server is not available, the user logon fails.

User Principal Name

A user principal name (UPN) is a logon name that takes the form of an e-mail address. A UPN specifies the
user ID followed by a DNS domain name, separated by an "@" character (for example,
jsmith@contoso.com). UPNs allow administrative management of the UPN suffix to provide logon names
that:

• Match the user’s e-mail name.

• Do not reveal the domain structure of the forest.

When a user account is created, the UPN suffix is generated by default as userName@ DnsDomainName,
but it can be changed administratively. For example, in a forest that has four domains, the UPN suffix
might be configured to map to the external DNS name for the organization. The userPrincipalName
attribute of the user account identifies the UPN and is replicated to the global catalog.

When you use a UPN to log on to a domain, your workstation contacts a global catalog server to resolve
the name because the UPN suffix is not necessarily the domain for which the contacted domain controller
is authoritative. If the DNS domain name in the UPN suffix is not a valid DNS domain, the logon fails.
Assuming the UPN suffix is a valid DNS name, the global catalog server returns the name of the AD DS
domain to your workstation, which then queries DNS for a domain controller in that domain.

If a company has more than one forest and uses trust relationships between the domains in the different
forests, a UPN cannot be used to log on to a domain that is outside the user’s forest because the UPN is
resolved in the global catalog of the user’s forest.

Universal Group Membership Caching

Universal Group Membership Caching eliminates the need for a domain controller in a multidomain forest
to contact a global catalog server during the logon process in domains where universal groups are
available. Caching group membership reduces WAN traffic, which helps in sites where updating the cached
group membership of security principals, including user and computer accounts, generates less traffic than
replicating the global catalog to the site.

Use the following criteria to determine if a site is a good candidate for Universal Group Membership
Caching:
 • Number of users and computers in the site: The site has less than 500 combined users and

computers, including transient users who log on occasionally but not on a regular basis. The
cache of a user who logs on once continues to be updated periodically for 180 days after the first
logon. A general limit of 500 membership caches can be updated at a time. If greater than
500 security principals have cached group memberships, some caches might not be updated.

• Number of domain controllers: Each domain controller performs a refresh on every user in its site

once every eight hours. Depending on the number of domains in the forest, 500 security
principals and two domain controllers could generate more WAN traffic than placing a global
catalog server in the site. Therefore, you need to rationalize the WAN costs when exceeding
500 security principals and two domain controllers.

• Tolerance for high latency in group updates. Because domain controllers in the site where

Universal Group Membership Caching is enabled update the membership caches every eight
hours, and because credentials are always taken from the cache, updates to group memberships
are not reflected in the security principal’s credentials for up to eight hours.

Address Book Lookups

Exchange Server uses the global catalog to store mail recipient data that enables clients in a forest to
send and receive e-mail messages.

2. Global Catalog Dependencies and Interactions

Global catalog servers have the following dependencies and interactions with other Windows Server
technologies:

• AD DS installation. When AD DS is installed on the first domain controller in a forest, the

installation application creates that domain controller as a global catalog server.

• AD DS replication. The global catalog is built and maintained by AD DS replication:

• Subsequent to forest creation, when a domain controller is designated as a global

catalog server, AD DS replication automatically transfers PAS replicas to the domain

controller, including the partial replica of every domain in the forest other than the local
domain.

• To facilitate intersite replication of global catalog server updates, AD DS replication

selects global catalog servers as bridgehead servers whenever a global catalog server is
present in a site and domains that are not present in the site exist in other sites in the forest.

• Domain Name System (DNS). Global catalog server clients depend on DNS to provide the IP

address of global catalog servers. DNS is required to advertise global catalog servers for domain
controller location.
 • Net Logon service. Global catalog advertisement in DNS depends on the Net Logon service to

perform DNS registrations. When replication of the global catalog is complete, or when a global
catalog server starts, the Net Logon service publishes service (SRV) resource records in DNS that
specifically advertise the domain controller as a global catalog server.

• Domain controller Locator: When a global catalog server is requested (by a user or application

that launches a search over port 3268, or by a domain controller that is authenticating a user
logon), the domain controller Locator queries DNS for a global catalog server.

In the following diagram, global catalog interactions include tracking a global catalog server through the
following interactions, which are indicated by boxes:

• Active Directory installation of a new forest: Global catalog creation occurs during AD DS

installation of the first domain controller in the forest.

• Net Logon registration: Resource records are registered in DNS to advertise the domain

controller as a global catalog server.

• AD DS replication:

• When a new domain controller (DC2) is created and an administrator designates it as a

global catalog server, replication of the PAS from DC1 occurs.

• DC1 in DomainA replicates changes for DomainA to DC2, and DC2 replicates updates to

data for DomainB to DC1.

• DC location: The dotted lines enclose the processes whereby two clients locate a global catalog

server by querying DNS:

• A through C: (A) ClientX sends a query to the global catalog, which prompts (B) a DNS

query to locate the closest global catalog server, and then (C) the client contacts the returned
global catalog server DC2 to resolve the query.

• 1 through 5: (1) ClientY logs on to the domain, which prompts (2) a DNS query for the

closest domain controllers. (3) ClientY contacts the returned domain controller DC3 for
authentication. (4) DC3 queries DNS to find the closest global catalog server and then (5)
contacts the returned global catalog server DC2 to retrieve the universal groups for the user.
Interactions with Other Windows Technologies

The global catalog solves the problem of how to locate domain data that is not stored on a domain
controller in the domain of the client that requires the information. By using different ports for standard
LDAP queries (port 389) and global catalog queries (port 3268), AD DS effectively separates forest-wide
queries that require a global catalog server from local, domainwide queries that can be serviced by the
domain controller in the user’s domain.
 B .How the Global Catalog Works
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows
Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

In this section

• 1.Global Catalog Architecture

• 2.Global Catalog Protocols

• 3.Global Catalog Interfaces

• 4.Global Catalog Physical Structure

• 5.Global Catalog Processes and Interactions

• 6.Network Ports Used by the Global Catalog

In a multidomain Active Directory® Domain Services (AD DS) forest, the global catalog provides a central
repository of domain information for the forest by storing partial replicas of all domain directory partitions.
These partial replicas are distributed by multimaster replication to all global catalog servers in a forest.

Note

In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named
Active Directory. In Windows Server 2008 R2 and Windows Server 2008 and, the directory service is
named Active Directory Domain Services . The rest of this topic refers to AD DS, but the information is
also applicable to Active Directory.
The global catalog makes the directory structure within a forest transparent to users who perform a
search. For example, if you search for all printers in a forest, a global catalog server processes the query
in the global catalog and then returns the results. Without a global catalog server, this query would
require a search of every domain in the forest.

During an interactive domain logon, the domain controller authenticates the user by verifying the user’s
identity, and also provides authorization data for the user’s access token by determining all groups of
which the user is a member. Because the global catalog is the forestwide location of the membership of all
universal groups, access to a global catalog server is a requirement for authentication in a multidomain
forest. As such, an ideal distribution of the global catalog is to have at least one global catalog server in
each AD DS site. When a global catalog server is available in a site, the authenticating domain controller is
not required to communicate across a WAN link to retrieve global catalog information.
In branch office scenarios, it is often not feasible to deploy a global catalog server in every branch site. At
the same time, it is not cost effective to contact a global catalog server over a WAN link for every logon
that occurs in the site. On domain controllers that are running Windows Server 2003 or later, universal
group membership can be cached so that the domain controller must connect to a global catalog server
across a WAN link only for initial logons in the site; thereafter, universal group membership can be
checked from a local cache. Search clients, however, must always connect to global catalog servers across
the WAN if no global catalog server exists in the client’s site.

This subject describes the functionality of the global catalog and the replication of objects to global catalog
servers in an AD DS forest.

Global Catalog Architecture

Global catalog server architecture differs from non-global catalog server architecture in its use of the
nonstandard LDAP port 3268, which directs queries to the global catalog. Queries over this port are
formed the same way as any LDAP query, but AD DS varies the search behavior according to the port that
is used: queries over port 3268 target the global catalog directory partitions (including the read-only
domain directory partitions and the one writable domain directory partition for which the server is
authoritative), and queries over port 389 target only the writable domain, configuration, application, and
schema directory partition replicas stored by the global catalog server in its role as a domain controller. In
addition, domain controllers use the proprietary replication interface when they contact global catalog
servers to retrieve universal group membership during client logons.

Search clients include Exchange Address Book clients, which use the client MAPI provider Emsabp32.dll to
look up e-mail addresses in the global catalog. The client-side MAPI provider communicates with the
server through the proprietary Name Service Provider Interface (NSPI) RPC interface.

Windows NT clients use Net APIs to communicate with the Security Accounts Manager (SAM) on the
primary domain controller (PDC) emulator. The PDC emulator, a domain controller operations master role
in AD DS domains, manages search and replication communication with clients that are running
Windows NT.

The relationships between these architectural components are shown in the following diagram.
Descriptions for the major components are provided in the subsequent table.

Global Catalog Architecture

For a more detailed description of LDAP and replication client-server architecture, see “How the Active
Directory Replication Model Works.”

Global Catalog Architecture Components

Component Description

Clients Global catalog clients, including search clients and Address Book clients, as well as
domain controllers performing replication and universal group security identifier (SID)
retrieval during logon in a multidomain forest.

Network The physical IP network.

Interfaces LDAP over port 389 for read and write operations and LDAP over port 3268 for global
catalog search operations. NSPI and replication (REPL) use proprietary RPC protocols.
Retrieval of universal group membership occurs over RPC as part of the replication
RPC interface. Windows NT 4.0 clients and backup domain controllers (BDCs)
communicate with AD DS through the Security Accounts Manager (SAM) interface.

Directory The directory service component that runs as Ntdsa.dll on each domain controller,
System Agent providing the interfaces through which services and processes gain access to the
(DSA) directory database.

Extensible The directory service component that runs as Esent.dll. ESE manages the tables of
Storage Engine records that comprise the directory database.
(ESE)

Ntds.dit The AD DS data store.

database file
 2. Global Catalog Protocols
The following diagram shows the four interfaces into AD DS and the protocols that package the data
according to their specific applications. These protocols and interfaces are the same for all domain
controllers and are not specific to global catalog servers. The significance for the global catalog server is
that domain controllers use the proprietary RPC replication protocol not only for replication, but also to
contact the global catalog server when retrieving universal group membership information and when
updating the group membership cache when Universal Group Membership Caching is enabled.

Global Catalog Protocols

The protocols are described in the following table.

Global Catalog Protocols

Protocol Description

Lightweight The primary directory service protocol that specifies directory communications. It
directory access runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP)
protocol (LDAP) connectionless transports (UDP access is primarily used by the domain controller
Locator process and can also be used to query the rootDSE). Clients use LDAP to
query, create, update, and delete information that is stored in a directory service
over a TCP connection through the TCP default port 389. Global catalog clients can
use LDAP to query AD DS over a TCP connection through the TCP port 3268. AD DS
supports LDAP v2 (RFC 1777) and LDAP v3 (RFC 2251). LDAP v3 is an industry
standard that can be used with any directory service that implements the LDAP
protocol. LDAP is the preferred and most common way of interacting with AD DS.

Remote Protocol for replication (REPL) and domain controller management communications
procedure call (including global catalog server interactions), NSPI address book communications,
(RPC) and SAM-related communications. RPC is a powerful, robust, efficient, and secure
interprocess communication (IPC) mechanism that enables data exchange and
invocation of functionality residing in a different process. That different process can
be on the same computer, on the local area network (LAN), or across the Internet.

Simple mail Protocol for replication communications when a permanent, “always on” network
transfer protocol connection does not exist between two domain controllers. SMTP is used to transport
(SMTP) and deliver messages based on specifications in Request for Comments (RFC) 821
and RFC 822. SMTP can replicate only the configuration and schema directory
partitions and global catalog read-only replicas (not writable domain data).

3. Global Catalog Interfaces

Interfaces for global catalog servers are the AD DS data store interfaces, shown in the previous figure and
described in the following table.

Global Catalog Data Store Interfaces

Interface Description

LDAP The primary interface for AD DS access. Directory clients use LDAP v3 to connect to the
DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is
backward compatible with LDAP v2.

REPL The replication management interface that provides functionality for finding data about
domain controllers, converting the names of network objects between different formats,
manipulating service principal names (SPNs) and DSAs, and managing replication of
servers.

NSPI/MAPI Name Service Provider Interface (NSPI) by which Messaging API (MAPI) clients access
AD DS. Messaging clients gain access to AD DS by using MAPI address book providers. For
compatibility with existing messaging clients, AD DS supports the NSPI/RPC address book
provider, which provides directory access, for example, to find the telephone number of a
user.

SAM Proprietary interface for connecting to the DSA on behalf of clients that run
Windows NT 4.0 or earlier. These clients use Windows NT 4.0 networking APIs to connect
to the DSA through SAM. Replication with Windows NT 4.0 backup domain controllers
(BDCs) occurs through the SAM interface as well.

Note
The NSPI (MAPI) interface is provided only for support of legacy Microsoft Outlook clients. Development
against this interface is no longer supported.
For more information about AD DS data store interfaces, see “How the Data Store Works.”

4. Global Catalog Physical Structure

AD DS is a distributed directory service in which data is stored as replicas on multiple domain controllers
to provide a virtual database that maintains consistency through AD DS replication. Domain controllers
provide the domainwide distribution of directory data. Global catalog servers provide the forestwide
distribution of directory data in a multidomain forest.

Global Catalog Partial Attribute Set

In its role as a domain controller, a global catalog server stores one domain directory partition that has
writable objects with a full complement of writable attributes. In its role as global catalog server, it also
stores the objects of all other domain directory partitions in a multidomain forest as read-only objects with
a partial set of attributes. The set of attributes that are marked for inclusion in the global catalog are
called the partial attribute set (PAS). An attribute is marked for inclusion in the PAS as part of its schema
definition.

Objects in the schema that define an attribute are attributeSchema objects, which themselves have an
attribute isMemberOfPartialAttributeSet. If the value of that attribute is TRUE, the attribute is
replicated to the global catalog. The replication topology for the global catalog is generated automatically
by the Knowledge Consistency Checker (KCC), a built-in process that implements a replication topology
that is guaranteed to deliver the contents of every directory partition to every global catalog server.

The attributes that are replicated to the global catalog by default include a base set that have been
defined by Microsoft as the attributes that are most likely to be used in searches. Administrators can use
the Microsoft Management Console (MMC) Active Directory Schema snap-in to specify additional attributes
to meet the needs of their installation. In the Active Directory Schema snap-in, you can select the
Replicate this attribute to the global catalog check box to designate an attributeSchema object as a
member of the PAS, which sets the value of the isMemberOfPartialAttributeSet attribute to TRUE.

Domain Controller and Global Catalog Server Structure

The physical representation of global catalog data is the same as all domain controllers: the Ntds.dit
database stores object attributes in a single file. On a domain controller that is not a global catalog server,
the Ntds.dit file contains a full, writable replica of every object in one domain directory partition for its
own domain, plus the writable configuration and schema directory partitions.

Note

The schema directory partition is writable only on the domain controller that is the schema operations
master for the forest.
The following diagram shows the physical representations of the global catalog as a forestwide resource
that is distributed as a database on global catalog servers.
Global Catalog Physical Structure
As shown in the preceding diagram, a global catalog server stores a replica of its own domain (full and
writable) and a partial, read-only replica of all other domains in the forest. All directory partitions on a
global catalog server, whether full or partial, are stored in the directory database file (Ntds.dit) on that
server. That is, there is not a separate storage area for global catalog attributes; they are treated as
additional information in the directory database of the global catalog server.

The following table describes the physical components of the diagram.

Global Catalog Server Physical Components

Physical
Component Description

Active Directory The set of domains that comprise the AD DS logical structure and that are searchable
forest in the global catalog.

Domain Server that stores one full, writable domain directory partition plus forestwide
controller configuration and schema directory partitions. Global catalog servers are always
domain controllers.

Global catalog Domain controller that stores one full, writable domain plus forestwide configuration
server and schema directory partitions, as well as a partial, read-only replica of all other
domains in the forest.

Ntds.dit Database file that stores replicas of the AD DS objects held by any domain controller,
including global catalog servers.
 5. Global Catalog Processes and Interactions

In addition to its activities as a domain controller, the global catalog server supports the following special
activities in the forest:

• User logon: In a multidomain forest, domain controllers must contact a global catalog server to

retrieve any SIDs of universal groups that the user is a member of. Additionally, if the user
specifies a logon name in the form of a UPN, the domain controller contacts a global catalog
server to retrieve the domain of the user.

• Universal and global group caching and updates: In sites where Universal Group Membership

Caching is enabled, domain controllers that are running Windows Server 2003 or later cache
group memberships and keep the cache updated by contacting a global catalog server.

• Global catalog searches: Clients can search the global catalog by specifying port 3268 or by using

search applications that use this port. Search activities include:

• Validation of references to non-local directory objects. When a domain controller holds a

directory object with an attribute that references an object in another domain, this reference
is validated by contacting a global catalog server.

• Exchange Address Book lookups: Exchange Server uses AD DS as the address book

store. Outlook clients query the global catalog to locate Address Book information.

• Global catalog server creation and advertisement: Global catalog servers register global-catalog-

specific service (SRV) resource records in DNS so that clients can locate them according to site. If
no global catalog server is available in the site of the user, a global catalog server is located in
the next closest site, according to the cost matrix that is generated by the KCC from site link cost
settings.

• Global catalog replication: Global catalog servers must either have replication partners for all

domains or be able to replicate with another global catalog server. When changes to the PAS
occur on, and are replicated between, domain controllers that are running Windows Server 2003
or later, only the updated attributes are replicated. Changes to the PAS that occur on domain
controllers that are running Windows 2000 Server prompt a full synchronization of the entire
global catalog (all attributes in the PAS are replicated anew to all global catalog servers). For
more information about PAS replication, see Global Catalog Replication.

User Logon
When a domain user logs on interactively to a domain, the contacted domain controller must retrieve
information from a global catalog server under the following conditions:

• The user's domain is Windows 2000 native domain functional level or higher. In this case, the

user might belong to a universal group whose object is stored in a different domain.
 • The user’s logon name is a user principal name (UPN), which has the format

sAMAccountName@DNSDomainName. In this case, the DNS domain suffix is not necessarily the
user’s domain and the identity of the user’s domain must be retrieved from a global catalog
server.

Universal Group SID Retrieval

A universal group is a security group that is available at the Windows 2000 native domain functional level
or higher. During interactive user logon, the authenticating domain controller retrieves the SIDs that the
user’s workstation requires to build the access token for the user. To retrieve the SIDs of all universal
groups to which the user belongs, the authenticating domain controller must contact a global catalog
server. If a global catalog server is not available in the site when a user logs on to a domain in which
universal groups are available, the computer will use cached credentials to log the user on if the user has
previously logged on to the domain from the same workstation. If the user has not previously logged on to
the domain from the same computer, the user can log on to only the local computer.

Of the three group types that are used to allow access to resources in a forest (domain local, global, and
universal), only universal groups have their membership replicated to the global catalog. The values of the
member attribute of universal group objects that exist in all domains must be available to an
authenticating domain controller because:

• Universal groups can contain members, including individual user accounts and global groups,

from any domain in the forest. Therefore, the user who is logging on might have a membership
in a universal group that exists in a different domain.

• Universal groups can be added to access control lists in any domain in the forest. Therefore, the

user might have permissions on objects in this domain by virtue of membership in a universal
group that exists in a different domain.

Contrast this requirement with the domain local group membership. Domain local groups can also have
members from other domains; however, domain local groups can be added to access control lists in only
the domain in which they are created. Therefore, a domain controller can always determine a user’s
membership in all domain local groups that are required for authorization in its own domain.

For global groups, although these groups can be added to access control lists in any domain, they can
contain accounts from only the domain in which they are created. Therefore, the global group membership
of the user who is logging on can always be checked locally. However, global groups can be members of
universal groups that exist in different domains. When group nesting is in effect (which has the same
availability criteria as availability of universal groups), being a member of a global group that is itself a
member of a universal group can give the user access to resources other than those allowed by
membership in the global group alone.

During the logon process, the authenticating domain controller retrieves a list of global group SIDs from
the user’s domain. If universal groups are available in the user’s domain, the domain controller passes the
list of global group SIDs to the nearest global catalog server. The global catalog server responds as
follows:

• Enumerates the member attribute of all universal groups in the forest and adds universal group

SIDs to the user’s SID list as follows:

• All universal groups that contain the user’s SID.

• All universal groups that contain the SID of any of the global groups in the user’s SID

list.
 • Returns the list, including both universal group SIDs and global group SIDs, to the domain

controller.

The authenticating domain controller sends the list of SIDs that is returned from the global catalog server
to the user’s computer, along with domain local group SIDs from the user’s domain. The user's local
computer, which creates the access token for the user, adds the returned SIDs to the access token.

For more information about how domain controllers cache group membership, see Universal Group
Membership Caching. For more information about how SIDs are retrieved and used in access tokens, see
“How Access Tokens Work.” For more information about the authentication process, see “How the
Kerberos Version 5 Authentication Protocol Works.” For more information about the logon process, see
“How Interactive Logon Works.”

UPN Logon
A global catalog server resolves UPNs when the authenticating domain controller does not have knowledge
of the account. For example, if a users account is located in noam.corp.contoso.com and the user logs on
with a UPN of JSmith@contoso.com, the domain name in the UPN suffix does not match the user’s
domain. In the Windows Server 2003 and Windows 2000 Server logon screen, you can either type your
user name (sAMAccountName) and select the domain name from the drop-down list, or you can use a
UPN. If you use a UPN, as soon as you type the @ sign, the domain list becomes unavailable. In this case,
domain controllers running Windows Server 2003 or Windows 2000 Server take the domain name from
the UPN suffix. The UPN suffix is often (usually) different from the home domain of the user. In this case,
the responding domain controller must contact a global catalog server to determine the domain of the
user.

The following diagram shows the general sequence that occurs when a user logs on to a domain by using
a UPN.

UPN Logon and Global Catalog Interaction

1. Because the domain of the user is not necessarily the same as the UPN suffix, the domain
controller Locator contacts the nearest domain controller according to the site of the client
computer.

2. The contacted domain controller determines whether the DNS name in the UPN suffix is the
domain for which the domain controller is authoritative.
 • If the domain name in the UPN suffix matches the domain of the domain controller, the

domain controller attempts to process the client authentication. If the user name is not
found, the domain controller contacts a global catalog server.

• If the DNS name in the UPN suffix does not match the domain of the domain controller,

the domain controller contacts a global catalog server.

3. The global catalog server uses the userPrincipalName attribute of the user object to look up

the distinguished name of the user object, and returns this value to the domain controller.

4. The domain controller extracts the domain name from the distinguished name of the user and
returns this value to the client.

5. The client requests a domain controller for its domain.

If a forest trust exists between two forests, the default form of a UPN
(sAMAccountName@DnsDomainName) is used for authentication in a different forest. If you create a
forest trust and the second-level DNS domain name (for example, contoso.com) exists in both forests, the
New Trust Wizard detects the conflict and only one forest is authoritative for that name suffix.

If NTLM-based trust relationships are created between the domains in different forests—as is required for
a trust relationship between a domain in an Active Directory forest and a Windows NT 4.0 domain,
between domains in two Windows 2000 Server forests, or between a domain in a Windows 2000 Server
forest and a domain in a Windows Server 2003 forest—a UPN cannot be used to log on to a trusting
domain that is outside the forest because the UPN is resolved in the global catalog of only one forest.

Logon Process in a Single-Domain Forest

In a single-domain forest, all domain controllers can service all logon requests, including UPN logons,
without requiring a global catalog server. However, only domain controllers that are configured as global
catalog servers can respond to LDAP traffic over port 3268.

For more information about the logon process, see “Interactive Logon Technical Reference.” For more
information about forest trust relationships, see “Domain and Forest Trusts Technical Reference.”

Universal Group Membership Caching

In multidomain forests where remote sites do not have a global catalog server, the need to contact a
global catalog server over a potentially slow WAN connection can be problematic. On domain controllers
that are running Windows Server 2003 or later, the Universal Group Membership Caching feature is
available by default (does not require a specific functional level or domain mode), although it must be
enabled on a per-site basis.

When enabled, this feature allows a domain controller to cache global group SIDs and universal group
SIDs that it retrieves from a global catalog server so that future logons do not require contacting a global
catalog server. This storage is referred to as “caching,” but the memberships are actually stored in a non-
volatile AD DS value. The memberships that are written to this value are not lost as a result of a restart or
power outage. For the purposes of this discussion, the term “cache” refers to this value. Group
membership is cached for user accounts and computer accounts.

Caching group memberships in branch site locations has the following potential benefits:

• Faster logon times because authenticating domain controllers no longer need to contact a global

catalog server to obtain universal group membership.

• Higher availability because logon is still possible if the WAN link to the site of the global catalog

server is unavailable.
 • No need to upgrade the hardware of existing domain controllers to handle the extra system

requirements necessary for hosting the global catalog.

• Minimized network bandwidth usage because a branch site domain controller does not have to

replicate all of the objects located in the global catalog.

Enabling Universal Group Membership Caching

Universal Group Membership Caching can be enabled for a site by using the Active Directory Sites and
Services MMC snap-in to edit the properties of the NTDS Site Settings object (CN=NTDS Site
Settings,CN=TargetSiteName,CN=Sites,CN=Configuration,CN=ForestRootDomain). In Active Directory
Sites and Services, if you click a site object, the NTDS Site Settings object for the site is visible in the
details pane. Right-click the NTDS Site Settings object and then click Properties. In the NTDS Site
Settings Properties dialog box, click Enable Universal Group Membership Caching.

Note

The options attribute of the NTDS Site Settings object, which controls this feature, has a default value
of 0. When only the Universal Group Membership Caching option is enabled, the attribute value is 32.
However, this attribute is a bit field, so its full functionality is derived from computing a bitwise AND of
all of the bits that are set.
When the feature is enabled for a site, domain controllers in the site cache both universal group
membership and global group membership for first-time logons and keep the cache updated thereafter.
The feature allows specifying the site from which to retrieve group membership. In the NTDS Site
Settings Properties dialog box, you can use the Refresh cache from list to specify the site to use. The
msDS-Preferred-GC-Site attribute stores the distinguished name of the specified site and controls this
setting.

If no site is specified, the closest-site mechanism uses the cost setting on the site link to determine which
site has the least-cost connection to contact a global catalog server.

If the user has not logged on to the domain previously and a global catalog server is not available, the
user can log on to only the local computer.

Note

If a user is the Administrator in the domain (Builtin Administrator account), the user can always log on
to the domain, even when a global catalog server is not available.
For more information about closest-site mechanisms, see “How Active Directory Replication Topology
Works” and “How DNS Support for Active Directory Works.”

Global Group and Universal Group SID List

Although the feature is named Universal Group Membership Caching, in fact the domain controller caches
both universal group SIDs and global group SIDs. As described in “Universal Group SID Retrieval” earlier
in this subject, the authenticating domain controller retrieves the list of universal group SIDs from the
global catalog server. The domain controller sends the list of global group SIDs to the global catalog
server so that universal group membership can be ascertained for these groups as well as for the user or
computer account itself. Therefore, both global group SIDs and universal group SIDs are included in the
list of SIDs that is returned from the global catalog server. The domain controller caches the entire list of
SIDs. When the account attempts subsequent logons in the site, the universal group and global group
SIDs for the account are obtained from the cache. Domain local group SIDs are always obtained from the
local directory database.

After a security principal has logged on in a site that has Universal Group Membership Caching enabled,
the group cache for the account on the authenticating domain controller is immediately populated.
However, it can take up to eight hours for other domain controllers in the same site to populate the group
cache. During this time, if the account is authenticated by a domain controller that has not populated the
account’s cache, a global catalog server must be contacted for the logon to proceed. After eight hours, all
domain controllers that are running Windows Server 2003 or later in the site can process all subsequent
logons by using the cached membership.
Group Cache Communication Between Domain Controllers
Although the cache itself is not replicated between domain controllers, knowledge that an account has
logged on in the site is replicated to all other domain controllers in the domain by means of a site affinity
attribute (msDS-Site-Affinity) of the respective user or computer object. This multivalued attribute
identifies the sites in which the account has logged on and includes a timestamp for each site. The domain
controllers in the domain use the replicated site affinity attribute to determine which account
memberships are cached for their site, and then independently populate their copy of each account’s
cache by contacting a global catalog server. For more information about how the cache is populated, see
How the Cache is Populated at First Logon and How the Cache is Refreshed. For more information about
how this attribute is updated, see Group Cache Storagee.

Cache Refresh and the Availability of Group Changes

The caching of group SIDs in this way, including both universal group and global group SIDs, can lead to
unexpected behavior when an administrator modifies the universal group or global group membership for
an account and expects the change to be reflected on all domain controllers in the domain after the first
replication cycle following the change. Even if the change is made on the domain controller that
authenticates the account or has been received through replication, the membership in the cache is used
instead of the value of the object member attribute. By default, domain controllers update the
membership cache for accounts in the site every eight hours. As a result, changes to the global group or
universal group membership of an account can take up to eight hours to be reflected on domain
controllers in a site where Universal Group Membership Caching is enabled.

To refresh the cache, domain controllers running Windows Server 2003 or later send a universal group
membership confirmation request to a global catalog server. There is no limit to the number of accounts
that can be cached, but a maximum of 500 account caches can be updated during any cache refresh.

Note

Universal Group Membership Caching can be enabled in a site that has domain controllers that are
running Windows 2000 Server. If Universal Group Membership Caching is enabled in such a site, users
might experience inconsistent group membership, depending on which domain controller authenticates
them. For this reason, it is recommended that you either upgrade all domain controllers that are
running Windows 2000 Server to Windows Server 2003 or later when group caching is enabled in a site,
or remove them.
Because the group memberships are cached, there is a period of latency before group membership
changes are reflected in an account’s access token. When group membership changes, the changes are
not reflected in the access token until the following events have occurred (in order):

1. The changes are replicated to the global catalog server that is used for the refresh of the cache.

2. The cache on the domain controllers in the account’s site is refreshed. Although the cache refresh
is not a replication event, the process uses the site link schedule. Therefore, a closed site link
schedule postpones the cache refresh until the schedule opens.

3. The user has logged off and back on again (user account is authenticated) or the computer has
restarted (computer account is authenticated).

When an access token is created during logon, the token contents are static until that user logs off and
logs on again. Furthermore, as long as Universal Group Membership Caching is enabled, an account’s
memberships are cached, and the cache entry has not expired, the cache entry is used during logon. If
changes have been made to group membership and the refresh task has not run, the changes are not
reflected until either the cache entry expires or the refresh task runs and processes the cache entry.

The length of the latency period depends on when the next refresh task is scheduled to run. The refresh
task reschedules itself for its next refresh during each current refresh run, as follows:

• Beginning with the current time plus the registry-configured refresh interval, the domain

controller consults the replication schedule on the site link that connects its site to the site of the
closest (or designated) global catalog server.
 • If the site link schedule allows replication at the projected time, the refresh task is scheduled to

run at this time.

• If the site link schedule does not allow replication at the projected time, the scheduling algorithm

steps forward one minimum replication interval (15 minutes) and checks the schedule again.

• This process is repeated until an open replication interval is found. If no open interval is found in

the seven-day schedule, the refresh task is scheduled to run by using a time calculated as the
current time plus the registry-configured refresh interval. In this case, event ID 1671 is logged as
a warning message that indicates the group membership cache refresh task was unable to find
the next available time slot of connectivity to the site of the global catalog server.

If faster updates are required, an administrator can initiate a cache refresh manually on the domain
controllers in the user’s site. For more information about refreshing the user cache, see Registry Settings
that Affect Cache Refresh and Site Affinity Limits.

Determining the Site to Use for Populating and Refreshing the Cache
You can designate a site from which to initially populate and subsequently refresh the group membership
cache. The Universal Group Membership Caching feature user interface (UI) contains an option to select a
site from the list of existing sites. When a site has been selected and the cache on a domain controller
must be populated for the first time or updated, the domain controller contacts a global catalog server in
the designated site. If no site is designated, site link costs are evaluated to determine the lowest-cost site
that contains a global catalog server. The site link cost matrix is supplied by the Intersite Messenger (ISM)
service.

The UI that you use to designate a preferred site for cache refresh does not check for the presence of a
global catalog server in the selected site. Therefore, it is possible to designate a refresh site that does not
contain a global catalog server. In this case, or in any case where a refresh site is designated but a global
catalog server does not respond, the domain controller uses the site link cost matrix and logs event
ID 1668 in the Directory Service log in Event Viewer, which indicates that the group membership cache
refresh task did not locate a global catalog in the preferred site, but was able to find a global catalog in
the following available site. The event lists the named preferred site and the actual site that was used.

Group Cache Storage

Cached group membership is stored as additional attributes of user and computer objects. Three
attributeSchema objects in the AD DS schema for the user object class (and inherited by the computer
object class) support this feature:

• msDS-Cached-Membership: (cached membership) A binary large object (BLOB) that contains

both universal and global group memberships (the group SIDs) for the user. This attribute has
the following characteristics:

• Is single valued.

• Is not indexed.

• Can be deleted.

• Cannot be written.

• Is not replicated.
• msDS-Cached-Membership-Time-Stamp: (last refresh time) Contains the time that the

cached membership was last updated, either by the first logon or by a refresh. This attribute is
used for the “staleness” check. The maximum period that is tolerated when using a cached group
membership is called the staleness interval. The staleness interval, set in the registry as 7 days,
is measured against the current time and the last refresh time. If the timestamp indicates that
the cache is older than the staleness interval allows, the cached membership is invalidated and a
global catalog server is required for logon. This attribute has the following characteristics:

• Is large integer, time valued.

• Is indexed.

• Can be deleted.

• Cannot be written.

• Is not replicated.

• msDS-Site-Affinity: Identifies the site(s) where the account has logged on plus a timestamp

that indicates the start time for the cached logon in the respective site. Presence of a value in
this attribute causes automatic population of group memberships and refresh at every refresh
interval. When a domain controller refreshes its cached memberships (every 8 hours by default),
the timestamp is used for removing accounts from the cache that have not logged on within the
site affinity time limit (the cache expires). To avoid replication of this attribute every time the
account logs on, the timestamp is updated only when the age exceeds 50 percent of the age limit
that is set in the registry (180 days, by default) and one of the following actions occurs:

• The account logs on and is authenticated by a domain controller.

• A user changes his or her account password. This update ensures that users who go for

extended periods without logging on have their site affinity values updated.

This attribute has the following characteristics:

• Is multivalued.

• Is indexed.

• Can be deleted.

• Can be written.

• Is replicated.
 Note

You can use ADSI Edit in Windows Support Tools to clear the cached entries for an account by deleting
the values in msDS-Cached-Membership and msDS-Cached-Membership-Time-Stamp from the
user or computer object. The attribute values are repopulated at the next logon or cache refresh,
whichever comes first.
Registry Settings that Affect Cache Refresh and Site Affinity Limits
Registry settings on each domain controller determine the limits that are imposed on group membership
caches. The entries in the following table are under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\, unless
otherwise noted, and they can be used to manage the cache.

Changes to these registry settings take effect the next time the refresh task runs.

Note

In the following table, some of the entry names contain the string “(minutes)”. Note that this string is
part of the entry name and must be included when creating the entry. For example:

• The value name Cached Membership Refresh Interval (minutes) is correct.

• The value name Cached Membership Refresh Interval is incorrect.

Registry Entries Used to Configure Caching Behavior

Default
Registry Entry Type Value Notes

Cached Membership Site Stickiness (minutes) DWORD 172800 Defines how long
(Value is the site affinity
in will remain in
minutes. effect. The site
This affinity value is
setting updated when
equals half of the period
180 days) defined by this
value has
expired. If an
account has not
logged on with a
domain controller
for a period of
one half of this
value or longer,
the account is
removed from
the list of
accounts whose
memberships are
 being refreshed.
The default value
is recommended.

Cached Membership Staleness (minutes) DWORD 10080 Determines the

(Value is maximum
in staleness value
minutes. when using
This cached group
setting membership. The
equals 7 account cannot
days) log on if the
cached
membership list
is older than the
staleness value
and if no global
catalog server is
available. The
default value is
recommended.

Cached Membership Refresh Interval (minutes) DWORD 480 Defines the

(Value is length of time
in between group
minutes. membership
This cache refreshes.
setting This value should
equals 8 be changed to
hours) synchronize once
a day (1440
minutes). For
dial-up
connections, you
might want a
higher value than
24 hours.
Lowering the
value to increase
the frequency of
cache refresh is
not
recommended
because it causes
increased WAN
traffic, potentially
defeating the
purpose of
Universal Group
Membership
Caching.

Cached Membership Refresh Limit DWORD 500 Defines the

maximum
number of user
and computer
accounts that are
refreshed.
Increase this
setting only if
event ID 1669
occurs in the
event log or you
have more than
500 users and
computers in a
 branch. If the
number of users
and computers in
a branch exceeds
500, a general
recommendation
is to either place
a global catalog
server in the
branch or
increase the
Cached
Membership
Refresh Limit
above 500. Be
aware that
increasing the
limit might incur
more WAN traffic
than that caused
by global catalog
update traffic.

SamNoGcLogonEnforceKerberosIpCheck DWORD 0 By default, allows

This setting appears under site affinity to be
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro tracked for
l\Lsa. Kerberos logons
that originate
outside the site.
A value of 1
configures SAM
so it does not
give site affinity
to Kerberos
logon requests
that originate
outside the
current site. This
option should be
configured to 1
on domain
controllers in the
branch-sites to
prevent logon
requests from
outside the site
being given
affinity for the
local site. This
setting prevents
an account’s
affinity from
being changed
during the logon
process when
connecting to a
Kerberos key
distribution
center (KDC)
outside of the
account’s site.
This setting
applies only to
Kerberos logons;
it does not affect
 site affinity
caching for NTLM
logons from
different sites.

SamNoGcLogonEnforceNTLMCheck DWORD 0 A value of 1

This setting appears under configures SAM
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro to not give site
l\Lsa. affinity to NTLM
logon requests
that are network
logon requests; it
may not prevent
caching for other
logon types. This
setting reduces
the number of
accounts with
site affinity by
excluding those
that simply
accessed network
resources (by
using NTLM).
This option
should not be
enabled if you
use older clients
that must
authenticate
from outside the
branch to local
resources in the
branch.

Note

To minimize the probability that remote users will use the UGC-enabled branch domain controller for
logon, remove the domain controller for site-less SRV records from DNS by using the
DnsAvoidRegisterRecords parameter for Netlogon. For more information about using
DnsAvoidRegisterRecords, see Microsoft Knowledge Base article 306602
(http://go.microsoft.com/fwlink/?LinkId=126645).
Methods of Refreshing the Cached Memberships
You can refresh cached memberships on a single domain controller.

For a one-time, immediate cache refresh:

• Use Ldp.exe to modify the operational attribute updateCachedMemberships on the rootDSE

with a value of 1. Adding a value of 1 to this attribute instructs the local domain controller to
perform the update. If the site link schedule allows replication at the time you modify the
attribute, this update occurs right away. This method is the preferred method for updating a
single domain controller because it does not require restarting the domain controller. For
information about using Ldp to modify this attribute, see the Note below. Ldp.exe can be installed
from Windows Support Tools in Windows Server 2003 and Windows 2000 Server, and it is
installed by default on domain controllers that run Windows Server 2008 and Windows
Server 2008 R2.

-or-
 • Restart the domain controllers in the site to restart the cache refresh interval, which triggers a

cache refresh.

• Use the following procedure to modify the updateCachedMemberships operational attribute.

To perform this operation, the user needs the control access right "Refresh Group Cache for
Logons" on the NTDS Settings object for the domain controller. Default access is granted to
System, Domain Admins, and Enterprise Admins.

1. Start Ldp.exe and bind to the target domain controller where the cache reset is to be performed.

(Do not select Tree view in the View menu.) When first binding to a domain controller with Ldp,
the default location is rootDSE. You can view the attributes for rootDSE in the details pane.
However, operational attributes are not listed.

2. On the Browse menu, click Modify.

3. In the Modify dialog box, in the Edit Entry Attribute box, type updateCachedMemberships.

In the Values box, type 1. Be sure to leave the Dn box blank.

4. Click Enter. The command should appear in the entry list.

5. Click Run. If the operation was successful, Ldp will report “Modified” in the output.

Method of Clearing the Cached Memberships

You can clear all cached memberships on all domain controllers in a site. However, doing so can affect
performance. The need to clear the cached memberships might arise due to too many cached accounts,
causing inability to refresh all account caches during a single cache refresh. For example, sites that have
many transient accounts might exceed the 500-account refresh limit.

If you have more than 500 accounts cached and you want to clear them for all domain controllers in the
site, you can do so by editing the registry.

Note

If you must edit the registry, use extreme caution and be sure that you back it up first. Registry
information is provided here as a reference for use by only highly skilled directory service
administrators. Do not directly edit the registry unless, as in this case, no Group Policy setting or other
Windows tools can accomplish the task. Modifications to the registry are not validated by the registry
editor or by Windows before they are applied, and as a result, incorrect values can be stored. Storage
of incorrect values can result in unrecoverable errors in the system.
On one domain controller, you can set the Cached Membership Site Stickiness (minutes) registry
entry to 0 and then initiate a cache refresh by using the operational attribute method on that domain
controller, as described in “Methods of Refreshing the Cached Memberships” earlier in this subject. The
0 value in the setting causes the cache to be purged—values in all three attributes (msDS-Cached-
Membership, msDS-Cached-Membership-Time-Stamp, and msDS-Site-Affinity) are cleared. After
the site stickiness attribute deletion has replicated within the site, you can then initiate cache refresh on
the other domain controllers in the site. Remember to return the value in Membership Site Stickiness
(minutes) to its default value of 180.

Diagnostic Logging Levels and Events

Diagnostic logging for Universal Group Membership Caching can be set in the registry entry 20 Group
Caching under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
Data type: REG_DWORD

Value range: 0-5

Default value: 0

Significant events are reported at logging level 2 with many additional events reported at logging level 5.
For troubleshooting, set the logging level to 5.

Sample Events at Logging Level 0

Event ID 1667: The group membership cache refresh task detected that the following site in which a
global catalog was found is not one of the cheapest sites, as indicated by the published site link
information.

Event ID 1668: The group membership cache refresh task did not locate a global catalog server in the
preferred site, but was able to find a global catalog server in the following available site. Preferred site:
<site name> Available site: <site name>

Event ID 1669: The group membership cache refresh task has reached the maximum number of users for
the local domain controller.

Event ID 1670: The group membership cache refresh task is behind schedule. Consider forcing a group
membership cache update.

Sample Events at Logging Level 2

Event ID 1776 internal event: The group membership cache task is starting.

Event ID 1777 internal event: The group membership cache task has finished. The completion status was
0, and the exit Internal ID was ######.

Event ID 1779 internal event: The Global Catalog Domain Controller <dcname> in site <site name>,
domain <domain name> will be used to update the group memberships.

Event ID 1781 internal event: By examining the published connectivity information, the group
membership cache task has determined site <site name> is a site with a low network cost to contact. The
task will schedule itself based on the schedule of network connectivity to this site.

Event ID 1782 internal event: By examining the published connectivity information, the group
membership cache task cannot find an efficient site to obtain group membership information. The task will
run using the global catalog server that is closest, as determined by the Net Logon locator, and will
schedule itself based on a fixed period.

Event ID 1842 internal event: The following site link will be used to schedule the group membership cache
refresh task. Site link: <distinguished name of site link>

Sample Events at Logging Level 5

Event ID 1778 internal event: The group membership cache task will run again in xx minutes.

Event ID 1784 internal event: The group membership cache task determined that site <distinguished
name of site> does not have a global catalog server.

How the Cache is Populated at First Logon

By default, the caching attributes on the user and computer objects are not populated. The following
diagram shows how the domain controller builds the list of SIDs to be cached and where in the process
the caching attributes are populated during the user’s first logon in the site. This example assumes that
the user is in a site that has Universal Group Membership Caching enabled, the domain of the client
workstation is the same as the domain of the user, and the domain has a functional level that allows
universal groups.
Universal Group Membership Caching Process at First Logon

The following events occur at each step in the preceding diagram:

1. A user logs on in a site where Universal Group Membership Caching is enabled. The user is
authenticated by the domain controller as being the requesting user.

2. The domain controller checks the values of the three caching attributes of the user object.
 3. Finding that the attributes are not populated, the domain controller checks its local directory and
retrieves the SID of the user (including SID history, if available) and the SIDs of all global groups
to which the user belongs.

4. The domain controller sends this list of SIDs to the global catalog server. The global catalog
server checks the universal group memberships of the user and all global groups in the list. The
global catalog server returns the list of combined universal group and global group SIDs to the
domain controller.

5. The user’s cache attributes are populated as follows:

a. The combined list of global group and universal group SIDs is recorded in the msDS-

Cached-Membership attribute.

b. The time is recorded in the msDS-Cached-Membership-Time-Stamp attribute (this

time indicates the last time the cache was updated; on the first logon, it also happens to
be the time the user logged on).

c. If SamNoGcLogonEnforceNTLMCheck or

SamNoGcLogonEnforceKerberosIpCheck, or both, are enabled on the domain

controller, the msDS-Site-Affinity attribute is ignored.

d. If the GUID for the local site exists in the msDS-Site-Affinity attribute and the settings

in step c. are not enabled, the timestamp value in msDS-Site-Affinity is evaluated as

follows: If the value indicates an age that is less than half the value in Cached
Membership Site Stickiness (minutes), the logon proceeds. If the timestamp
indicates an age that is greater than half the value in Cached Membership Site
Stickiness (minutes), or if the attribute is not populated, the site GUID and time are
written to the msDS-Site-Affinity attribute, and the logon proceeds.

6. The domain controller checks its local directory for any domain local groups to which the user
belongs and adds domain local group SIDs to its list of global group and universal group SIDs.

Note

The process for accomplishing Step 6 differs depending on whether the domain of the client computer is
the same as the domain of the user and, if not, whether the client computer is joined to a domain that
has a mixed domain mode or functional level, or a native domain mode or functional level. For more
information about how SIDs are retrieved and added to access tokens, see “Access Tokens Technical
Reference.”
7. The domain controller sends the entire list of SIDs to the client computer, where the LSA
retrieves SIDs of the user’s built-in group memberships and constructs the user’s access token.

Note

Global catalog servers in a site where caching is enabled do not populate the msDS-Cached-
Membership and msDS-Cached-Membership-Time-Stamp attributes of users they authenticate.
Because global catalog servers are already aware of universal group memberships throughout the
forest and global group memberships for the domain, there is no need for them to use these attributes.
How the Cache is Used for Subsequent Logons
When Universal Group Membership Caching is enabled in the site, the following sequence occurs during
account logon:

1. The account is authenticated by the contacted domain controller.

2. The domain controller checks for the presence of values in the caching attributes of the
respective user or computer object. If the attribute values are present, the domain controller
updates the values as follows:

a. If the value in the msDS-Cached-Membership-Time-Stamp attribute indicates an

age that is less than the staleness interval (Cached Membership Staleness
(minutes), default seven days), the domain controller reads the group SIDs from the
msDS-Cached-Membership attribute and the logon proceeds.

b. If the value in msDS-Cached-Membership-Time-Stamp indicates an age of greater

than the staleness interval, the domain controller contacts a global catalog server to
request the universal group membership. If a global catalog server cannot be contacted,
the logon is denied.

c. If the value in the timestamp in msDS-Site-Affinity is equal to or older than

50 percent of the site stickiness setting, the timestamp is updated with the current time.

3. The domain controller returns the group SIDs from the cache plus any domain local group SIDs
to the client computer and the logon proceeds.

Note

At no time during a successful logon does the local domain controller check with a global catalog server
to see if the account’s group membership has changed. Changes to an account’s group membership are
not reflected in the account’s access token until the local domain controller performs a cache refresh.
The default amount of time between cache refreshes is eight hours. This interval could result in an
inconsistent view of group membership if the account was authenticated by a domain controller in a
different site. This discrepancy might also confuse administrators who are unfamiliar with how universal
group membership caching works.
How the Cache is Refreshed
The cache refresh process occurs automatically on every domain controller that is running
Windows Server 2003 or later and has received replication of the msDS-Site-Affinity attribute update for
a user or computer object or has already cached group memberships. The refresh operation occurs
differently depending on whether a site is selected for the preferred refresh site.

Cache Refresh Process When a Preferred Refresh Site is Not Selected

When the refresh interval expires, the domain controller proceeds as follows:

1. Lists all the site links that connect the domain controller’s site to a site that hosts a global catalog
server in increasing order of cost values on the site link objects.
2. Selects the lowest-cost site link and schedules the refresh by using the site link schedule. If no
site link schedule is set, then replication is always available. Depending on the schedule, the
refresh proceeds as follows:

• If the schedule currently allows replication, the domain controller begins the refresh.

• If the schedule does not currently allow replication, the domain controller schedules the

refresh to begin when the schedule allows replication.

Note

When the refresh is postponed according to the site link schedule, a random stagger in the range of 0-
15 minutes is added to the computed start time. Schedule staggering has the effect of ensuring that
domain controllers begin their refresh at slightly different times, thereby improving load balancing on
the global catalog server.

• When the schedule allows replication, begins the refresh by locating and binding to a

global catalog server in the next closest site.

• Removes accounts that have a populated cache but no site affinity. Cached entries that

do not include a populated msDS-Site-Affinity value are purged at this time. A

maximum of 64 entries are removed at a time. If more entries need to be removed,
they are removed during subsequent refreshes.

• Removes any account whose site affinity matches the local site, but whose site affinity

time period has expired. In this case, the values in the three cache attributes are
deleted and this account no longer has a group membership cache on the domain
controller.

• Builds a list of accounts by querying the global catalog for all accounts that have GUIDs

in their msDS-Site-Affinity attribute that match the GUID of the domain controller’s
site.

• Updates cache attributes of the accounts in the list by querying the global catalog for

each account’s group membership, as follows:

• Update the msDS-Cached-Membership attribute with the account’s group

membership SIDs.

• Update the msDS-Cached-Membership-Time-Stamp attribute with the time

of refresh.

• Repeats the process for each account until all accounts are updated or until the refresh

limit of 500 accounts is reached. If the refresh limit is reached, the domain controller
logs event ID 1669 in the Directory Service event log, and the refresh stops.

• Checks to ensure that the refresh task has not fallen behind in terms of the maximum

period allowed for an account’s cached membership list to be valid for logons. This step
 is accomplished by locating the record with the oldest msDS-Cached-Membership-
Time-Stamp value and comparing the timestamp value to the staleness interval (seven
days by default). If the entry is more than seven days old, the domain controller logs
event ID 1670, indicating that the refresh task has fallen behind.

Note

When the domain controller encounters the refresh limit, it stops updating cache entries. Because the
order in which the updates occur cannot be predicted, there is no way to ensure that the caches of the
most recent accounts are updated. The staleness check in step 9 checks all cached entries, even those
excluded due to exceeding the refresh limit. After about one week, the non-updated cache entries will
become stale and cause the falling behind error to be reported in the event log.

• Note

• When the domain controller encounters the refresh limit, it stops updating

cache entries. Because the order in which the updates occur cannot be predicted,
there is no way to ensure that the caches of the most recent accounts are updated.
The staleness check in step 9 checks all cached entries, even those excluded due to
exceeding the refresh limit. After about one week, the non-updated cache entries will
become stale and cause the falling behind error to be reported in the event log.

Cache Refresh Process When A Preferred Refresh Site is Selected

When a site is selected to always be used for refreshing the group membership cache, the domain
controller does not need to order the site links according to cost, but simply contacts a global catalog
server in the specified site. However, if no global catalog server is available at the time the refresh is
attempted, the domain controller logs event ID 1782, indicating that a domain controller could not be
found in the preferred site, and uses the site link cost to locate a global catalog server in the next closest
site.

Inconsistent Access to Domain-Based Objects on Global Catalog Servers

When specifying Read or List permissions for domain data that is also replicated to the global catalog, use
global groups rather than domain local groups because the access token that is created for the user by the
global catalog server does not necessarily contain information about domain local groups to which the
user belongs.

When a user connects to a global catalog server, an access token is created for the user that is used in
subsequent access decisions on the server. If the user is a member of a domain other than the domain of
the global catalog server, the global catalog server contacts a domain controller in the user’s domain to
authenticate the user and retrieve authorization data. The domain controller returns information about the
user, including the SIDs of global groups in the user’s domain to which the user belongs. The domain
controller from the user's domain does not return domain local group SIDs to the global catalog server.

Universal group membership is retrieved from the global catalog, and the global catalog server looks to its
own domain (which is not necessarily the domain of the user) for any domain local groups to which the
user belongs. Thus the access token for the user on the global catalog server contains the global groups
and universal groups to which the user belongs, as well as any domain local groups to which the user
belongs in the domain of the global catalog server.

The effect of a missing domain local group SID in the user’s access token is that the user’s access to
global catalog data is unpredictable. For example, if access to the homePhone attribute of a user object
is restricted by a domain local group in the user's domain, and the user is a member of that group, the
user is able to view that attribute in the global catalog when both of the following conditions are true:

• The homePhone attribute is replicated to the global catalog.

 • The global catalog server to which the user connects does not host a writable copy of the user’s

domain.

Similarly, if the user is a member of a domain local group in a domain other than the domain hosted by
the global catalog server, and that group is granted read access to the homePhone attribute, the user
cannot view that attribute in the global catalog.

Global Catalog Searches

The location of an object in AD DS is provided by the distinguished name of the object, which includes the
full path to a replica of the object, culminating in the directory partition that holds the object. However,
the user or application does not always have the distinguished name of the target object, or even the
domain of the object. To locate objects without knowing the domain, the most commonly used attributes
of the object are replicated to the global catalog. By using these object attributes and directing the search
to the global catalog, requesters can find objects of interest without having to know their directory
location. For example, to locate a printer, you can search according to the building of the printer. To
locate a person, you can provide the name of the person. To locate all people who are managed by
someone, you can provide the manager’s name.

LDAP Search Ports

AD DS uses the Lightweight Directory Access Protocol (LDAP) as its access protocol. LDAP search requests
can be sent and received by AD DS on port 389 (the default LDAP access port) and port 3268 (the default
global catalog port). LDAP traffic that uses the Secure Sockets Layer (SSL) authentication protocol
accesses ports 686 and 3269, respectively. In this discussion, search behavior that applies to ports 389
and 3268 also apply to the respective behavior of LDAP queries over ports 686 and 3269.

When a search request is sent to port 389, the search is conducted on a single domain directory partition.
If the object is not found in that domain or the schema or configuration directory partitions, the domain
controller refers the request to a domain controller in the domain that is indicated in the distinguished
name of the object.

When a search request is sent to port 3268, the search includes all directory partitions in the forest — that
is, the search is processed by a global catalog server. If the request specifies attributes that are part of
the PAS, the global catalog can return results for objects in any domain without generating a referral to a
domain controller in a different domain. Only global catalog servers receive LDAP requests through
port 3268. Certain LDAP client applications are programmed to use port 3268. Even if the data that
satisfies a search request is available on a regular domain controller, if the application launching the
search uses port 3268, the search necessarily goes to a global catalog server.

Search Criteria That Target the Global Catalog

Searches are directed to a global catalog server under the following conditions:

• You specify port 3268 or 3269 in an LDAP search tool.

• You select Entire Directory in a search-scope list in an AD DS snap-in or search tool, such as

Active Directory Users and Computers or the Search command on the Start menu.

• You write the distinguished name as an attribute value, where the distinguished name represents

a nonlocal object. For example, if you are adding a member to a group and the member that you
are adding is from a different domain, a global catalog server verifies that the user object
represented by the distinguished name exists and obtains its GUID.

Characteristics of a Global Catalog Search

The following characteristics differentiate a global catalog search from a standard LDAP search:

• Global catalog queries are directed to port 3268, which explicitly indicates that global catalog

semantics are required. By default, ordinary LDAP searches are received through port 389. If you
bind to port 389, even if you bind to a global catalog server, your search includes a single domain
 directory partition. If you bind to port 3268, your search includes all directory partitions in the
forest. If the server you attempt to bind to over port 3268 is not a global catalog server, the
server refuses the bind.

• Global catalog searches can specify a non-instantiated search base, indicated as "com" or " "

(blank search base).

• Global catalog searches cross directory partition boundaries. The extent of the standard LDAP

search is the directory partition.

• Global catalog searches do not return subordinate referrals. If you use port 3268 to request an

attribute that is not in the global catalog, you do not receive a referral to it. Subordinate referrals
are an LDAP response; when you query over port 3268, you receive global catalog responses,
which are based solely on the contents of the global catalog. If you query the same server by
using port 389, you receive referrals for objects that are in the forest but whose attributes are
not referenced in the global catalog.

Note

A referral to a directory that is external to AD DS can be returned by the global catalog if a base-level
search for an external directory is submitted and if the distinguished name of the external directory
uses the domain component (dc=) naming attribute. This referral is returned according to the ability of
AD DS to construct a Domain Name System (DNS) name from the domain components of the
distinguished name and is not based on the presence of any cross-reference object. The same referral
is returned by using the LDAP port; it is not specific to the global catalog.
Because the member attribute is not replicated to the global catalog for all group types, and because the
memberOf attribute derives its value by referencing the member attribute (called back links and forward
links, respectively), the results of searches for members of groups and groups of which a member belongs
can vary, depending on whether you search the global catalog (port 3268) or the domain (port 389), the
kind of groups that the user belongs to (global groups or domain local groups), and whether the user
belongs to universal groups outside the local domain.

For more information about global catalog searches and the implications of searching on back links and
forward links, see “How Active Directory Searches Work.”

The Infrastructure Master and Phantom Records

An attribute that has a distinguished name as a value references (points to) the named object. When the
referenced object does not actually exist in the local directory database because it is in a different domain,
a placeholder record called a phantom is created in that database as the object reference. Because there
is a reference to it, the referenced object must exist in some form, either as the full object (if the domain
controller stores the respective domain directory partition) or as an object reference (when the domain
controller does not store that domain).

The infrastructure master is a single domain controller in each domain that tracks name changes of
referenced objects and updates the references on the referencing object. When a referenced object is
moved to a different domain (which effectively renames the object), the infrastructure master updates the
distinguished name of the phantom. The infrastructure master finds phantom records by using a database
index that is created only on domain controllers that hold the infrastructure operations master role. When
the reference count of the phantom falls to zero (no objects are referencing the object that the phantom
represents), garbage collection on each domain controller removes the phantom.

Because objects can reference objects in different domains, the infrastructure operations master role is
not compatible with global catalog server status if more than one domain is in the forest. If a global
catalog server holds the infrastructure operations master role, phantom records are never created
because the referenced object is always located in the directory database on the global catalog server.
For more information about the infrastructure operations master role, see “How Operations Masters
Work.”

Exchange Address Book Lookups

The Exchange Server directory service is integrated with AD DS. When mail users want to find a person
within their organization, they usually search the global address book (GAL), which is an aggregation of all
messaging recipients in the enterprise, including mailbox-enabled users, mail-enabled users, groups, and
contacts. The GAL is a virtual linked list of pointers to the mail recipient objects that comprise it. Mail
recipients can be user accounts (both enabled and disabled accounts), contacts, distribution lists, security
groups, and folders. The GAL is automatically populated by a service on the Exchange Server, and user’s
can create customized address lists. Exchange Server uses the global catalog to generate the GAL.

Every Outlook client is configured with the name of an Exchange server. Exchange servers use AD DS and
DNS to locate a global catalog server. When an Outlook client user opens the Address Book, or when a
user composes a message and types a name or an address in the To: field, the Outlook client uses the
global catalog server that is specified by its Exchange server to search the contents of the GAL or other
address lists.

For more information about how Outlook clients locate address information in the global catalog, see “How
Active Directory Searches Work.”

Global Catalog Server Creation and Advertisement

You can designate a domain controller as a global catalog server by simply selecting the Global catalog
check box in the properties of the NTDS Settings object, located beneath each server object in
Active Directory Sites and Services. On servers that run Windows Server 2008 R2 or Windows
Server 2008, you can also designate a domain controller as a global catalog server during AD DS
installation. However, for search clients and other domain controllers in the forest to locate it, the global
catalog server must register itself in DNS.

The Net Logon service on a domain controller registers service (SRV) resource records in DNS that identify
the domain controller so that it can be located. In the case of a global catalog server, additional SRV
resource records are registered to identify the server as a global catalog server. These SRV resource
records contain the server name, the forest name, and the site name for the global catalog server. DNS
queries for these records return all global catalog servers in the requested site. When a client requests a
global catalog server by launching an LDAP search over port 3268, the domain controller Locator on the
client queries DNS for a domain controller that hosts the global catalog. For more information about how
domain controllers and global catalog servers are located, see “How DNS Support for Active Directory
Works.”

By default, before a domain controller advertises itself as a global catalog server in DNS, the global
catalog contents must be replicated to the server. This process involves replication of a partial, read-only
replica of every domain in the forest except for the domain for which the new global catalog server is
authoritative. The duration of this process depends on how many domains the forest contains, the size of
the domains, and the relative locations of source and destination domain controllers. If multiple domains
are in the forest and if source domain controllers are located only in distant sites, the process takes longer
than if all domains are in the same site or in only a few sites. When replication must occur between sites
to create the global catalog, replication occurs according to the site link schedule.

When creating a new global catalog server, the process can be delayed by several conditions, including
the following:

• The KCC could not reach a source domain controller from which to replicate a directory partition.

• Replication cannot begin until the scheduled time.

• Replication of the directory partition is in progress but has not yet completed. This delay might

occur if the directory partition is very large. In addition, the replication priority queue prioritizes
addition of new directory partitions at a lower priority than incremental replication of existing
partitions.
 • The source domain controller for a directory partition has gone offline or is unavailable due to

network problems.

These conditions are logged in the Directory Service log when the logging level is set to 0 (the default
setting) in the Global Catalog entry under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\. If you want
to receive more information, you can increase the logging level by editing this entry.

Warning

If you must edit the registry, use extreme caution and be sure that you back it up first. Registry
information is provided here as a reference for use by only highly skilled directory service
administrators. Do not directly edit the registry unless, as in this case, no Group Policy setting or other
Windows tools can accomplish the task. Modifications to the registry are not validated by the registry
editor or by Windows before they are applied, and as a result, incorrect values can be stored. Storage
of incorrect values can result in unrecoverable errors in the system.
Requirements for Global Catalog Readiness
By default, a global catalog server is not considered “ready” (the server advertises itself in DNS as a
global catalog server) until all read-only directory partitions have been fully replicated to the new global
catalog server. The Global Catalog Partition Occupancy registry entry under
HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters determines the
requirements for how many read-only directory partitions must be present on a domain controller for it to
be considered a global catalog server, from no partitions (0) to all partitions (6).

For domain controllers that run Windows Server 2003 or later, the default occupancy value requires that
all read-only directory partitions be replicated to the global catalog server before the Net Logon service
registers SRV resource records in DNS. For most conditions, this default provides the best option for
ensuring that a global catalog server provides a consistent view of the directory. In less common
circumstances, however, it might be useful to make the global catalog server available with an incomplete
set of partial domain directory partitions—for example, when delay of replication of a domain that is not
required by users is jeopardizing their ability to log on.

The Global Catalog Partition Occupancy entry can have the values shown in the following table.

Global Catalog Partition Occupancy Level Values

Value Description

0 No occupancy requirement. Removing the occupancy level requirement might be useful in a

scenario where domain controllers are being staged for deployment but are not yet in
production.

1 At least one read-only directory partition in the site has been added by the KCC. This level, as
well as level 3 and level 5, provide the ability to distinguish between a source for the directory
partition being reachable (at least one object has been returned) and the entire directory
partition having been replicated (as in levels 2, 4, and 6).
When the KCC can reach the first object, it can create a replica link, which is the agreement
between the source and destination domain controllers to replicate to the destination. If the KCC
cannot reach a source, the KCC logs event ID 1558 in the Directory Service log, which indicates
the distinguished name of the directory partition that has not been fully synchronized. In this
case, the KCC continues to try to replicate the partition each time it runs (every 15 minutes by
default).
When the KCC succeeds in creating the replica link, it passes responsibility for retrying and
completing the synchronization to the replication engine. The KCC then stops logging events,
after which the replication status can be checked by using the repadmin/showrepl command.

2 At least one read-only directory partition in the site has been fully synchronized.

3 All read-only directory partitions in the site have been added by the KCC (at least one has been
fully synchronized). In this case, the KCC has been able to contact one source for every
 directory partition in the site. This level is useful when you want to advertise a global catalog
server as soon as possible with a high likelihood of success.

4 All read-only directory partitions in the site have been fully synchronized. With this setting, if a
source for any directory partition is not available, DNS registrations cannot occur. On domain
controllers that are running Windows 2000 Server with Service Pack 1 (SP1) or Windows 2000
Server with Service Pack 2 (SP2), this occupancy level is the default requirement before the
global catalog server is advertised in DNS.

5 All read-only directory partitions in the forest have been added by the KCC (at least one has
been fully synchronized).

6 All read-only directory partitions in the forest have been fully synchronized. On domain
controllers that are running Windows Server 2003 or Windows 2000 Server with SP3 or later,
this occupancy level is the default requirement before the global catalog server is advertised in
DNS. This setting ensures the highest level of consistency.
Event ID 1578 reports the level that is required and the level that the domain controller has achieved.

Advertising a Global Catalog Server Prior to Full Synchronization

By default, a domain controller checks every 30 minutes to see whether it has received all of the read-only
directory partitions that are required to be present before the server advertises itself in DNS as a global
catalog server. Event ID 1110 indicates that the promotion is being delayed because the required
directory partitions have not all been synchronized.

This delay is controlled by the Global Catalog Delay Advertisement (sec) registry entry under
HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters\. If you set a
value for Global Catalog Delay Advertisement (sec), it overrides the requirements set in Global
Catalog Partition Occupancy and allows global catalog advertisement without requiring full
synchronization of all read-only directory partitions.

When conditions preclude the successful synchronization of the new global catalog server, you can force
advertisement of the global catalog server and then remove the global catalog from the server. Until the
global catalog server is successfully advertised, you are unable to remove it.

Replication Process for Global Catalog Creation

When you designate a domain controller to be a global catalog server, the Knowledge Consistency
Checker (KCC) on the domain controller runs immediately and updates the replication topology. When the
KCC runs, it checks to see whether the Global Catalog option is selected for any domain controllers, and
creates the replication topology accordingly. The KCC configures the newly selected global catalog server
to be the destination server for a read-only replica of every domain directory partition in the forest except
for the writable domain directory partition that the server already holds. The KCC on the global catalog
server must be able to reach a server that will be the source of each read-only directory partition.

When the KCC locates an available source domain controller, it creates an inbound connection on the new
global catalog server and replication of that read-only partition takes place. If the source is within the site,
replication begins immediately. If the source is in a different site, replication begins when it is next
scheduled. Replication of all objects in the partial directory partition must complete successfully before the
directory partition is considered to be present on the global catalog server.

Successful Completion of Global Catalog Creation

When all directory partitions are present, the domain controller sets its rootDSE isGlobalCatalogReady
attribute to TRUE and the Net Logon service on the domain controller registers SRV resource records that
specifically advertise the global catalog server in DNS. At this point, the global catalog is considered to be
available, and event ID 1119 is logged in the Directory Service log.

Global Catalog Replication

Although read-only directory partitions on global catalog servers cannot be updated directly by
administrative LDAP writes, they are updated through AD DS replication when changes occur to their
respective writable replicas.

The following diagram represents the AD DS database on a global catalog server in the corp.contoso.com
forest root domain. A global catalog server has a single directory database. However, to represent the
different logical directory partitions in the forest, the diagram shows database divided into segments. The
top three segments represent directory partitions that are writable replicas for the domain controller (the
domain, configuration, and schema directory partitions). The bottom three segments represent directory
partitions that are read-only replicas of the other domains in the forest.

Writable and read-only replicas in the AD DS database on a global catalog server

The source domain controller for replication of a given directory partition to a global catalog server can be
either a non-global catalog domain controller or another global catalog server. In the following diagram,
each directory partition on the global catalog server is being updated by a non-global catalog domain
controller. The writable replicas on the global catalog server are updated by a domain controller that is
authoritative for the same domain, Corp.contoso.com. The replication for the Corp.contoso.com domain
and the configuration and schema directory partitions is two-way because the replicas are all writable.

Each of the read-only replicas is updated by a source domain controller that is authoritative for the
respective directory partition. The replication is one-way because read-only replicas never update writable
replicas.

Direction of directory partition replica updates between a global catalog server and other
domain controllers

Replication Between Global Catalog Servers

As is true for all domain controllers, a global catalog server uses a single topology to replicate the schema
and configuration directory partitions, and it uses a separate topology, if needed, for each domain
directory partition. However, when a two-way connection exists between the servers, either for replication
of the schema and configuration directory partitions or for replication in opposite directions of the two
writable domain directory partitions, all replicas on each global catalog server use the same connection to
update their common replicas when changes are available.

The diagram below shows the directions of replication between directory partitions on two global catalog
servers that are in different sites and are authoritative for different domains. The writable replicas of
soam.corp.contoso.com and corp.contoso.com update the respective read-only replicas in one direction
only (a writable replica is never updated by a read-only replica). Because neither domain controller is
authoritative for the noam.corp.contoso.com and eur.corp.contoso.com domain replicas, the global catalog
servers can be sources for replication of these partial read-only replicas. This replication is shown as two-
way because a two-way connection already exists and these replicas are each capable of updating the
other.

Direction of directory partition replica updates between two global catalog servers in different
domains

In the preceding diagram, the read-only replicas can also be updated from other domain controllers.
Unless the forest functional level is Windows 2000 Server, the intersite KCC algorithm avoids creating
redundant connection objects by implementing one-way replication where possible. For example, if the
schema and configuration writable replicas and the Corp and Eur read-only domain replicas on GC1 are all
updated by a domain controller other than GC2, replication of the Corp and Eur read-only replicas from
GC1 to GC2 occurs in one direction if it occurs. In this case, GC1 might not generate a connection object
for replication from GC2.

Global Catalog Replication of Additions to the Partial Attribute Set

Each global catalog server in an AD DS forest hosts a copy of every existing object in that forest. For the
objects of its own domain, a global catalog server has information related to all attributes that are
associated with those objects. For the objects in domains other than its own, a global catalog server has
only information that is related to the set of attributes that are marked in the AD DS schema to be
included in the partial attribute set (PAS). As described earlier, the PAS is defined by Microsoft as those
attributes that are most likely to be used for searches. These attributes are replicated to every global
catalog server in an AD DS forest.

If you want to add an attribute to the PAS, you can mark the attribute by using the Active Directory
Schema snap-in to edit the isMemberOfPartialAttributeSet value on the respective attributeSchema
object. You mark the attribute by placing a checkmark next to isMemberOfPartialAttributeSet. If the
isMemberOfPartialAttributeSet value is checked (set to TRUE), the attribute is replicated to the global
catalog. If the value is not checked (set to FALSE), the attribute is not replicated to the global catalog.

When the PAS is updated on the domain controller that has the schema operations master role, the
writable schema directory partition replicates normally to all domain controllers. When a global catalog
server attempts to update its read-only directory partition from a source replication partner whose schema
has been udpated with the PAS change, the destination global catalog server receives the information that
the PAS has been updated.

Depending on the version of Windows that is running on the replication partners, a global catalog server
responds to an update to the PAS either by initiating replication of all attributes in the read-only directory
partitions in the global catalog (full synchronization), or only the attributes that were added to the PAS
(updates only), as follows:

• Updates only—both replication partners are running Windows Server 2003 or later: Only

the added attributes are replicated and there is no replication impact. In this case, when the
isMemberOfPartialAttributeSet value of a new attributeSchema object in the schema
directory partition is set to TRUE and this change is either made on a global catalog server or
replicated in by a global catalog server, the global catalog server records unique NTDS
 Replication informational events in the Directory Service log for each read-only directory partition
that it hosts, as follows:

• Event ID 1704, stating that in response to addition of one or more attributes to the PAS,

the global catalog server has initiated replication of the PAS for the specified directory
partition from the specified domain controller.

• Event ID 1702, stating that synchronization of the PAS has completed successfully.

• Full synchronization—both replication partners are running Windows 2000 Server: The

global catalog server initiates replication of all PAS attributes of all objects in all read-only domain
directory partitions. In this case, all replication partner metadata and up-to-dateness metadata
for the directory partition is discarded and the global catalog server builds a new list of replication
partners and up-to-dateness information relative to those partners. Building its partner
information anew, it requests replication of all attributes, filtering out any attribute that is not
marked for inclusion in the PAS. If the attributes can be replicated over an RPC connection, the
domain controller attempts a full replication over the RPC connection before it uses a configured
SMTP connection. If full replication is completed, the up-to-dateness vector that is created
ensures that later replication requests on other connections do not include data that has been
received during the initial full replication.

Full replication of all attributes in the PAS to bring all global catalog servers up-to-date causes
increased network traffic while it is in progress and can take from several minutes to hours,
depending on the size of the directory. Although interruption of service does not occur, this
replication causes higher bandwidth consumption than is required for usual day-to-day
replication. The resulting bandwidth consumption for each global catalog server is equivalent to
that caused by assigning the global catalog role to a domain controller.

In this case, when the isMemberOfPartialAttributeSet value of an additional

attributeSchema object in the schema directory partition is set to TRUE and this change is
either made on a global catalog server or replicated in by a global catalog server, a unique NTDS
Replication informational event ID 1575 is recorded in the Directory Service log for each read-
only directory partition that is hosted by the global catalog server. Event ID 1575 states that one
or more new attributes has been added to the PAS for the specified directory partition and that
full synchronization of all objects and all attributes in the specified directory partition will be
performed from the source domain controller on the next replication cycle.

• Full synchronization—a global catalog server that is running Windows Server 2003 or

later sources replication of a partial, read-only directory partition from a global catalog
server or domain controller that is running Windows 2000 Server: The global catalog
server that is running Windows Server 2003 or later reverts to Windows 2000 Server behavior
and, as described above, initiates full replication of all objects and their attributes in all read-only
directory partitions. For each read-only directory partition that it hosts, the global catalog server
that is running Windows Server 2003 or alter records unique NTDS Replication informational
events in the Directory Service log, as follows:
 • Event ID 1575, stating that full synchronization of the PAS will be initiated on the next

replication cycle.

• Event ID 1703, stating that synchronization of the PAS has been initiated.

• Event ID 1702, stating that synchronization of the PAS has completed successfully.

Note

The AD DS schema in Windows Server 2003 and later contains attributes that are marked for inclusion
in the PAS as soon as the forest functional level is raised to Windows Server 2003 or higher. Replication
of the additions to the PAS to global catalog servers is triggered by raising the forest functional level to
Windows Server 2003 or higher. Therefore, upgrading the schema has no impact on Windows 2000–
based global catalog servers because the global catalog is updated only when all domain controllers are
running Windows Server 2003 or later (the requirement for raising the forest functional level to at least
Windows Server 2003). For more information about functional levels, see “How Active Directory
Functional Levels Work.”
For more information about replication metadata, including up-to-dateness vector, see “How the Active
Directory Replication Model Works.”

Global Catalog Response to Deletions from the Partial Attribute Set

Removing an attribute from the PAS does not involve replication of a deletion, but is handled locally. If
you set the isMemberOfPartialAttributeSet value to FALSE in the schema, the attribute is removed
from the directory of each global catalog server immediately after receiving the schema update. This
behavior is the same on global catalog servers running any version of Windows Server.

Removing the Global Catalog from a Domain Controller

When you add the global catalog to a domain controller, a partial replica of each domain directory
partition, other than the domain for which the domain controller is authoritative, is copied to the domain
controller as described in Replication Process for Global Catalog Creation. This replication occurs
immediately within a site or at the next scheduled replication between sites. However, when you remove
the global catalog from a domain controller, the KCC begins removing the read-only replicas one at a time
by means of an asynchronous process that removes objects gradually over time until no read-only objects
remain.

The Windows 2000 KCC removes approximately 500 objects per attempt. Each time the KCC runs (every
15 minutes by default), it attempts the removal of the read-only replica until there are no remaining
objects. At an estimated 2000 objects per hour, complete removal of the global catalog from the domain
controller can take from several hours to days, depending on the size of the directory.

The KCC in Windows Server 2003 or later initially instructs the directory to remove each replica, but once
the instruction is received, the directory itself keeps track of the progress of replica removal and
reschedules the work accordingly. Rather than removing a fixed number of objects per removal attempt,
AD DS continues removing objects until either the replica is gone or a higher priority replication operation
is in the queue. Read-only replica removal receives the lowest possible priority, meaning that any other
replication work will interrupt it. Thus, removal work is pre-empted for the other work and then resumed
later. On domain controllers running Windows Server 2003 or later, event log messages record when
removal of a partial replica is starting, being resumed, and finishing.

KCC events that are logged in the Directory Service log during global catalog removal include:

• Event ID 1744: Local domain controller is no longer a global catalog server.

• Event ID 1659: Removal of a directory partition from the local database has been resumed,

including the approximate number of objects remaining to be removed and number of link values
of attributes remaining to be removed.
 • Event ID 1660: A specified directory partition has been removed from the local domain controller.

For a normally-to-lightly loaded system, read-only replica removal occurs as fast as possible in the
background. On a server that is very busy with replication (for example, a hub domain controller),
estimating the time required for global catalog removal is difficult.

As soon as you set the domain controller to not be a global catalog server by clearing the Global Catalog
check box on the NTDS Settings object properties page, Net Logon deregisters the SRV resource records
that specifically advertise the global catalog server in DNS. Therefore, although the read-only domain
replicas might take hours or days to remove, the domain controller immediately stops advertising itself as
a global catalog server in DNS and immediately stops accepting LDAP requests over port 3268.

Note

On a domain controller running Windows 2000 Server, if you check the Global Catalog box again
before a partial replica has been completely removed, the KCC begins the process of replicating in the
read-only replicas as follows: If a given replica is completely gone, the KCC adds the replica back. If the
replica is still in the process of being removed, the KCC does not add it again until the initial removal is
complete. Thus, during the removal period, there can conceivably be a mix of new replicas from the
most recent global catalog instance, and some old replicas in the process of being removed from the
previous instance. This condition is temporary and of no consequence to users because the domain
controller is not being advertised as a global catalog server.

Network Ports Used by the Global Catalog

The following ports are used by global catalog servers:

Port Assignments for Global Catalog Servers

Service Name UDP TCP

LDAP 3268 (global catalog)

LDAP 3269 (global catalog Secure Sockets Layer [SSL])

LDAP 389 389

LDAP 636 (SSL)

RPC/REPL 135 (endpoint mapper)

Kerberos 88 88

DNS 53 53
SMB over IP 445 445

C. Global Catalog Tools and Settings

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows
Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

In this section

• 1.Global Catalog Tools

• 2.Global Catalog Registry Entries

• 3.Global Catalog Group Policy Settings

• 4.Network Ports Used by Global Catalog Servers

Global Catalog Tools

Tools that are associated with a global catalog server are the same tools that you use to manage any
domain controller.

The following tools have commands that are specific to managing global catalog servers.
Adsiedit.msc: ADSI Edit

Category
A Microsoft Management Console (MMC) snap-in that is available in Windows Support Tools in
Windows Server® 2003 and Microsoft Windows® 2000 Server. It is built into Windows Server 2008 R2
and Windows Server 2008 and available if you have the Active Directory® Domain Services (AD DS) or
the Active Directory Lightweight Directory Services (AD LDS) server role installed. It is also available if
you install the Active Directory Domain Services Tools that are part of the Remote Server Administration
Tools (RSAT). For more information, see How to Administer Microsoft Windows Client and Server
Computers Locally and Remotely (http://go.microsoft.com/fwlink/?LinkID=177813).

Note

In Windows Server 2003 and Windows 2000 Server, the directory service is named Active Directory. In
Windows Server 2008 R2 and Windows Server 2008, the directory service is named Active Directory
Domain Services. The rest of this topic refers to AD DS, but the information is also applicable to
Active Directory.

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2008 R2 • Windows Server 2008 R2

• Windows Server 2008 • Windows Server 2008

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard

Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003,

• Windows Server 2003, Datacenter Edition Enterprise Edition

Servers running: • Windows Server 2003,

Datacenter Edition
• Windows Server 2008 R2
• Windows 2000 Server

• Windows Server 2008

• Windows 2000 Advanced Server

• Windows Server 2003, Standard Edition

• Windows 2000 Datacenter
• Windows Server 2003, Enterprise Edition Server

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:
 • Windows 7 with Remote Server Administration
Tools (RSAT) installed.

• Windows XP Professional

• Windows Vista with Remote Server

Administration Tools (RSAT) installed.

ADSI Edit is an MMC snap-in that you can use to view and modify attributes of directory objects as well as
the root DSA-specific entry (DSE) (rootDSE) attributes for the domain controller.

To find more information about ADSI Edit, see “Support Tools Help” in Tools and Settings Collection.

Dssite.msc: Active Directory Sites and Services

Category
Administrative Tools, MMC snap-in

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2008 R2 • Windows Server 2008 R2

• Windows Server 2008 • Windows Server 2008

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard

Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003,

• Windows Server 2003, Datacenter Edition Enterprise Edition

Servers running: • Windows Server 2003,

Datacenter Edition
• Windows Server 2008 R2
 • Windows Server 2008 • Windows 2000 Server

• Windows Server 2003, Standard Edition • Windows 2000 Advanced Server

• Windows Server 2003, Enterprise Edition • Windows 2000 Datacenter

Server
• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows 7 with Remote Server Administration

Tools (RSAT) installed.

• Windows Vista with Remote Server

Administration Tools (RSAT) installed.

• Windows XP Professional with Adminpak.msi

installed

You can use Active Directory Sites and Services to create, modify, and delete site configuration objects in
Active Directory, including sites, subnets, connection objects, and site links. You can also use Active
Directory Sites and Services to create the intersite topology, including mapping subnet addresses to sites,
creating and configuring site links, creating manual connection objects, forcing replication over a
connection, setting a domain controller to be a global catalog server, and selecting preferred bridgehead
servers.

Repadmin.exe: Repadmin

Category
Windows Support Tools, command-line

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

• Windows Server 2008 R2 • Windows Server 2008 R2

• Windows Server 2008 • Windows Server 2008

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard

Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003,
 • Windows Server 2003, Datacenter Edition Enterprise Edition

Servers running: • Windows Server 2003,

Datacenter Edition
• Windows Server 2008 R2
• Windows 2000 Server

• Windows Server 2008

• Windows 2000 Advanced Server

• Windows Server 2003, Standard Edition

• Windows 2000 Datacenter
• Windows Server 2003, Enterprise Edition Server

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows 7 with Remote Server Administration

Tools (RSAT) installed.

• Windows Vista with Remote Server

Administration Tools (RSAT) installed.

• Windows XP Professional

Repadmin is used to view the replication information on domain controllers. You can determine the last
successful replication of all directory partitions, identify inbound and outbound replication partners,
identify the current bridgehead servers, view object metadata, and generally manage Active Directory
replication topology. You can use Repadmin to force replication of an entire directory partition or of a
single object. You can also list domain controllers in a site.

Repadmin is extended in Windows Server 2003 to enable commands to target sets of domain controllers.
For example, you can target all domain controllers in a site or domain, or all domain controllers that are
global catalog servers. In Windows 2000 Server, Repadmin can report information about only one domain
controller at a time.

For more information about Repadmin, see “Support Tools Help” in Tools and Settings Collection.

Ldp.exe: Ldp

Category
Windows Support Tools, GUI

Version compatibility

Can Be Run From Can Be Run Against

Domain controllers running: Domain controllers running:

 • Windows Server 2008 R2 • Windows Server 2008 R2

• Windows Server 2008 • Windows Server 2008

• Windows Server 2003, Standard Edition • Windows Server 2003, Standard

Edition
• Windows Server 2003, Enterprise Edition
• Windows Server 2003,

• Windows Server 2003, Datacenter Edition Enterprise Edition

Servers running: • Windows Server 2003,

Datacenter Edition
• Windows Server 2008 R2
• Windows 2000 Server

• Windows Server 2008

• Windows 2000 Advanced Server

• Windows Server 2003, Standard Edition

• Windows 2000 Datacenter
• Windows Server 2003, Enterprise Edition Server

• Windows Server 2003, Datacenter Edition

• Windows Server 2003, Web Edition

Computers running:

• Windows 7 with Remote Server Administration

Tools (RSAT) installed.

• Windows Vista with Remote Server

Administration Tools (RSAT) installed.

• Windows XP Professional

Ldp is a Lightweight Directory Access Protocol (LDAP) graphical user interface (GUI) tool that you can use
to perform operations such as connect, bind, search, modify, add, and delete against any LDAP-
compatible directory, such as AD DS. You can also use Ldp to view objects that are stored in AD DS, along
with their metadata, for example, security descriptors and replication metadata.

You can use Ldp to view and edit the updateCachedMemberships operational attribute on the rootDSE.

For more information about Ldp, see “Support Tools Help” in Tools and Settings Collection.

Global Catalog Registry Entries

The information here is provided as a reference for use in troubleshooting or verifying that the required
settings are applied. It is recommended that you do not directly edit the registry unless there is no other
alternative. Modifications to the registry are not validated by the registry editor or by Windows before they
are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the
system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console
(MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use
extreme caution.

The following registry entries are associated with the global catalog.

NTDS Parameters
The following registry entries under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters control or
contain information about the configuration of the global catalog.

Global Catalog Promotion Complete

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Windows Server 2003:

Used for Install From Media. This entry is set in conjunction with the domain controller setting its rootDSE
attribute isGlobalCatalogReady to TRUE, the Net Logon service on the domain controller registering SRV
resource records that specifically advertise the global catalog in DNS, and the domain controller beginning
to listen on port 3268.

Global Catalog Partition Occupancy

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003:

The requirement for read-only replicas that must be added (replication partner established) or
synchronized (replication completed), or both, on the global catalog server before the server is advertised
in DNS. Lower occupancy levels specify varying levels of replication completeness, including advertising in
DNS when all read-only replicas of only those domains represented in the domain controller’s site are
synchronized.

Version
Windows 2000 Server with SP3 and later:

The occupancy level requires full synchronization of all read-only replicas.

Version
Windows 2000 Server with Service Pack (SP) 2 and earlier:

The occupancy level requires only the replicas of domains in the site.

Global Catalog Delay Advertisement

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows 2000 Server

Overrides the requirements set in Global Catalog Partition Occupancy entry and allows global catalog
advertisement without requiring full synchronization of all read-only replicas. If you do not set this value,
checking for synchronized read-only partitions continues to occur at 30-minute intervals until the
requirements are met.

Cached Membership Site Stickiness (minutes)

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003

The maximum time during which an account’s cached membership can be refreshed automatically without
the account having to log on in this site. The default value is one-half the value of the account’s site
affinity setting, which is 180 days by default. If the account has not logged on in more than 90 days, the
account’s group membership cache expires and must be reinstated at the next logon by contacting a
global catalog server.

Cached Membership Staleness (minutes)

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003

The maximum staleness to tolerate when using a cached group membership. The default value is one
week. If the cached membership age is greater than this interval and no global catalog server is available,
the logon fails. If no value is present, the default value is used.

Cached Membership Refresh Interval (minutes)

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003

The frequency of automatic cache refresh. The default value is eight hours. If no value is present, the
default value is used.

Cached Membership Refresh Limit

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003
The maximum number of user and computer accounts that are refreshed during a group membership
cache refresh.

SamNoGcLogonEnforceKerberosIpCheck

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003

By default, allows site affinity to be tracked for Kerberos logons that originate outside the site. This setting
only applies to Kerberos logons; it will not affect site affinity caching for NTLM logons from different sites.

SamNoGcLogonEnforceNTLMCheck

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003

A value of 1 configures Security Accounts Manager (SAM) to not give site affinity to NTLM logon requests
that are network logon requests; it may not prevent caching for other logon types.

NTDS Diagnostics
The following registry entry under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics control the
logging level for the component or process that is specified in the entry name.

Global Catalog

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows 2000 Server

The logging level for the global catalog on the domain controller. The value is set to an integer from 0 (no
logging) through 5 (most verbose logging).

20 Group Caching

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Version
Windows Server 2008 R2, Windows Server 2008, Windows Server 2003

The logging level for Universal Group Membership Caching on a domain controller in a site where this
feature is enabled. The value is set to an integer from 0 (no logging) through 5 (most verbose logging).
Significant events are reported at logging level 2. with many additional events reported at logging level 5.
Global Catalog Group Policy Settings

The following table lists and describes the Group Policy settings that are associated with global catalog
servers.

Group Policy Settings Associated with the Global Catalog

Group Policy
Setting Description

Automated Site Determines whether domain controllers will dynamically register DC Locator site-
Coverage by the DC specific SRV resource records for the closest sites where no domain controller for
Locator DNS SRV the same domain exists (or no global catalog server for the same forest exists).
Records These DNS records are dynamically registered by the Net Logon service, and they
are used to locate domain controllers.

Sites Covered by the Specifies the sites for which the global catalog servers should register the site-
GC Locator DNS SRV specific GC Locator SRV resource records in DNS. These records are registered in
Records addition to the site-specific SRV resource records registered for the site where the
global catalog server resides and, if the global catalog server is appropriately
configured, for the sites without a global catalog server in the same forest for
which this global catalog server is the closest global catalog server. These records
are registered by Net Logon service.
If this policy is not configured, then it is not applied to any global catalog servers
and global catalog servers use their local configuration.

Network Ports Used by Global Catalog Servers

The following table shows the network ports that are used by global catalog servers.

Port Assignments for Global Catalog Servers

Service Name UDP TCP

LDAP 3268 (global catalog)

LDAP 3269 (global catalog Secure Sockets Layer [SSL])

LDAP 389 389

LDAP 636 (SSL)

RPC/REPL 135 (endpoint mapper)

Kerberos 88 88
DNS 53 53

SMB over IP 445 445