I85PREP
⌘ K
MSCE study materials
MSCE study resources

Branch Office Authentication Latency After WAN Upgrade

MSCE · Put your knowledge to work in context.

All case studies

Branch Office Authentication Latency After WAN Upgrade

Contoso has a hub site with two domain controllers (DC1, DC2) running DNS and a branch office of 60 users connected by a 40 Mbps MPLS link with 35 ms round-trip latency. The branch previously hosted a read-only domain controller (RODC) that failed two months ago and was never replaced. Since then, users report 20-45 second logon times in the morning, and helpdesk tickets show intermittent failures resolving internal names. The branch has a single /24 subnet and its DHCP scope hands out only the hub DCs as DNS servers. A new file server at the branch is joined to the domain and authenticates against the hub. Management will not fund new hardware this quarter but will approve configuration changes.

1. Diagnose the most likely cause of slow morning logons and propose a configuration-only remediation that does not require new server hardware.

Read the worked answer

The branch has no local authentication endpoint, so every interactive logon traverses the 35 ms WAN to a hub DC. Kerberos ticket acquisition plus group policy retrieval over a constrained 40 Mbps link, compounded by morning logon storms, explains the 20-45 second times.

Configuration-only options:

  1. Enable site awareness: define the branch as an AD site with its /24 subnet, and ensure the branch is associated with the hub site link. Verify with nltest /dsgetdc:contoso.com /force from a branch client that it selects a hub DC consistently rather than crossing site links unpredictably.
  2. Reduce logon work: enable Always wait for the network at computer startup and logon only if policy processing is the bottleneck; otherwise consider Asynchronous policy processing to shorten perceived logon time.
  3. Trim GPO scope: audit which GPOs apply to branch users/computers and remove or block inheritance of unnecessary software-install and folder-redirection policies that pull large payloads over the WAN.
  4. Cache credentials: ensure Interactive logon: Number of previous logons to cache is at least 10 so cached logons work when the WAN is unavailable.

Because no new hardware is allowed, the durable fix (restoring an RODC) is deferred; the changes above reduce but do not eliminate WAN dependency, and this trade-off should be documented.

2. Users report intermittent failures resolving internal names. The branch DHCP scope points only to hub DCs. What should you change, and what risks must you manage?

Read the worked answer

Point branch DHCP clients at DNS servers that are reachable and responsive over the WAN, and validate that those servers host the AD-integrated zones. Options:

  • Keep hub DCs as DNS but confirm the branch's DNS client subnet is associated with the correct AD site so clients prefer the nearest DC/DNS.
  • If latency to hub DNS is the issue, deploy a DNS forwarder or secondary zone on an existing branch server (the new file server can host DNS if it meets requirements) rather than adding hardware.

Risks to manage:

  • Stale records: a secondary zone or forwarder caches data; ensure zone transfer intervals and scavenging are appropriate.
  • Single point of failure: if the branch DNS host fails, clients lose resolution; configure at least two DNS servers in DHCP scope options.
  • Dynamic registration: clients registering against a read-only or secondary zone cannot update records; ensure dynamic updates flow to a writable primary.

Validate with ipconfig /flushdns, nslookup against each server, and dcdiag /test:dns on hub DCs.

3. The failed RODC's computer account still exists in AD. What cleanup and hardening steps apply before any replacement is considered?

Read the worked answer
  1. Reset the RODC account: in AD Users and Computers, reset the RODC computer account password, or delete and recreate it when hardware is available. A stale account with cached secrets is a risk.
  2. Review the password replication policy: confirm the RODC's Password Replication Policy allowed-list contains only the branch user/computer groups that need caching, and audit Advanced view for any credentials currently cached (repadmin /showobjmeta and the RODC's Advanced tab). Purge cached credentials for departed users.
  3. Check DNS records: remove stale A/AAAA and SRV records referencing the dead RODC; run dcdiag /test:dns and verify replication health with repadmin /replsummary.
  4. Sites and services: if the RODC was the only DC in a branch site, correct the site/subnet mapping so clients are not steered to a nonexistent DC.
  5. Document that the branch is currently WAN-dependent and that restoring local authentication is the long-term remediation.