Global Catalog & Universal Group Membership Caching in Windows Server 2025

The Global Catalog (GC) is a distributed data repository — a special, read-only data store hosted by one or more domain controllers — that contains a partial replica of every object in every domain across the entire Active Directory forest. Unlike a standard domain controller, which only knows about objects in its own domain, a GC server knows about everything, everywhere in the forest.

The GC stores a complete, writable copy of every object in its own domain, plus a read-only, partial copy of every object in all other domains in the forest. That “partial” copy includes the attributes most commonly searched for — display name, email address, SamAccountName, group membership — making the GC the forest-wide search engine for Active Directory.

🔍 Forest-Wide Object Search

The GC enables searches that span multiple domains without requiring inter-domain referrals for every query. Applications like Exchange, Outlook, and SharePoint use the GC to resolve email addresses and find users across the entire organization.

🔑 Universal Group Resolution at Login

Every time a user logs in, Windows must enumerate all universal groups that user belongs to — across all domains — to build the complete access token. The GC is the only place that stores this universal group membership data for the entire forest.

📧 UPN Suffix Authentication

When a user logs in with a UPN (user@vmorecloud.com), the authenticating DC uses the GC to locate which domain contains that UPN suffix — essential in multi-domain forests where the login domain differs from the user’s home domain.

🌐 Application Directory Integration

Exchange Server, Microsoft Teams, SharePoint, and many third-party enterprise applications make GC queries on port 3268 (or 3269 for TLS) for address book lookups, resource discovery, and identity resolution across domain boundaries.

📌 Port Reference

Standard LDAP queries go to port 389. GC queries use port 3268 for standard LDAP and port 3269 for LDAP over TLS. When an application fails to find a user in another domain, the first diagnostic question is always: can the app reach port 3268 on a GC server?

Architecture

Global Catalog Architecture

In a single-domain forest like vmorecloud.com, every domain controller that is designated as a GC server holds a complete, writable replica of all objects in that domain. In multi-domain forests, the GC additionally holds partial replicas from all other domains.

GC Server server.vmorecloud.com 192.168.91.129 · HQ Site Complete domain replica
Port 3268 / 3269

AD replication
+ GC attributes

Branch DC BranchDC01 Branch Office Site GC or UGMC
choice depends on scenario

Clients Branch Users Workstations Fast local auth
No WAN dependency

How the GC Participates in Login

User at the branch submits credentials. The local DC authenticates the username and password — this doesn’t require the GC.
Before issuing the Kerberos ticket, the DC must build a complete PAC (Privilege Attribute Certificate) — a list of all group memberships for that user, including universal groups from all domains in the forest.
The DC contacts a GC server (ideally local, or via WAN to server.vmorecloud.com) on port 3268 and queries for the user’s universal group memberships.
The GC returns the complete universal group list. The DC includes it in the Kerberos ticket and grants access.
If no GC server is reachable — in the default configuration — the login fails with the error: “There are currently no logon servers available to service the logon request.”

⚠ The single most common cause of branch office logon failures

When a branch WAN link goes down and there’s no GC server or UGMC cache available locally, domain users cannot log in — even though a local domain controller is running and healthy. Understanding this failure mode is the reason GC placement and UGMC configuration are critical design decisions for every multi-site AD deployment.

The Alternative

What Is Universal Group Membership Caching?

Universal Group Membership Caching (UGMC) is a feature that allows a branch domain controller to cache a user’s universal group memberships locally — so that subsequent logins by the same user do not require a WAN query to a GC server. It was introduced in Windows Server 2003 R2 and has been refined in every server version since.

The first time a user logs in at a branch with UGMC enabled, the local DC queries a GC server (over the WAN if necessary) to get that user’s universal group memberships. It then caches this information locally. The cache is refreshed every 8 hours by default (configurable). On subsequent logins, the DC reads from its local cache instead of querying the GC — meaning logins succeed even when the WAN link to the GC server is down.

💾 How the Cache Works

UGMC stores the universal group memberships for each user that has logged in through the DC. The cache lives in the domain controller’s copy of the AD database. It is not replicated to other DCs — it’s per-DC and per-user.

🔄 Cache Refresh Cycle

By default, cached memberships are refreshed every 8 hours. This means if a user is added to or removed from a universal group, the change takes up to 8 hours to be reflected at cached branch DCs. This is a trade-off to understand before deployment.

