Connect to a Windows VPS and troubleshoot Remote Desktop

Confirm the Windows service and recovery console
Remote Desktop lets you use the graphical desktop of a Windows VPS. You need a Windows edition that supports incoming Remote Desktop connections, the correct account and a permitted network path. This guide does not convert a Linux service into Windows or include a Windows licence.
Find the assigned public address and login details in your service information. Check that the VPS is powered on and use its browser console to inspect the operating system if Remote Desktop fails. Keep that console available before changing authentication or firewall settings. Never post the machine password or a console launch token in a public message.
Check the server settings from the console
In Windows settings, confirm Remote Desktop is enabled. The exact navigation varies between supported Windows Server releases. Check that the intended account is permitted to sign in through Remote Desktop; local policy or domain policy can still deny access even when a user belongs to an allowed group.
Keep Network Level Authentication enabled. Use a current, updated Remote Desktop client. If an authentication error occurs, verify the username format, password, account lockout state and applicable user rights. Do not turn off authentication protections or weaken security policy to bypass an unexplained login failure.
A local account and a domain account are different identities. Use the account issued for this machine, and check that its password has not expired or been changed elsewhere. A saved credential in your client can continue submitting an old password after a reset.
Test the network path
From a Windows client with PowerShell, test the intended address and configured TCP port. The usual Remote Desktop port is 3389, but your service may use a different approved configuration:
Test-NetConnection -ComputerName server.example -Port 3389
Replace the example hostname with the assigned address. Inspect 
TcpTestSucceeded. A failed ping alone is inconclusive because ICMP may be filtered. A successful TCP test confirms reachability to that port, not that your credentials or full Remote Desktop session will work.
If TCP fails, compare the server's listening port, Windows Firewall rule and any upstream firewall. Scope access to your trusted source addresses or an agreed VPN. Do not disable the whole firewall or expose every port. If your source address changes, update the permitted management source deliberately.
Inspect a refused or disconnected session
Check Remote Desktop Services and the relevant Windows event logs at the failure time. Distinguish a network timeout from an authentication rejection or a session that opens and immediately closes. Record the client error code and whether the problem affects one user or every permitted user.
Review recent updates, pending restarts and available resources. A machine that is unresponsive in both console and Remote Desktop needs a broader guest investigation. Do not repeatedly power-cycle it while applications are saving data. Restarting Remote Desktop Services can interrupt sessions, so coordinate that step rather than using it as a first test.
Verify access and retain secure management
After a targeted fix, open a new connection and confirm the expected account and desktop. Recheck firewall scope and keep strong unique passwords. Consider VPN or gateway access rather than leaving RDP broadly exposed.
If you need CloudExa support, include the service ID, timestamp, source network, TCP-test result and redacted client error. Keep passwords out of screenshots. Use the console recovery route if a firewall or password change removed your remote access; a reinstall is not required just because RDP cannot connect.
Further reading
Microsoft Remote Desktop access
TCP connectivity tests
RDS connectivity investigation
Authentication and user rights