gateway issue - cluster setup

Hi merkol​,

A consistent ~50 second timeout that hits only SharePoint, on only the new server, usually points to something the network test does not exercise: the SharePoint calls are made by the mashup container running under the gateway service account, often to more hosts than the test covers (sign-in, SharePoint tenant, CDN), and over a path that may differ per data center (TLS inspection, WPAD/proxy auto-detect, IPv6). A few targeted checks:

1. Test SharePoint as the gateway service, not as your admin user. Run this on Server 2 in a shell started as the service identity (or SYSTEM via PsExec -s as a close approximation):

$hosts = "login.microsoftonline.com","<tenant>.sharepoint.com","<tenant>-my.sharepoint.com"
foreach ($h in $hosts) {
  $sw = [Diagnostics.Stopwatch]::StartNew()
  try { Invoke-WebRequest "https://$h" -UseBasicParsing -TimeoutSec 60 | Out-Null; "OK  $h  $($sw.Elapsed.TotalSeconds)s" }
  catch { "ERR $h  $($sw.Elapsed.TotalSeconds)s  $($_.Exception.Message)" }
}
Resolve-DnsName <tenant>.sharepoint.com          # compare IPv4/IPv6 answers with Server 1
netsh winhttp show proxy                          # machine-level proxy used by services

If one host takes ~20-50s before succeeding, that is your timeout: typically IPv6 being tried first and blackholed, WPAD auto-detect waiting, or an SSL-inspecting device in the new DC that SharePoint traffic goes through.

2. Compare TLS inspection between data centers. If the new DC breaks and re-signs TLS, add the SharePoint/Microsoft 365 endpoints to the inspection bypass list (Microsoft publishes them as the "Optimize/Allow" Microsoft 365 endpoint categories).

3. Keep production stable meanwhile. In the gateway cluster settings, turn off "Distribute requests across all active gateways in this cluster" (or set Server 2 to disabled for now), so SharePoint refreshes keep going to Server 1 while you test.

So my overall approach would be:

Route traffic to Server 1 (disable distribution / member) for now
-> On Server 2, time each SharePoint-related host as the service identity
-> Compare DNS (IPv6), WinHTTP proxy and TLS inspection with Server 1
-> Bypass inspection / fix proxy for M365 endpoints
-> Re-enable Server 2 and test a SharePoint refresh

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.