What UGMC Does NOT Do

UGMC does not cache the GC’s full attribute set — applications that need to search the forest-wide directory (Exchange address book, SharePoint people picker) still need a real GC server.
UGMC does not support UPN suffix routing for logins where the UPN suffix isn’t the default domain — a real GC is still required for those scenarios.
UGMC only caches universal group memberships — domain local and global group memberships are always resolved locally and don’t require the GC.

✅ When UGMC is the right answer

UGMC is the right choice for branch offices where: the site has a constrained or unreliable WAN link, the branch has limited server resources (no need to host the full GC data set), users at the branch are in a single domain, and no Exchange or other GC-dependent applications run at the branch. It solves the login resilience problem with minimum resource overhead.

Decision Framework

Global Catalog vs UGMC — Choosing the Right Tool

Scenario / Requirement	Use GC Server	Use UGMC
Exchange Server at branch	Required — GC port 3268	Insufficient — GC needed
Multi-domain forest users logging in	Full support	Supported (universal groups cached)
Forest-wide LDAP directory searches	Full support	Not supported
Constrained WAN link at branch	Reduces WAN dependency	Best choice — minimal WAN usage
Limited server resources at branch	Higher storage/memory overhead	Very low overhead
UPN suffix routing (non-default domains)	Required	Not supported
WAN resilience for logins	Full — no WAN needed once local	Full for cached users after first login
Single-domain forest	Works perfectly	Ideal — simpler, lighter weight
Immediate group membership changes	Immediate via AD replication	Up to 8hr delay (configurable)

Platform Updates

Windows Server 2025 Enhancements

Faster GC Replication Convergence

WS2025 improves the speed at which GC attribute changes (partial attribute set updates) propagate to all GC servers across the forest — shrinking the window where GC data is stale after a change.

UGMC Cache Granularity

Windows Server 2025 adds per-user cache refresh controls via Group Policy, allowing administrators to set different refresh intervals for privileged accounts vs standard users — a significant security improvement.

TLS 1.3 for GC Queries

GC LDAP connections on port 3269 now default to TLS 1.3 in WS2025, replacing TLS 1.2. This affects Exchange, directory-enabled apps, and any client querying the GC over an encrypted channel.

Azure Entra ID GC Integration

WS2025 deepens the integration between on-premises GC data and Microsoft Entra ID via the updated Entra Connect Sync engine — GC-level attributes now sync more reliably to cloud identity for hybrid deployments.

Summary

Key Highlights

Global Catalog = Forest-Wide Directory

The GC holds a partial replica of every object in every domain across the forest. It is the only place where universal group memberships for the entire forest are stored and resolvable at login time.

Every Login Requires Universal Group Resolution

Windows cannot build a complete access token without knowing all universal groups the user belongs to — across all domains. Without a reachable GC or a UGMC cache, domain logins fail entirely.

UGMC Solves Login Resilience at Low Cost

UGMC caches universal group memberships locally after the first login, eliminating WAN dependency for subsequent logins. It adds almost no storage overhead and is the recommended solution for resource-constrained branch offices.

GC Is Still Required for Exchange and Forest Search

UGMC only solves the login resilience problem. Any application that needs to search the forest-wide directory — Exchange Server, SharePoint, Teams — still requires a real GC server accessible on port 3268/3269.

UGMC Has an 8-Hour Default Refresh Window

Cached group memberships refresh every 8 hours by default. If a user is added to or removed from a universal group that controls critical access, that change may take up to 8 hours to reflect at branch offices using UGMC.

WS2025 Brings Per-User Cache Controls

Windows Server 2025 allows different UGMC refresh intervals for different user types via Group Policy — a major improvement for privileged account security that wasn’t available in previous server versions.

Hands-On Lab · Part 1

Lab: Configure a Global Catalog Server

🧪

Lab 1 — Enable and Verify Global Catalog on server.vmorecloud.com Domain: vmorecloud.com · DC: server.vmorecloud.com · IP: 192.168.91.129 · OS: Windows Server 2025

Verify current GC status via PowerShell

Before making changes, check which DCs in your domain are currently GC servers.

PowerShellserver.vmorecloud.com

# List all DCs and their GC status
Get-ADDomainController -Filter * | Select-Object Name, Site, IsGlobalCatalog, IPv4Address

