Understanding Global Catalog (Active Directory)

8.3K

In addition to the 5 FSMO roles in Active Directory, there is Global Catalog (GC), that is often informally referred to as a sixth DC role, although it is not an FSMO role. Unlike FSMO roles, any controller in a domain can host a Global Catalog role. This role doesn’t need to be unique within an Active Directory domain or forest. However, the Global Catalog is the most important DC role from a practical point of view.

The Global Catalog architecture described in our article applies to Active Directory Domain Services on Windows Server 2025 as well as supported earlier Windows Server versions.

Global Catalog and Windows Server 2025

Windows Server 2025 also introduces changes to the Active Directory Domain Services database engine, including support for 32-KB database pages. This can affect the storage characteristics and size of the ntds.dit database. When planning DCs and Global Catalog servers, you should consider the resulting storage requirements together with the number of domains, objects, Global Catalog attributes, replication topology, and available disk capacity.

These database-engine changes do not alter the basic Global Catalog architecture: a GC still contains a full replica of its own domain and a partial replica of other domains in the forest.

What is the Global Catalog?

A Global Catalog (GC) server is a DC that stores a full replica of all objects in its own domain and a partial replica of objects from all other domains in the forest. The partial replicas contain only the attributes included in the Global Catalog’s Partial Attribute Set (PAS). Global catalogs allow users and apps to find objects in any domain of the current forest by searching for attributes included in GC. For example, in a multi-domain forest, a DC may use a Global Catalog in order to locate a user account when the UPN cannot be resolved locally. A UPN logon does not inherently require a Global Catalog when the user account belongs to the local domain.

When a DC cannot resolve a User Principal Name (UPN) locally, it can query a Global Catalog server to locate the user’s account within the forest.

A DC that is not a GC normally stores a complete replica of its own domain but does not maintain replicas of other domains’ directory partitions.

The Global Catalog contains a basic (but incomplete) set of attributes for each forest object in each domain (Partial Attribute Set, PAS). The GC receives data from all the domain directory partitions in the forest, they are copied using a standard AD replication service. The set of attributes that are copied to the Global Catalog is defined in the AD schema. If necessary, you can configure additional attributes that will be replicated to the GC using the Active Directory Schema mmc snap-in.

Imagine a workstation requesting info about an object from another domain in the current AD forest. The machine contacts the nearest GC with a request in order to provide it with info about this object.

The Global Catalog can answer searches for attributes that are included in its Partial Attribute Set (PAS). In case the requested attribute is not included in the PAS, the GC cannot return its value from the partial replica and may return an LDAP referral to the appropriate domain partition. The client can then follow the referral and query a DC that holds the required directory data.

To add an attribute to the Global Catalog’s Partial Attribute Set, select Replicate this attribute to the Global Catalog in the Active Directory Schema snap-in. This sets the isMemberOfPartialAttributeSet attribute to TRUE for that schema attribute.

Find domain controllers with GC roles using PowerShell

You can use PowerShell to find domain controllers with GC roles in the domain. First, import the PowerShell Active Directory module into your current sessions:

Import-Module ActiveDirectory

To find the list of DCs that contains the Global Catalog role in the current forest, run the command:

(Get-ADForest).GlobalCatalogs

You can check if the current DC is a Global Catalog server:

Get-ADDomainController -Identity $env:COMPUTERNAME |
Format-Table Name,IsGlobalCatalog

Check GC role on DCs in a specific AD site

Get-ADDomainController -Filter * |
Where-Object {$_.Site -eq 'New-York'} |
FT Name,IsGlobalCatalog

List all GC servers with dsquery (Legacy tool)

Or use the dsquery command-line tool. To list all GC servers in the current Active Directory forest:

dsquery server -forest -isgc

Finding GC servers in a specific forest domain

dsquery server -domain theitbros.com -isgc

Notes

The first Global Catalog server is automatically created on the first DC in the forest when you promote the DC after installing the Active Directory Domain Services role. In a single Active Directory site, one GC can provide the required Global Catalog functionality, but relying on a single GC creates a single point of failure. You should deploy multiple GC servers where GC availability is required. In many AD environments, all writable DCs are configured as Global Catalog servers.

In case you are working with multi-site environment, you need to plan GC placement based on authentication requirements, directory search traffic, app dependencies, WAN connectivity, and failure cases. Depending on the topology, each site does not necessarily need its own GC, but sites that require local GC access should have appropriate redundancy. Keep in mind that Exchange relies on Global Catalog servers for directory lookups, so GC availability should be considered carefully when planning Exchange deployments.

You can assign additional domain controllers as GC by selecting the Global Catalog option in the “Active Directory Sites and Services” snap-in (dssite.msc).

Global catalog server purposes

The global catalog server is used for the following purposes:

Object search

