Skip to main content

Active Directory Instant Replication

When you activate a role that updates on‑premises Active Directory (for example, adding a user to a group), the change must replicate to the domain controller your apps use. In multi‑site AD topologies, inter‑site replication is often scheduled and can introduce delays. If you need faster end‑to‑end activations across sites, consider enabling instant (on‑demand) replication patterns.

This page outlines safe options you can adopt in your own environment. Use change control and test in a non‑production domain first.

note

This is an operational recommendation to reduce propagation latency. GrantFlow does not change your AD replication settings.

When you might need this​

  • Users activate time‑bound access and must use apps serviced by remote sites
  • Help desk reports “activation succeeded but access still denied” until replication completes
  • Sites with longer WAN replication intervals or busy replication schedules

Options to reduce cross‑site delay​

By default, inter‑site replication is schedule‑based. Many organizations enable change notifications on selected site links so updates flow sooner without waiting for the next interval.

  • Change notifications can increase replication chatter; enable only where needed
  • Keep site link schedules and costs aligned with your network design

Ask your AD team to review and, if appropriate, enable change notifications on the relevant site links. See Microsoft documentation for exact procedures for your Windows Server version.

Capacity and bandwidth

Change notifications send deltas as changes occur. On noisy domains or constrained links, evaluate impact before broad rollout.

2) Trigger on‑demand replication after critical changes​

If you prefer not to change site link behavior, you can explicitly trigger replication for the objects you just modified (for example, the group you added the user to). This keeps replication scoped and predictable.

  • Forest‑wide “blast” (use sparingly):
Replicate all partitions
# Replicate all partitions from the local DC to partners (enterprise/force/partners)
repadmin /syncall /AeP
  • Targeted object replication between two DCs:
Sync a single object between DCs
# Replicate a single object (group or user) from SourceDC to DestinationDC
# Replace values with your own object DN and DC hostnames
Sync-ADObject -Object "CN=VPN-Access,OU=Groups,DC=example,DC=com" -Source "dc1.corp.example.com" -Destination "dc2.remote.example.com"
  • Fan‑out to all DCs in a remote site:
Fan-out to all DCs in a site
# Replicate a specific object to every DC in the target site
$objectDn = "CN=VPN-Access,OU=Groups,DC=example,DC=com"
$sourceDc = "dc1.corp.example.com"
$targetSite = "Remote-Site-1"

Get-ADDomainController -Filter * -SiteName $targetSite |
ForEach-Object {
  Sync-ADObject -Object $objectDn -Source $sourceDc -Destination $_.HostName
}
Practical approach

Many teams combine a short replication interval on critical site links with targeted Sync-ADObject calls after sensitive changes (like privileged group membership).

Verification​

  • Confirm replication health: repadmin /showrepl or Get-ADReplicationPartnerMetadata
  • Validate the change on DCs in the remote site (group membership, effective access)
  • Retest the user’s access path (Kerberos token refresh or re‑sign‑in may be required)

Notes and safeguards​

  • Scope on‑demand replication to only the objects you changed
  • Avoid repeatedly blasting forest‑wide sync during peak hours
  • Document the runbook and train operators if this becomes part of your access workflows

Reference​

See also​

Last updated on