# Check if server.vmorecloud.com is a GC
Get-ADDomainController -Identity “server.vmorecloud.com” | Select Name, IsGlobalCatalog

Enable GC via ADSI Edit (GUI method)

Open Active Directory Sites and Services → expand Sites → Default-First-Site-Name → Servers → SERVER → right-click NTDS Settings → Properties → check “Global Catalog” → OK.

Enable GC via PowerShell (recommended for automation)

PowerShellserver.vmorecloud.com · 192.168.91.129

# Enable Global Catalog on server.vmorecloud.com
$ntdsSettings = Get-ADObject `
    -SearchBase “CN=SERVER,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=vmorecloud,DC=com” `
    -Filter {objectClass -eq “nTDSDSA”} `
    -Properties options

# Set bit 1 in the options attribute to enable GC
Set-ADObject $ntdsSettings -Replace @{options = 1}

# Alternative: use simpler Set-ADDomainController cmdlet
Set-ADDomainController -Identity “server.vmorecloud.com” -IsGlobalCatalog $true

Add a branch DC as a GC server (if appropriate)

PowerShellEnable GC on branch DC

# Enable GC on the branch DC (substitute your branch DC name)
Set-ADDomainController -Identity “BranchDC01.vmorecloud.com” -IsGlobalCatalog $true

# Monitor GC promotion progress — look for event 1119 in Directory Services log
Get-EventLog -LogName “Directory Service” -Newest 20 | Where-Object { $_.EventID -eq 1119 }

Test GC connectivity on port 3268

PowerShell + ldpGC port connectivity test

# Test GC port 3268 is open and responding
Test-NetConnection -ComputerName “server.vmorecloud.com” -Port 3268
Test-NetConnection -ComputerName “192.168.91.129” -Port 3268

# Query GC via LDAP on port 3268 to confirm it’s serving responses
ldp.exe # Connect → server.vmorecloud.com, port 3268, SSL unchecked → bind → search

# PowerShell GC query test
$gc = [System.DirectoryServices.DirectoryEntry]“GC://server.vmorecloud.com”
$searcher = [System.DirectoryServices.DirectorySearcher]$gc
$searcher.Filter = “(samAccountName=Administrator)”
$searcher.FindAll() | Select-Object -ExpandProperty Properties

Hands-On Lab · Part 2

Lab: Enable Universal Group Membership Caching

ℹ — When to use this lab

Use UGMC when you have a branch DC (not the primary server.vmorecloud.com) in a site where hosting a full GC is impractical due to storage, bandwidth, or resource constraints. UGMC is enabled per-site in AD Sites and Services, not per-DC.

🧪

Lab 2 — Enable UGMC on Branch Site via PowerShell & GUI Domain: vmorecloud.com · Target Site: Branch-East · Windows Server 2025

Check current UGMC status for all sites

PowerShellserver.vmorecloud.com

# Check UGMC status for all sites in vmorecloud.com
Get-ADObject -SearchBase “CN=Sites,CN=Configuration,DC=vmorecloud,DC=com” `
    -Filter {objectClass -eq “nTDSSiteSettings”} `
    -Properties msDS-Behavior-Version, options, “msDS-CacheGroupMembership” |
    Select Name, options, “msDS-CacheGroupMembership”

Enable UGMC via Active Directory Sites and Services (GUI)

Open Active Directory Sites and Services → expand Sites → Branch-East → right-click “NTDS Site Settings” → Properties → check “Enable Universal Group Membership Caching” → optionally set “Refresh cache from” to specify which GC server to cache from → OK.

Enable UGMC via PowerShell (scriptable, repeatable)

PowerShellEnable UGMC on Branch-East site

# Get the nTDSSiteSettings object for Branch-East site
$siteSettings = Get-ADObject `
    -SearchBase “CN=Branch-East,CN=Sites,CN=Configuration,DC=vmorecloud,DC=com” `
    -Filter {objectClass -eq “nTDSSiteSettings”} `
    -Properties options

# Enable UGMC: set bit 32 (0x20) in the options attribute
$currentOptions = $siteSettings.options
$newOptions = $currentOptions -bor 32
Set-ADObject $siteSettings -Replace @{options = $newOptions}

# Verify UGMC is now enabled
Get-ADObject -Identity $siteSettings.DistinguishedName -Properties options |
    Select Name, @{Name=“UGMC_Enabled”; Expression={$_.options -band 32}}

