It’s almost impossible to overstate the usefulness of remote desktop access for Windows PCs. Simply put, it lets a user or administrator on one Windows PC, called a client machine, establish a remote session on another Windows PC, called a server or host machine.
Microsoft’s Remote Desktop Protocol (RDP) is the foundation on which various built-in Windows remote access tools rest. This secure network communications protocol supports both the old-school Remote Desktop Connection application and the modern Remote Desktop app, both shown in Figure 1 below.
Using available network connections between client and host via RDP, these programs let the client user open a window that displays some chosen remote desktop. With a remote desktop session up and running, that user can operate the targeted remote desktop almost as if they were sitting in front of it.
Thus, for example, I can sit at my production desktop and access any of the other 11 PCs in my house easily and directly. With some minor exceptions — usually related to applications or services that require direct, physical access to a specific machine (such as a BIOS/UEFI upgrade, firmware tools, and some OEM utilities) — one can do anything to a PC remotely that one can do directly.
Network and support admins find this capability invaluable, particularly if they must access and interact with PCs (including those running Windows Server as well as desktop versions of Windows) in other locations. The ongoing proliferation of “work from home” situations post-pandemic has only increased the value and importance of remote access.
Remote Desktop Connection and Remote Desktop come built into Windows 10 and 11 at no added cost. Thus, while there are plenty of third-party remote access tools readily available, many businesses (especially smaller ones) use Microsoft’s tools as a matter of cost-saving and preference.
See my story “Windows 10’s Remote Desktop options explained” for more details about Remote Desktop and Remote Desktop Connection and how to use them. In this story I’ll focus on what you can do when you encounter problems making a remote connection work.
When, how, and why remote access goes wonky
Remote access hinges on a working network connection between the client and host. Furthermore, it requires that the user have account credentials necessary to operate the remote PC. And finally, the remote access software itself must be properly configured and working.
Thus, remote access problems generally fall into one of four categories — namely:
- Network connectivity or access: RDP can’t establish a session between client and host unless the network is working properly. Such issues are best handled using the built-in Windows Network troubleshooter. Also see the “Troubleshooting connection problems” section of my Windows Remote Desktop explainer.
- The user must be able to identify and access the targeted host using a remote access application. This means that they know the IP address or name of the targeted host and that either one or both of those identifiers gets them to the right PC in their chosen application. I discuss this in more detail in an upcoming section.
- The user must have a valid account on the targeted host, and that host must recognize the account name and password to permit access. In addition, those credentials must work within the chosen remote access program in use. This also comes in for discussion later on.
- The remote access software must itself work properly to provide working connections between client and host. Occasionally, Windows updates will break Remote Desktop Connection and/or Remote Desktop. I’ll explain how to diagnose such issues and work around them later as well.
These various areas may not sound like much, but they cover a pretty broad and interesting range of potential problems and possible resolutions. Microsoft Learn offers a detailed and helpful tutorial on these topics entitled “General Remote Desktop connection troubleshooting.” Other useful Microsoft tutorials in this same vein include “Troubleshoot RDP client connection problems” and “How to use Remote Desktop.”
I won’t cover everything that’s mentioned in those resources. Instead I will focus on a handful of common RDP-related issues that I’ve personally encountered over the past couple of years. Fortunately, most of them are easy to fix without requiring major investments of time and effort. But if what you find here doesn’t help your issue(s), please do consult those references.
Problem 1: Computer name fails to resolve
When docked in an office, laptops may switch from a Wi-Fi network link to a wired network link. When undocked, Wi-Fi usually takes over. In working with Thunderbolt 3 and 4 docks since 2017, I’ve noticed myself unable to use Remote Desktop Connection (RDC) or Remote Desktop (RD) after changing from Wi-Fi to wired or vice-versa.
Over time, I figured out that switching from one interface to another changes the IP address in use. (Each network interface must have a unique IP address on its local area network.) The local DNS server did not update its address tables immediately, so the IP address associated with the computer name reflected the Wi-Fi adapter (when plugging into the dock) or the wired GbE adapter (when undocking and using Wi-Fi instead).
This takes care of itself in 12-24 hours for typical DNS servers, but in the meantime you must use the target PC’s current, working IP address inside RD or RDC to establish a working connection. To see what’s what, a LAN scanning utility can be helpful. I use a free and capable tool called Advanced IP Scanner for that purpose, as shown in Figure 2.
Advanced IP Scanner also shows which interface (and associated IP address) is active when more than one appears (it’s the one that lights up in blue). If a command-line tool like NSlookup <computername> shows an IP address different from the one associated with the active adapter, you’ve found a PC for which you must use its IP address for remote access, at least temporarily.
Problem 2: RDP fails to connect, or connects and then freezes
Sometimes, Microsoft changes something in its remote access software or related Windows registry settings that causes RDP connections to go sideways. I’ve seen this happen three times in the last 18 months with various Windows 11 releases (mostly Insider preview builds in the Dev or Beta Channel, in the interests of full disclosure). The symptoms are immediate and obvious: the RDP connection either opens to a black screen and does nothing, or it opens to the target desktop and closes a second or two later.
This is a good news/bad news scenario. This normally happens after applying an upgrade or update to a Windows PC. If it’s not just your PC affected, news will emerge that “some users experience RDP issues after applying the upgrade.” That’s your clue that you’re among the afflicted… err… affected. You can either live with it and wait for a fix (they usually come pretty quickly, given the importance of working RDP for many, many users and organizations). Or you can roll back the update or upgrade and hang back until Microsoft announces a fix.
Problem 3: RDP logins won’t work
Remember, it takes a valid account (preferably an administrative account) to log in into a remote PC. If something goes wrong with remote login and the associated LSASS (Local Security Authority Server Service), this will stymie your ability to log in using RDP.
Fixes can vary widely for such issues. I’ve successfully used one or more of the following techniques to overcome RDP login failures:
- Set up a local administrator account on the target PC and log into that instead of the Microsoft account (with typical name@domain format) you might otherwise use.
- If you normally log in using a PIN or biometric authentication, a password hash never gets stored in the local password cache. This is what Windows uses for RDP logins, so if a hash isn’t present, you can’t log in. The fix is easy but requires somebody to log in to the target machine using the account name and its associated password. Do this once, and the problem won’t recur.
- Sometimes promoting the account you want to use for RDP login from ordinary user to administrator level will fix RDP credential problems. Obviously, you can do this only if you trust the user not to abuse that level of privilege.
Other fixes that have occasionally helped to address RDP login issues are less frequently necessary. In some cases, I’ve observed that visiting Settings > System > Remote Desktop, turning Enable Remote Desktop off, waiting 30 seconds, and then turning Enable Remote Desktop back on helped. On other occasions, switching from Wi-Fi to GbE, waiting 30 seconds, and then switching back again also helped. Save this for a last-ditch attempt with RDP login troubleshooting, though: it works less often than not.
Problem 4: RDP doesn’t show remote control bar in session window
When you run a remote session in Remote Desktop Connection and set that session to full-screen mode, you see a control bar at the top of the maximized remote session window, as shown in Figure 3.
You can stretch a non-maximized window to fill the entire screen so it looks like full-screen mode. But if you do, the control bar is missing. This happens to me whenever I upgrade my Nvidia graphics driver on my production desktop. The Nvidia driver upgrade stretches the windows to fill the screen but does not maximize those windows. Ergo, no control bar.
This is supremely hard to notice but incredibly easy to fix: just toggle the middle button at the top right of the remote window. Diagnosing this took me an embarrassingly long time and led me into unnecessary troubleshooting exercises.
A general RDP troubleshooting tip
If you run into something not already mentioned in this story (or in the Microsoft tips and tutorials), use your symptom along with your Windows version as a search string in Bing or Google (or your favorite search engine). Thus, you could use something like “RDP black screen windows 10” or “RDP authentication fails Windows 11” and see what comes up. This often provides useful information and occasional fixes or workarounds, especially when you find information from reliable sources such as Super User, Windows 10 Forums, or Windows 11 Forum.
The “last argument of kings” for RDP
King Louis XIV engraved his brass cannon with the motto “Ultima ratio regum.” This translates from Latin to “the final argument of kings.” Thus, cannon served him as a kind of last and final resort for problem solving.
Having been in the situation where I needed remote access now to some specific Windows PC but couldn’t get either RD or RDC to work, I can say from experience that you can usually install and use a third-party remote access package to force a solution. In my case, that was TeamViewer. In your case, it might be AnyDesk, Zoho Assist, or one of the other items mentioned in Keith Shaw’s 2020 Computerworld story “Remote desktop software: 8 enterprise-friendly IT support tools.”
Use one if you must as your final argument. It should work. Then you can switch back when a documented RD or RDC fix emerges.
Copyright © 2023 IDG Communications, Inc.