The Remote Desktop of the Windows Server built on Nutanix suddenly became unreachable.

A sudden RDP outage that is fixed only after moving the VM to another Nutanix node points most strongly to a network path issue rather than a Windows Server configuration issue.

The documented RDP troubleshooting split is:

1. Check whether the problem is on the server itself.
   • If the server is running and console access works, test RDP locally with mstsc to localhost.
   • If localhost works, the RDP-TCP listener is likely working and the issue is probably network-related.
2. Check network connectivity to TCP 3389.
   • From a machine in the same network, run:

          Test-NetConnection -ComputerName <server-name-or-ip> -Port 3389 -InformationLevel Detailed
     

   • If TcpTestSucceeded is False, the issue is connectivity, firewall, routing, or another network element blocking RDP.
3. Check firewall and filtering.
   • On the server, verify Remote Desktop - User Mode (TCP-In) and UDP-In inbound rules are enabled in wf.msc.
   • Also check whether antivirus or other network elements are interfering.

Based on the behavior described:

• Rebooting the VM and rebooting from inside Windows did not help.
• Migrating the jump server to another Nutanix node did help.

That pattern does not match a persistent Windows-side RDP listener failure as closely as it matches a node-specific network problem affecting inbound RDP traffic. In the documented flow, this falls under incorrect network configurations or other network elements restricting traffic.

Possible causes supported by the troubleshooting guidance are:

• a temporary network connectivity issue on the original host path
• firewall or filtering behavior affecting TCP 3389
• another network element restricting RDP traffic
• less likely, an intermittent server-side condition that cleared only after the migration changed the effective path

If the issue happens again, the most useful way to isolate it is:

1. Confirm the VM is running and accessible by console.
2. From the server console, test mstsc to localhost.
   • If that works, focus on network path troubleshooting.
3. From the jump server or another machine in the same network, run Test-NetConnection to port 3389.
   • True = no basic connectivity issue; then check server configuration, roles, or port conflicts.
   • False = network path, firewall, or filtering issue.
4. On the server, verify Windows Firewall RDP rules are enabled.
5. Check whether any AV product is affecting RDP.
6. If the listener is working and connectivity still fails, escalate to the platform/network team or Microsoft Support.

A few server-side causes are also documented, but they fit the symptoms less well here:

• another process taking port 3389 instead of TermService
• problems with the RDP self-signed certificate
• unnecessary RDS roles or RDS role misconfiguration
• intermittent TCP port exhaustion, especially if the issue appears after the server runs for several days and a restart temporarily fixes it

Since migration to another Nutanix node was the only action that restored access, the strongest conclusion is that the original node or its network path was the trigger, while Windows itself was likely still functional.

References:

• Remote Desktop can't connect to the remote computer
• "Remote Desktop cannot verify the identity of the remote computer" when connecting to a remote machine