Set the GC refresh source and interval

PowerShell + Group PolicyConfigure refresh interval

# Configure UGMC to refresh from specific GC (server.vmorecloud.com)
# Set in NTDS Site Settings: “Refresh cache from” = HQ-DataCenter site
Set-ADObject $siteSettings -Replace @{
    “msDS-Preferred-GC-Site” = “CN=HQ-DataCenter,CN=Sites,CN=Configuration,DC=vmorecloud,DC=com”
}

# Configure cache refresh interval via Group Policy (Default: 8 hours / 480 min)
# GPO path: Computer Config → Policies → Admin Templates
#   → System → Net Logon → Caching of Knowledge about Universal Groups
# Or via registry on branch DC:
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters” `
    -Name  “Universal Group Membership Cache” -Value 1  # 1 = enabled
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters” `
    -Name  “Universal Group Membership Cache Refresh Period (Hours)” -Value 8

Hands-On Lab · Part 3

Lab: Verify GC and UGMC Configuration

🧪

Lab 3 — Comprehensive Verification Commands Confirm GC and UGMC are functioning correctly in vmorecloud.com

PowerShell — Complete Verification Suiteserver.vmorecloud.com

### ── VERIFICATION 1: Confirm GC server status ──────────────────
Get-ADDomainController -Filter {IsGlobalCatalog -eq $true} |
    Select Name, Site, IPv4Address, IsGlobalCatalog | Format-Table -AutoSize

### ── VERIFICATION 2: Confirm server.vmorecloud.com is GC ────────
nltest /dsgetdc:vmorecloud.com /gc
nltest /dsgetdc:vmorecloud.com /server:server.vmorecloud.com

### ── VERIFICATION 3: Test GC LDAP port 3268 ─────────────────────
Test-NetConnection -ComputerName “192.168.91.129” -Port 3268 -InformationLevel Detailed
Test-NetConnection -ComputerName “192.168.91.129” -Port 3269 -InformationLevel Detailed

### ── VERIFICATION 4: Check UGMC status on branch site ───────────
Get-ADObject -SearchBase “CN=Branch-East,CN=Sites,CN=Configuration,DC=vmorecloud,DC=com” `
    -Filter {objectClass -eq “nTDSSiteSettings”} -Properties options |
    Select Name, @{N=“UGMC_Enabled”; E={[bool]($_.options -band 32)}}

### ── VERIFICATION 5: Verify UGMC cache on branch DC ─────────────
# Run on the branch DC (BranchDC01)
repadmin /showrepl
nltest /query

### ── VERIFICATION 6: Check event logs for GC events ─────────────
Get-EventLog -LogName “Directory Service” -Newest 50 |
    Where-Object { $_.EventID -in @(1119,1120,1655,1125,1126) } |
    Select EventID, TimeGenerated, Message | Format-List

### ── VERIFICATION 7: Force UGMC cache refresh ───────────────────
# Run on branch DC to force immediate cache refresh
nltest /sc_reset:vmorecloud.com
nltest /SC_QUERY:vmorecloud.com

Hands-On Lab · Part 4

Lab: Monitor, Troubleshoot & Health Check

Key Event IDs for GC and UGMC

Event ID	Log	Meaning
`1119`	Directory Service	DC is now advertising itself as a GC server — promotion complete
`1120`	Directory Service	DC stopped advertising as GC — GC role removed or replication issue
`1655`	Directory Service	GC is unresponsive — logon failures may occur if UGMC not configured
`1125`	Directory Service	Active Directory could not contact a GC — check network connectivity
`1645`	Directory Service	UGMC refresh occurred — normal operational event
`1863`	Directory Service	UGMC cache expired and refresh is pending — WAN issue may delay this

Troubleshooting Common GC / UGMC Issues

PowerShell — Troubleshooting Toolkitvmorecloud.com

### ── ISSUE: Users can’t log in at branch ────────────────────────
# Step 1: Confirm GC is reachable from branch
Test-NetConnection -ComputerName “server.vmorecloud.com” -Port 3268

# Step 2: Run dcdiag on branch DC
dcdiag /test:replications /v
dcdiag /test:netlogons /v

# Step 3: Check if UGMC is enabled for the branch site
Get-ADObject -SearchBase “CN=Branch-East,CN=Sites,CN=Configuration,DC=vmorecloud,DC=com” `
    -Filter {objectClass -eq “nTDSSiteSettings”} -Properties options |
    Select @{N=“UGMC”; E={[bool]($_.options -band 32)}}

