Introduction

A remote access migration can bring the new NPS or policy tier online while RD Gateway still authenticates sessions against the old one. Users reach the gateway URL, but authorization still depends on the retired NPS server, one gateway works while another still uses the previous policy backend, or remote access fails only after the old server is disabled because CAP or RAP policy, RADIUS integration, and certificate bindings often move in separate steps.

Treat this as an authentication-path problem instead of a generic RDP failure. Start by checking which NPS server, CAP or RAP policy path, and certificate an affected RD Gateway session actually uses, because migrations often validate the new remote access host manually while production gateway flows still rely on older NPS integration.

Symptoms

  • RD Gateway still authenticates against the old NPS policy server after migration
  • Remote users can reach the gateway, but authorization fails only after the previous NPS server is removed
  • One gateway or site uses the new NPS backend while another still uses the old one
  • CAP or RAP behavior looks inconsistent across gateway servers
  • The new policy server is healthy, but live RDP sessions still depend on the retired backend
  • The issue started after moving RD Gateway, NPS, or remote access policy infrastructure

Common Causes

  • RD Gateway still points to the old NPS or RADIUS server for authentication or authorization
  • CAP or RAP policy was updated on one gateway but not another
  • Certificates or gateway bindings still correspond to the previous policy path or host
  • Load balancer, DNS, or farm membership still steers users toward an older gateway configuration
  • Configuration management or golden images keep restoring the retired NPS settings
  • Validation confirmed the new policy server could process requests but did not verify where live gateway sessions actually authenticated

Step-by-Step Fix

  1. Capture one affected RD Gateway login and record the gateway host, NPS target, CAP or RAP path, and certificate it actually uses, because the runtime access path determines where remote-session policy is enforced.
  2. Compare that active gateway authentication path with the intended post-migration design, because one stale gateway setting can keep many users tied to the retired NPS backend.
  3. Review RD Gateway configuration, RADIUS or NPS targets, CAP or RAP policy, certificates, and any gateway farm or load balancer settings for references to the old policy server, because remote access depends on edge, policy, and trust configuration together.
  4. Check each gateway host, farm member, and site separately if behavior differs, because migrations often fix one remote access path while another still uses the previous policy backend.
  5. Update the authoritative gateway and policy configuration so affected sessions authenticate against the intended NPS environment, because deploying the new policy server alone does not retarget existing RD Gateway flows.
  6. Run a controlled remote desktop login and confirm the intended NPS server handles the authentication and authorization decision, because a visible gateway prompt does not prove the right backend approved the session.
  7. Verify the old NPS environment no longer receives RADIUS or policy traffic from migrated gateways, because split remote-access paths can remain hidden while both backends stay online.
  8. Review certificates, shared secrets, and CAP or RAP evaluation if logins still fail, because the destination can be correct while trust or policy mapping still breaks access.
  9. Document which team owns RD Gateway templates, NPS policy, and migration validation so future remote-access cutovers verify the actual authentication backend before retiring the previous server.