RDP outdated entry in the DNS cache How to fix it

Server Management Service

Sometimes, in the process of establishing connection to an RDS (Remote Desktop Server) farm running Windows Server 2008 R2 using the standard RD client (mstsc.exe), Windows users experience an error message such as "RDP outdated entry in the DNS cache".

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to fix Windows related errors.
In this context, we shall look into the main causes of this issue and how to resolve it.

What triggers "RDP outdated entry in the DNS cache" issue?

When this problem occurs, you will see an error message such as this;

The connection cannot be completed because the remote computer that was reached is not the one you specified. This could be caused by an outdated entry in the DNS cache. Try using the IP address of the computer instead of the name.

The configuration of the RDS farm comprises 3 servers running Windows Server 2008 R2 with RD Connection Broker used to distribute workload between the terminals and to reconnect to the current sessions.

Since this error occurs from time to time suggests that the problem is with one of the servers of the farm.

How we resolve the problem ‘RDP outdated entry in the DNS cache’

To fix this issue, start by running the server record registration in DNS. To do this, execute the following command;

ipconfig /registerdns

Next, reset the local DNS cache on the client in a couple of minutes by running the following command;

ipconfig /flushdns

The reduce the level of the protocol used to encrypt the RDP connection from SSL to RDP Security Layer.
This setting is located in "Remote Desktop Session Host Configuration >> Microsoft RDP 7.1 >> Properties >> Security Layer".

In our case, we discovered that in the configuration, the Negotiate method is used. It uses automatic switching from TLS to RDP Security Layer if the client does not support the first method.
Additionally, the time on the problem server differs from the domain controller time. Moreover, we found that this server was located on the VMWare ESXi host at the wrong time. Also, the option of time synchronization with the host hypervisor was enabled in VMWare Tools settings.

So we disabled ESXi synchronization and restarted Windows Time Service to synchronize time with the DC by running the commands;