You cannot force an instant GAL refresh in Exchange Online; directory changes are usually available in the service within minutes, but Outlook and mobile clients may keep showing old details until they sync or rebuild their offline address book. If you treat every delay like an Exchange Online problem, you waste time chasing the wrong layer and leave users seeing stale names, titles, or addresses. This guide separates server-side address list updates from Outlook cache and OAB timing, and shows what admins can change versus what clients control.
Exchange Online Update GAL: Why New Users Don't Appear and How to Fix It
What the GAL is and why new users appear late
You cannot force an instant GAL refresh in Exchange Online. Directory changes usually reach the service within minutes, but Outlook and mobile clients can keep older details until they sync or rebuild their offline address book. If you treat every delay like an Exchange Online problem, you waste time on the wrong layer and leave users seeing stale names, titles, or addresses. This guide separates server-side address list updates from Outlook cache and OAB timing, and shows what admins can change versus what clients control. Microsoft documents that address book and GAL-related changes are not immediate for all clients, and cached-mode Outlook depends on offline data refresh cycles rather than a live lookup alone. See Microsoft Learn on address list update timing and Offline Address Book generation and download behavior.
The Global Address List is the organization-wide address list users browse for people, mail contacts, and groups. In Exchange Online, a new recipient can exist in the directory before it appears in every client view. That gap usually comes from one of four places: directory data, recipient filter scope, Offline Address Book generation, or Outlook cache behavior. For related troubleshooting, see directory sync troubleshooting and OAB management.
What you'll need
- Exchange Online PowerShell access with rights to read recipient and address list settings.
- The new user’s display name, primary SMTP address, and the OU or sync source that created the object.
- An Outlook client in both cached mode and online mode, if you can test from a desktop.
- Access to Microsoft 365 admin or synchronization tools if the account comes from a synced directory.
Check the directory record first
- Open Exchange Online PowerShell and run Get-Recipient -Identity user@domain.com.
- Confirm the object exists, has the expected mailbox or mail user type, and shows the correct address.
- Check the user’s visible properties in Entra ID or the source directory if the object is synced.
If the record is missing here, the GAL is not the problem yet. A recipient that does not exist in the directory cannot appear in any address list.
Check recipient filters and scope
- Run Get-GlobalAddressList and inspect the filter for the custom GAL.
- Compare the new user’s OU, recipient type, company, or custom attribute against that filter.
- If the GAL is scoped to one OU, confirm the user was created in that OU or matches the filter rule.
Say your GAL is filtered to one OU and the user was created in a different OU. The directory record may be valid, but the address list rule excludes it. That is a scope issue, not a refresh issue.
Check directory synchronization timing
- Open the sync tool or admin center and confirm the last successful directory sync completed.
- Verify the new user reached Microsoft 365 with the correct attributes before you retest the GAL.
- If the object is still absent in the cloud directory, wait for the sync cycle or trigger the directory sync process used in your tenant.
Suppose the source directory created the account only a few minutes ago, but synchronization has not finished. Exchange Online cannot list a user it has not received yet. In that case, the delay is upstream of Exchange.
How do I force an Exchange Online GAL update?
You can force a GAL regeneration in on-premises Exchange with PowerShell, but Exchange Online does not give tenant admins the same manual regeneration control for the service-side GAL. In Microsoft 365, the practical path is to verify the object, confirm filter scope, and then wait for the service and clients to process the change. Microsoft’s Exchange Online cmdlet guidance does not provide a tenant-side way to force a true service-wide GAL rebuild the way on-premises Exchange can. For the closest operational guidance, review Microsoft Learn on Update-GlobalAddressList and note the on-premises scope of that cmdlet.
What Update-GlobalAddressList does on-premises
The Update-GlobalAddressList cmdlet is a PowerShell command for Exchange management tasks. In on-premises Exchange, it can regenerate a GAL so filtered membership updates faster. That behavior does not map one-for-one to Exchange Online, where Microsoft manages the service-side generation and publication pipeline.
What Exchange Online admins can and cannot force
- Use Get-Recipient to confirm the user exists in the cloud directory.
- Use Get-GlobalAddressList and related recipient filter checks to confirm the user belongs in the list.
- Change the source attribute or scope if the filter excludes the user, then wait for the service to process the change.
A manual PowerShell command can still matter, but mostly as a verification and correction tool in Exchange Online. It can confirm the recipient and its filter path. It cannot guarantee that every Outlook client will refresh at the same moment.
If that didn't work, try this next: check whether the recipient is hidden from address lists, excluded by a custom attribute, or still waiting on directory sync. Those are the common blockers after a basic GAL check passes.
Why are new users not showing in the GAL yet?
The usual causes are missing directory data, filter mismatch, or sync delay. If the user exists in Exchange Online but still does not appear in a custom GAL, the filter is usually the fastest place to look. If the user does not exist in the cloud directory yet, the sync path is the bottleneck.
Validate the filter and membership logic
- Run Get-GlobalAddressList | Format-List Name,RecipientFilter.
- Compare the user’s attributes to the filter terms, especially OU-based scope and custom recipient properties.
- Adjust the filter or move the object only if the business rule allows it.
A custom GAL filtered to a specific organizational unit can miss a new user even when everything else is healthy. The filter is working as designed. The fix is to make the object match the rule, not to wait for a different kind of refresh.
Picture a tenant where the new hire is licensed and mail-enabled, but the GAL filter only includes one OU. The mailbox exists, the directory sync succeeded, and the user still does not appear. That points to scope, not a broken GAL.
Does Outlook cached mode delay changes?
Yes. Cached mode can delay what users see because Outlook keeps a local copy of address book data. Online mode is a better test for live directory visibility, but even then, the Offline Address Book and client-side cache can still create lag for some address lookups and name resolution. Microsoft notes that Offline Address Books are generated on a schedule and then downloaded by clients, so visibility can lag behind the directory change itself.
Test online mode before touching the server again
- Open Outlook and go to File > Account Settings > Account Settings.
- Select the account, then check whether Use Cached Exchange Mode is enabled.
- Temporarily test in online mode, then search the GAL again.
If the user appears in online mode but not in cached mode, the server-side directory is already ahead of the client. That means you are dealing with local Outlook data, not an Exchange Online directory fault.
Understand OAB lag versus live GAL data
The Offline Address Book is separate from the live GAL. Cached Outlook clients use the OAB for some address data, so a mailbox can see older information until the OAB is rebuilt or the client downloads a newer copy. Microsoft Learn explains that OAB generation and distribution are scheduled processes, not instant pushes, which is why cached clients can lag behind the live directory. See Offline Address Book generation schedules for the timing model.
How I tested
The result was consistent: when the object existed but did not appear everywhere, the blocker was usually filter scope or cached data, not a missing mailbox.
Troubleshooting matrix
This matrix separates the most common causes of a missing user. Use it to identify the layer before you try any fix. That keeps you from waiting on Outlook when the real issue is recipient scope, or changing the filter when the user has not synced yet.
| Symptom | Likely layer | How to verify it | Can the admin force a faster update? |
|---|---|---|---|
| User exists in Entra ID but not in Exchange recipient results | Directory sync | Run Get-Recipient; check the sync status in the tenant admin tools | Sometimes, if your sync tooling allows a manual sync cycle |
| User exists in Exchange but not in a custom GAL | Recipient filter | Run Get-GlobalAddressList and compare filter terms to the user’s attributes | Yes, if you can adjust the object or the filter |
| New user appears in Outlook online mode but not cached mode | Outlook cache | Switch to online mode and compare results | No, the client must refresh its local data |
| New user appears in Outlook after waiting for address book download | OAB | Check whether Outlook is using cached mode and whether the address book refreshed | Not instantly in Exchange Online; clients must download the newer OAB |
| A manual command fixed it immediately on-premises | Exchange directory | Confirm whether the environment is on-premises or Exchange Online | Yes on-premises with Update-GlobalAddressList; not the same in Exchange Online |
Common mistakes
The biggest error is treating every visibility delay as a single server problem. Exchange Online, the OAB, and Outlook cached mode do not share one timer. If you check only one client, or only one directory layer, you can miss the actual blocker.
- Do not assume the GAL is broken if a cached Outlook client is stale.
- Do not assume a manual PowerShell command in on-premises Exchange applies the same way in Exchange Online.
- Do not stop at the first sync check if the GAL uses an OU-based filter.
- Do not rely on one mailbox view; compare online mode and cached mode.
A common first-timer mistake is to see a missing user in one desktop client and restart Exchange troubleshooting there. If online mode shows the user and cached mode does not, the client cache is the slow layer.
Frequently asked questions
How often does Exchange Online GAL update?
There is no fixed tenant-wide interval to rely on. In practice, directory changes usually appear in the service within minutes, but the visible result depends on the recipient object, any custom filter, and whether Outlook is reading live data or a cached address book.
Does Outlook cached mode delay GAL changes?
Yes. Cached mode can show stale address data until Outlook refreshes its local cache or downloads newer offline data. Test with File > Account Settings > Account Settings and compare the result in online mode before changing Exchange settings again.
What is the difference between GAL and OAB update timing?
The GAL is the server-side list. The OAB is the client-side download used by cached Outlook. A recipient can be present in the GAL while still missing from a cached client until the OAB updates and Outlook reads the newer file.
Can I update the Global Address List with PowerShell?
Yes, in on-premises Exchange, Update-GlobalAddressList can regenerate a GAL. In Exchange Online, PowerShell is still useful for checking recipient state and filters, but it does not give the same manual rebuild control over the service-wide GAL.
Sources
- Microsoft Learn: Address list update behavior
- Microsoft Learn: Offline Address Books
- Microsoft Learn: Update-GlobalAddressList