If a user searches for an object by specifying Entire Directory parameter in the query, this LDAP query is redirected to the port TCP/3268 (or TCP/3269 for LDAP over SSL) and sent to the nearest GC server. If no available Global Catalog server can be reached for the client/app, forest-wide searches may fail/require referrals to the appropriate domain directory partition.

Authentication

During the logon process, a DC may query a Global Catalog server to resolve a User Principal Name (UPN) and obtain universal group membership information. The actual authentication of user credentials is still performed by a DC using Kerberos/NTLM.

Verifying universal group membership in a multi-domain environment

In the verification process, the domain controller verifies the authenticity of the user, after which the user receives authorization data to access the resources. To provide this information, the domain controller retrieves the security identifiers (SIDs) for all Active Directory groups that the user is a member of and adds these identifiers to the user’s access token. Because universal groups can contain user accounts and groups from any domain in the forest, the group membership in them can only be resolved by the GC Server that has catalog information at the forest level.

Checking references to objects within the forest

Domain controllers use a Global Catalog to validate references to objects in other domains in the forest. That’s why if the domain controller contains an object with an attribute, that contains a reference to an object in another domain — the domain controller checks the link by establishing a connection to the Global Catalog server.

Exchange Address Book Search

When users want to find a person within the organization in Outlook, they usually search through the Global Address List (GAL). The GAL is a list that is created by Exchange as a result of an LDAP query to search for all mail-enabled objects — users, contacts, and distribution groups.

When users search the Global Address List (GAL) in Outlook, the client doesn’t directly query a Global Catalog server in the way older Exchange versions did. Modern Outlook clients access address-book info through Exchange services. Exchange itself relies on AD and Global Catalog servers to access recipient and directory info. Exchange servers locate suitable DCs and Global Catalog servers through AD and DNS.

For Outlook clients using Cached Exchange Mode, the Offline Address Book (OAB) provides a local copy of address-list info and is normally used for address-book queries to reduce the workload on Exchange servers. Connected Outlook clients can also use the online GAL when required.

Therefore, Global Catalog availability remains important for Exchange, but it should not be described as a direct Outlook-to-GC dependency.

How to Optimize Global Catalog Server Placement?

For resiliency, deploy multiple Global Catalog servers where GC availability is required and avoid relying on a single GC as the only available server for a production site. In many AD environments, configuring all writable DCs as Global Catalog servers is common because it provides GC redundancy and simplifies placement.

If every DC in a domain is also a Global Catalog server, the traditional Infrastructure Master placement restriction does not apply. However, GC placement should still account for site topology, WAN bandwidth, authentication requirements, directory search traffic, and application dependencies.

Global Catalog servers store a partial replica of objects from other domains in the forest. Enabling the GC role therefore increases the amount of directory data stored on the server and can increase replication traffic. Mostly, this overhead is relatively small, but you should consider it when deploying DCs in bandwidth-constrained/resource-limited locations.

Global Catalog and Lingering Objects

Lingering objects are an AD replication consistency problem, not a Global Catalog-specific feature. Because a Global Catalog stores partial replicas of other domain partitions, replication problems can also affect GC data.

A DC that remains disconnected from replication longer than the forest’s configured tombstone lifetime can potentially reintroduce outdated objects when it reconnects. The actual tombstone lifetime is environment-dependent, so you need to check the configured value rather than assuming a specific default.

If you suspect lingering objects, first you need to check the overall replication health:

repadmin /replsummary
repadmin /showrepl

Do not remove lingering objects until you have identified the affected DC and directory partition and confirmed the correct source DC.

For detailed detection and removal procedures, including the use of Microsoft’s Lingering Object Liquidator (LoL/LOLv2) and repadmin /removelingeringobjects, see the Microsoft documentation on removing lingering objects.

Strict Replication Consistency can help prevent lingering objects from being reintroduced through replication. Legacy environments should verify that the setting is enabled.

Universal Group Membership Caching (UGMC)

In multi-site AD environments, it is not always necessary to deploy a Global Catalog server in every site. Universal Group Membership Caching (UGMC) allows DC to cache universal group membership information after the first successful logon. This can reduce WAN traffic and allow users to authenticate even when a local GC server is unavailable.

UGMC can be a useful alternative for smaller remote sites where deploying and maintaining an additional Global Catalog server is not desirable.

Without access to a Global Catalog, you can face a fail during some logon scenarios (particularly in multi-domain forests when universal group membership information is required). The Global Catalog is one of the most important AD services because it supports forest-wide searches, user authentication cases, and universal group membership resolution.

How to Enable/Disable the Global Catalog Role on a Domain Controller?

You can enable the Global Catalog role on a domain controller in several ways:

• Using the graphical Active Directory Sites and Services mmc console;
• Using PowerShell;
• Using the dsmod.exe tool for legacy environments. The command requires the distinguished name (DN) of the server object, not the NTDS Settings object:

  dsmod server "CN=DC03,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=theitbros,DC=com" -isgc yes

  The -isgc yes parameter enables the Global Catalog on the specified DC. To disable it, use -isgc no.
  Note that dsmod is a legacy command-line tool. You should prefer Active Directory PowerShell cmdlets or repadmin for command-line administration.

