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

Question

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

佐々木駿 20

When I tried to connect to a Windows Server 2022 Standard Evaluation built on Nutanix via Remote Desktop, the connection suddenly became impossible. Rebooting the server a few times solved the issue, but what could have caused it?

For troubleshooting, I tried:

Rebooting the virtual machine on Nutanix
Logging into the server and rebooting after ①
Migrating the jump server to another Nutanix node after ①

Interestingly, the problem was only resolved with ③.

0 comments

2 answers

Your answer

Answer 1

Hi 佐々木駿,

In a Nutanix cluster, virtual machines communicate through each node's virtual switch, such as Open vSwitch on AHV. When a node develops a stale Address Resolution Protocol (ARP) cache entry or a hung connection-tracking state, TCP port 3389 traffic between hosts is silently dropped. Migrating the jump server moved its virtual network adapter to a healthy switch on the new host and broadcast a Gratuitous ARP announcement, flushing outdated switch forwarding tables. Earlier reboots of the Windows server occasionally helped because restarting reloads the Nutanix VirtIO network driver (C:\Windows\System32\drivers\netkvm.sys) to broadcast fresh network announcements and clears the TCP table if a software leak exhausted ephemeral outbound ports (logged in C:\Windows\System32\eventvwr.msc under Windows Logs\System as Tcpip Event IDs 4227 and 4231).

Windows Server 2022 also has a known bug where Remote Desktop sessions using UDP port 3389 alongside virtual adapter offloading can intermittently hang during the security handshake with client error 0x4 or Schannel error 0x80090304. If you encounter an unpatched UDP transport bug on your current build, install the latest Cumulative Update via Windows Update or wait for an official Microsoft fix. As a supported interim step, run C:\Windows\System32\gpedit.msc, navigate to Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections, and set the Select RDP transport protocols policy to use only TCP transport.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN

佐々木駿 20 Reputation points

2026-10-02T04:20:59.18+00:00

Hello, VPHAN,

Thank you very much for your response.

Based on your response, we contacted Nutanix to inquire about the logs that should be checked. They informed us that flushing the Open vSwitch forwarding table and sending GARP packets are normal network operations and are not recorded in the logs by default. They also explained that even if TCP port 3389 traffic had been dropped without a response, packet captures or similar monitoring would have needed to be configured in advance, making it difficult to investigate unless the issue recurs.

On the other hand, Nutanix pointed out that, according to the event logs on the affected Windows system, timeouts occurred in various services, including local services unrelated to the network, such as Schedule (Task Scheduler) and Spooler (Print Spooler).

The Microsoft Remote Display Adapter driver subsequently crashed. However, they explained that even if AHV had been in a situation where packets were dropped, it would not normally cause the display driver in the guest OS to crash.

Therefore, they believe that this was more likely an issue occurring within the guest OS rather than a network problem.

Incidentally, it appears that Windows Server 2022 (KB5122882), which addresses known Remote Desktop instability, was released in September 2026. Based on the results of our investigation so far, is it possible that this issue was fixed by KB5122882?

Answer 2

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:

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.
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.
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:

Confirm the VM is running and accessible by console.
From the server console, test mstsc to localhost.
- If that works, focus on network path troubleshooting.
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.
On the server, verify Windows Firewall RDP rules are enabled.
Check whether any AV product is affecting RDP.
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: