Introduction

A remote access migration can bring the new RD Gateway into service while users still tunnel sessions through the old one. Remote Desktop works for some users but not others, MFA prompts appear from the retired gateway, or sessions fail only after the previous server is shut down because RDP files, connection broker settings, and client-side gateway preferences often outlive the infrastructure change.

Treat this as a gateway-targeting problem instead of a generic Remote Desktop outage. Start by checking which RD Gateway hostname and certificate an affected client actually uses during connection, because migrations often validate the new gateway itself while saved RemoteApp feeds or local RDP profiles still reference the previous endpoint.

Symptoms

  • Remote Desktop clients still connect through the old RD Gateway after migration
  • Users see the retired gateway certificate, prompt, or branding during login
  • One user group reaches the new gateway while another still uses the previous path
  • Remote access fails only after the old gateway is disabled
  • New gateway health checks pass, but real user sessions still depend on the old server
  • The issue started after moving RD Gateway, RemoteApp, or remote desktop infrastructure

Common Causes

  • Saved RDP files or RemoteApp feeds still specify the old gateway hostname
  • Connection broker or published resources still hand out the previous gateway target
  • DNS aliases, external URLs, or SSL certificates still resolve clients to the retired server
  • Group Policy or client-side RDP settings still enforce the old gateway
  • One collection or published app was updated while another still references the previous environment
  • Validation confirmed the new RD Gateway accepted sessions but did not verify what endpoint actual clients launched against

Step-by-Step Fix

  1. Capture one affected connection and record the RD Gateway hostname, certificate, and published resource source it actually uses, because the live access path determines which gateway handles the session.
  2. Compare that active target with the intended post-migration remote access design, because one stale RDP profile or broker reference can keep a whole user group tied to the retired gateway.
  3. Review RDP files, RemoteApp feed settings, connection broker publication, DNS aliases, and Group Policy for references to the old gateway, because RD access routing usually spans broker, client, and name-resolution layers.
  4. Check different user pools, collections, and endpoint types separately if only part of the estate is affected, because migrations often fix one published path while another still serves the previous gateway.
  5. Update the authoritative broker and client-distribution settings so new and existing sessions use the intended RD Gateway, because deploying a replacement server alone does not retarget saved connection data.
  6. Launch a controlled remote session from an affected client and confirm it negotiates through the intended gateway, because a reachable login screen does not prove the right infrastructure is in path.
  7. Verify the old gateway no longer receives tunneled sessions from migrated users, because split remote access can remain hidden while both gateways stay online.
  8. Review MFA integrations, certificate trust, and CAP or RAP policies if sessions still fail, because the target can be correct while authentication or authorization controls still reflect the old environment.
  9. Document which team owns RDP feed publication, broker settings, and migration validation so future remote access cutovers verify the actual gateway used by clients before retiring the previous one.