Network speed and Cached Exchange Mode — diagnostic playbook

Network performance shapes how Exchange Cached Mode feels: latency and packet loss slow interactive updates while bandwidth sets how long bulk transfers take. Start by timing one clear symptom, run a few quick client and network tests, then use the playbook thresholds to choose client fixes, network fixes, or an escalation.

Symptom: what slow Cached Mode looks like and what to time

Direct answer: Reproduce one clear symptom and time it precisely before changing anything. That gives a baseline you can compare after fixes.

Common, measurable symptoms:

• Slow initial sync: profile setup or mailbox rebuild takes hours or stalls. Time to first 1,000 headers and first 100 full items.

• Delayed new mail: messages appear in Outlook seconds or minutes after server delivery. Time from server timestamp to Outlook visibility.

• Folder refresh lag: read/unread flags, moved messages or folder lists update slowly. Time to refresh after a change from another client or OWA.

• Calendar / Free/Busy lag: meeting updates show up late. Time from change on the organizer’s client to visibility in the attendee’s cached client.

• OAB or GAL delays: resolving a new user or OAB download is slow. Time forced OAB download and name resolution.

• Search/indexing differences: server-side search returns different or faster results than the client; local searches for items present in the OST should be immediate.

Timing checklist (use a stopwatch or script):

1. Create or rebuild a profile and record time to first 1,000 headers and first 100 full items.

2. Send a test mail from a server account and record time until it appears in Outlook and until a manual Send/Receive completes.

3. Modify a calendar item from a second account and record time until it appears in the user's Outlook view.

4. Force an OAB download and record completion time.

5. Run a search for a known recent message and record latency.

Record client details: Outlook build, transport (MAPI/HTTP or Graph-based), network type (LAN, VPN, cellular), and managed device status.

Before you start: scope, safe checks and stopping conditions

Direct answer: Confirm scope and permissions, run basic checks, and avoid destructive actions until you have timings and logs.

Scope and preconditions:

• Applies to Outlook in Cached Exchange Mode against Exchange Server or Exchange Online.

• You need permission to enable Outlook logging and capture packets on the client. Admin access is required for tenant/server checks.

Safe checks to run first:

• Confirm you can reproduce the symptom while the user is active.

• Check whether the machine is on VPN; plan to test off-VPN (office LAN or cellular) to separate VPN issues.

• Verify basic Internet services work (web browsing, DNS).

Stopping conditions and protections:

• Do not delete or rebuild OST files until you have recorded timings and exported logs. If you must recreate an OST, close Outlook and move the OST file to a backup location rather than deleting it.

• If captures include personal data, redact or avoid body text and follow privacy policy.

Version checks and fallbacks:

• Confirm Outlook transport: modern clients use MAPI/HTTP or Microsoft Graph; older setups may use RPC over HTTP.

• Check whether split tunneling or forced tunnel affects Exchange traffic routing.

Applicability: which Cached Mode operations use the network and why

Direct answer: Cached Mode serves most reads locally from the OST; the network is used when Outlook needs data not synchronized or when it performs server-side operations.

Operations that hit the network:

• Initial full mailbox sync and downloading attachments.

• Incremental folder sync rounds and small polling transactions.

• New-mail notification via persistent connections (MAPI/HTTP or equivalent).

• Server-side searches and resolving items not in the OST.

• Calendar Free/Busy requests and updates.

• OAB downloads and resolver lookups.

Operations served from the OST (local):

• Reading synchronized messages, opening cached attachments, and client-side indexed searches for items present in the OST.

How network metrics matter:

• Latency: many small requests suffer from high RTT, slowing interactive updates.

• Bandwidth: large transfers (initial sync, attachments, OAB) need throughput; low bandwidth lengthens these.

• Packet loss and jitter: cause retransmits, TLS renegotiation or broken long-lived connections, affecting responsiveness and bulk transfers.

• Practical note: Exchange Online and on-premises behave similarly from the client side; test the actual endpoints your clients reach.

Fix: step-by-step diagnostic flow with tests, traces and decision branches

Direct answer: Reproduce the symptom, run quick reversible checks, collect focused traces, then apply low-risk fixes and re-verify.

1. Reproduce and record

1.1 Reproduce one symptom and record exact steps and timings from the Symptom checklist.