Enable Global Catalog role on DC using Active Directory Sites and Services

Run the mmc snap-in “Active Directory Sites and Services” (Start > Windows Administrative Tools, or run the dssite.msc command).

Expand the Sites section and find the AD site that contains your domain controller. Expand it, right-click on NTDS Settings and then select Properties.

Set the Global Catalog checkbox on the General tab to enable the GC role, or uncheck it to disable it. Click OK to save your changes.

Once promoted to a GC server, an event with Event ID 1110 should appear in the Directory Service section of Event Viewer:

Event Source: NTDS General

Event Category: Replication

After successful installation of the role, Event ID 1119 will appear:

This domain controller is now a global catalog

In this case, the value of the Global Catalog Promotion Complete registry setting under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters key registry should be 1.

You can make a read-only domain controller a Global Catalog server. You can also make a Read-Only Domain Controller (RODC) a Global Catalog server. An RODC can host the Global Catalog service and is commonly used with GC in branch-office cases. However, an RODC remains a read-only DC. A Global Catalog does not make an RODC equivalent to a writable DC: the RODC still cannot accept directory write operations. Before deploying a GC on an RODC, you should verify that apps and services support the RODC architecture and its read-only limitations.

Enable Global Catalog role on DC using PowerShell

The Global Catalog setting is stored in the options attribute of the DC’s NTDS Settings (nTDSDSA) object. The 0x00000001 bit (IS_GC) indicates that the DC is or is becoming a Global Catalog server.

You can enable the Global Catalog with the Active Directory PowerShell module by adding this bit to the existing options value:

Import-Module ActiveDirectory

$dc = Get-ADDomainController -Identity 'DC03'
$ntds = Get-ADObject -Identity $dc.NTDSSettingsObjectDN -Properties options

$newOptions = [int]$ntds.options -bor 0x1

Set-ADObject -Identity $ntds.DistinguishedName -Replace @{options = $newOptions}

The -bor operation preserves the existing option bits and adds only the IS_GC bit. You should not replace options with 1 unconditionally, because that could clear other option flags.

You can verify the setting with the command below:

Get-ADObject -Identity $ntds.DistinguishedName -Properties options |
Select-Object DistinguishedName, options

Enable GC using Repadmin

You can also enable or disable the Global Catalog flag with repadmin:

repadmin /options DC03 +IS_GC

In order to remove the Global Catalog role, use the command:

repadmin /options DC03 -IS_GC

Hint. Note that AD does not require every domain to have a Global Catalog server. However, a forest should have an appropriate number of Global Catalog servers in order to support authentication, universal group membership, directory searches, and app requirements. Before disabling a GC, you need to check if another GC is available where required and that the change will not affect apps/authentication.

These commands can be used to move the global catalog server functionality from one DC to another.

Check registration of Global Catalog server

AD registers Global Catalog service locator records as DNS SRV records under the _msdcs namespace. The forest-wide GC locator record has this format:

_ldap._tcp.gc._msdcs.<forest-root-domain>

Here is an example:

_ldap._tcp.gc._msdcs.theitbros.com

For a specific AD site, the corresponding record uses this format:

_ldap._tcp.<SiteName>._sites.gc._msdcs.<forest-root-domain>

Here is an example:

_ldap._tcp.New-York._sites.gc._msdcs.theitbros.com

You can query the GC SRV record with the built-in nslookup tool:

nslookup -type=SRV _ldap._tcp.gc._msdcs.theitbros.com

For a site-specific record, use the following command:

nslookup -type=SRV _ldap._tcp.New-York._sites.gc._msdcs.theitbros.com

These records allow AD clients and DC Locator to discover Global Catalog servers.

Verifying Global Catalog replication status

To ensure that Global Catalog data is fully replicated between DCs, you can use the repadmin tool. This is especially useful when troubleshooting delays in Global Catalog availability after enabling the GC role on a DC.

For example, you can use the following command to show replication status for all directory partitions (including Global Catalog-related partitions):

repadmin /showrepl

You can also use the following command to get an overview of replication health across all DCs in the forest:

repadmin /replsummary

Check Global Catalog role on DC with ldp.exe

After activating the Global Catalog role on DC, you can check its readiness. For this, the ldp.exe utility is used. Run the tool, select Connection > Connect > specify the DC name and a 389 as a connection port. Click Ok.

Verify the isGlobalCatalogReady: TRUE value in the LDP window. This means that your GC is ready.

Check Global Catalog role on DC with CMD

You can use nltest in order to check if DC Locator can discover a Global Catalog for the domain:

nltest /dsgetdc:theitbros.com /gc

Check the output for the GC flag. This indicates that DC Locator discovered a DC that advertises the Global Catalog service.