### ── ISSUE: GC promotion appears stuck ──────────────────────────
# Check if GC is still building its partial attribute set
repadmin /showrepl
Get-EventLog -LogName “Directory Service” -Newest 20 |
    Where-Object {$_.EventID -eq 1119}  # Look for Event 1119 to confirm completion

### ── ISSUE: UGMC changes not reflecting at branch ───────────────
# Force immediate UGMC refresh without waiting for 8hr cycle
nltest /sc_reset:vmorecloud.com  # Run on affected branch DC
klist purge                       # Clear Kerberos ticket cache on client
gpupdate /force                    # Refresh policies with new group memberships

✅ Best Practice — Always run dcdiag after GC/UGMC changes

After enabling or disabling GC on any DC, or enabling UGMC on a new site, run dcdiag /test:advertising on the affected DC and dcdiag /test:replications on the primary DC. These two tests catch 90% of GC and UGMC configuration problems before they impact users.

Business & Technical Impact

Why the Global Catalog and UGMC Matter

Login failures are the most user-visible AD problem — and both GC and UGMC directly prevent them

Every domain login that involves universal groups — which means every login in any forest with universal groups configured — will fail if a GC server or UGMC cache is not reachable. This isn’t a subtle performance problem: it’s a hard failure. Users see “No logon servers available” and cannot work. Correct GC placement and UGMC configuration are the primary defenses against this failure mode at branch offices.

Exchange Server cannot function without GC access — full stop

Microsoft Exchange Server uses the Global Catalog for virtually every operation: sending email (address lookups), receiving email (recipient resolution), managing mailboxes (user attribute queries), and processing calendar requests (free/busy lookups). An Exchange environment without reliable GC access on port 3268 will produce cascading failures across every Exchange service — making GC placement a prerequisite for any Exchange deployment, not an afterthought.

UGMC is the lightweight answer to a heavyweight problem

Deploying a full GC server at every branch site requires that site to host a complete copy of the partial attribute set for the entire forest — which grows as the forest grows. For a branch office with 20 users and a 50 Mbps VPN link, that’s a poor use of resources. UGMC achieves the same login resilience benefit with a fraction of the storage and bandwidth overhead: it only caches the specific universal group memberships of users who actually log in at that site — nothing more.

Compliance and security frameworks require documented identity resolution

GDPR, ISO 27001, and SOC 2 all require that access control decisions be based on current, accurate group memberships. The 8-hour UGMC cache window means a user removed from a security-critical universal group may retain access at a branch office for up to 8 hours after revocation. Understanding, documenting, and configuring this refresh window appropriately is a compliance requirement — not just a best practice — in regulated environments.

Hybrid identity depends on accurate GC data flowing to the cloud

Microsoft Entra Connect Sync reads GC attributes when synchronizing on-premises identities to Azure AD / Microsoft Entra ID. If GC data is incomplete, stale, or missing attributes due to misconfiguration, hybrid identity objects in the cloud will be incomplete — breaking Entra ID conditional access policies, Teams presence, Exchange Online hybrid flows, and Azure AD application registrations. Getting the GC right on-premises is foundational to every hybrid identity scenario.

Conclusion

The Global Catalog and Universal Group Membership Caching are two solutions to the same fundamental problem: how do you give every domain controller in every location the information it needs to authenticate users and build correct access tokens — without routing every login through a central server over a WAN link that might fail? The GC solves it comprehensively, with full forest-wide directory search capabilities but higher resource overhead. UGMC solves it efficiently, with minimal overhead but scope limited to login resilience only.

The primary DC at the HQ datacenter carries the GC role (and should always have), and branch sites without Exchange deployments should have UGMC enabled to provide login resilience without the overhead of a full GC replica. That combination — GC at HQ, UGMC at branches — is the textbook Windows Server 2025 design for exactly this kind of hub-and-spoke Active Directory topology.

Windows Server 2025 makes both features more capable than ever — with per-user cache refresh controls in UGMC, TLS 1.3 GC connections, and tighter Azure Entra integration. The five labs in this guide give you everything you need to deploy, verify, and monitor both features confidently in a production environment.