2. Quick safe triage (fast, reversible checks)

2.1 Check Outlook connection status and note transport and server. Collect logs if Outlook shows Disconnected or Adapting.

• Open Outlook, Ctrl‑right‑click the tray icon → Connection Status.

2.2 If on VPN, repeat the reproduce test from office LAN or a cellular hotspot. If it disappears off-VPN, the VPN or routing is the likely cause.

2.3 Test with Safe Mode or a clean profile to rule out add-ins and corrupted profile state.

3. Network reachability and basic latency/loss checks

3.1 Ping the Exchange endpoint your client uses and a public low-latency host to compare RTTs.

3.2 Run a TCP connect test to the Exchange endpoint port 443 to measure handshake time.

time bash -c '</dev/tcp/outlook.office365.com/443' || echo 'connect failed'

3.3 Use traceroute or tracert to find high-latency hops between client and Exchange endpoints.

3.4 If available, run iPerf3 to measure throughput. If no test server exists, focus on latency and loss instead.

4. Capture client-side logs and packet trace

4.1 Enable Outlook logging (File → Options → Advanced → Enable troubleshooting logging) and reproduce for 1–2 minutes.

4.2 Capture a packet trace with Wireshark or tcpdump while reproducing. Limit capture to the reproducer window and Exchange endpoint IPs.

5. Server/tenant checks (admin)

5.1 Check Exchange or Microsoft 365 service health, mailbox throttling logs, and recent incidents.

5.2 Confirm tenant-level policies that affect routing (Conditional Access, forced tunnel) and whether large shared mailboxes are set to cache.

Decision branches (how to interpret results):

• High RTT (>150–200 ms) to Exchange endpoints with slow interactive operations: focus on routing or VPN path improvements.

• Sustained packet loss above 0.5–1% or visible TCP retransmits: treat as network reliability and escalate to network/ISP.

• Bandwidth limits with low RTT and negligible loss: initial syncs will be slow; consider limiting cache scope, scheduling syncs, or increasing link capacity.

• Client logs showing OST corruption, repeated ItemSync errors, or reindexing while the network looks healthy: focus on OST/profile repair and AV exclusions.

When to stop and avoid risky actions:

• Do not recreate or delete OST until you have a confirmed server copy and exported logs. If needed, move the OST to a backup location instead of deleting it.

Verify: expected outputs and thresholds that indicate a network bottleneck

Direct answer: Use thresholds as practical signals: latency under 50–100 ms feels responsive; persistent high RTT, packet loss, or low throughput point to the network.

Thresholds and signs:

• Latency: interactive folder syncs and calendar queries feel responsive under 50–100 ms RTT. RTT consistently above 150–200 ms makes many small operations sluggish.

• Packet loss: sustained loss above 0.5–1% causes retransmits and delays; loss above 2% usually disrupts push or long-lived connections.

• Bandwidth: estimate OST size and divide by your desired sync window. Example: a 10 GB initial sync over sustained 10 Mbps throughput takes many hours.

• Packet trace signs: SYN retransmits, duplicate ACKs, or repeated TLS renegotiation during the reproducer window indicate path reliability problems or middlebox interference.

Evidence for network root cause:

• Ping/traceroute shows a hop or ISP segment with large, variable latency or packet loss during measurements.

• Wireshark/tcpdump shows TCP retransmits and duplicate ACKs correlated with slow sync timestamps.

• Outlook logs show normal sync cycles but long durations aligning with high RTT or loss periods.

What to include when escalating:

• Timed symptom records, Outlook version and transport, ping/traceroute outputs, packet capture with timestamps, and Outlook logging excerpts. Show tests from multiple networks when possible.

Prevent: prioritized mitigations and when to escalate

Direct answer: Start with low-risk client fixes, then fix network path problems, and only then change server or tenant settings or escalate.

Client-level mitigations (lowest disruption)

1. Reduce cache scope: set the sync slider to cache fewer months or exclude very large folders.

2. Exclude OST and Outlook executables from real-time antivirus scanning per vendor guidance.

3. Test a clean Outlook profile or launch Outlook in Safe Mode to rule out add-ins.

4. Enable or confirm MAPI/HTTP where supported because it uses persistent connections that handle flaky paths better than legacy RPC.

Network-level mitigations (next priority)

1. Prefer direct Internet egress for Exchange Online traffic rather than hairpinning through MPLS/VPN; enable split tunneling when policy allows.

2. Fix routing issues: address a high-RTT hop, remove a faulty ISP peering, or request an improved route from the provider.

3. Use SD‑WAN to steer traffic to the best edge and fail over around problem paths.

4. Apply QoS only when it protects interactive traffic; measure before and after.

Server/tenant mitigations and escalation criteria

1. Avoid caching very large shared mailboxes; configure access to those mailboxes in online mode when appropriate.

2. If multiple users show the same reproducible issue from different networks and captures point at Microsoft endpoints or tenant routing, open a support case with your provider or Microsoft with captures and steps.

3. For recurring wide-scale delays, review tenant egress strategy and Microsoft 365 network guidance. Check vendor docs for endpoint or routing changes before acting.

When to escalate to vendor support:

• You have reproducible steps, packet captures showing loss or retransmits to Microsoft endpoints, Outlook logs with long sync durations, and the issue occurs from multiple client networks.

How to prove a non-network cause (OST, AV, add-ins, server throttling)

Direct answer: Check AV, add-ins, the profile/OST, and server-side throttling in that order, using the least disruptive tests first.

1. Antivirus and endpoint protection

1.1 Temporarily disable real-time scanning for the Outlook process and the OST directory (or apply vendor-recommended exclusions) and reproduce the symptom.

• Expected: if AV caused delays, interactive actions improve while scanning is disabled. If no change, re-enable scanning and proceed.

2. Add-ins and profile corruption

2.1 Launch Outlook in Safe Mode and reproduce the symptom.

• Expected: if an add-in caused the slowdown, performance improves in Safe Mode.

2.2 Create a clean profile and point to the same mailbox; reproduce the symptom.

• Expected: if the profile or OST was corrupted, a clean profile behaves differently. If delays remain on a different network, the network is likelier.

3. OST corruption or reindexing

3.1 Check Outlook logs for repeated resyncs, ItemSync errors or reindexing. If present, move the OST to a backup folder and let Outlook rebuild only after you have evidence rebuilding is necessary.

4. Server-side throttling or service issues

4.1 As an admin, check Exchange throttling logs, service health, and telemetry for spikes correlated with the user’s timeframe.

How to decide:

• If performance improves off-VPN or from a different network while the same OST/profile behaves poorly on the original path, the network is the primary suspect.

• If performance is poor even on a fast direct Internet link and packet captures show little loss and low RTT, investigate OST corruption, AV, add-ins, or server-side throttling next.

Verify a fix worked

Direct answer: Repeat the timed reproduce steps and compare before/after values to confirm improvement.

1. Re-run the timed actions from the Symptom checklist and compare values.

2. Expected results:

• Latency fixes: RTT drops into the 50–100 ms range and interactive updates complete noticeably faster.

• Packet-loss fixes: packet loss falls below 0.5% and traces show fewer retransmits.

• Bandwidth fixes: measured throughput during an initial sync approaches the available link rate and sync time shortens.

3. If the issue persists, collect a fresh packet capture and Outlook logs during the reproduce and escalate with the evidence package.

When to change architecture or accept trade-offs

Direct answer: Change architecture or accept trade-offs only after measuring and exhausting low-risk fixes.

• Use Online Mode (no caching) for users who need occasional mailbox access and suffer long initial syncs on low-bandwidth links, knowing it increases server load and read latency.

• Avoid caching very large shared mailboxes; provide access via delegated online mode or Microsoft-recommended sharing techniques.

• If many remote sites have poor routing to Microsoft endpoints, consider changing WAN design (direct Internet egress, SD‑WAN, or different ISPs) and test impact first.

Check vendor guidance and tenancy routing requirements before making large architecture or licensing changes.

Conclusion

Direct answer: Pick a representative user, reproduce the symptom and collect timings, then run quick triage tests (connection status, VPN check, Safe Mode). Capture a short packet trace and Outlook logs while reproducing. Apply low-risk client fixes first (reduce cache scope, AV exclusions, clean profile), run a simple route test off the VPN, and escalate to network/ISP or Microsoft with the evidence package if captures show high RTT or packet loss.