In this issue LANGALIST: A better remote desktop connection Additional articles in the PLUS issue PROFILES: Tried, tested, and true: Max Stul Oppenheimer FREEWARE SPOTLIGHT: NotesMan — It’s the simple things ON SECURITY: The other ransomware scam
LANGALIST A better remote desktop connection
By Fred Langa Alas, it’s not the one built into Windows. A remote desktop connection (RDC) lets you access and use a distant PC just as if you were sitting at its keyboard, whether that second device is in the next room or halfway around the world. For yourself, RDC provides a way to access files and apps from anywhere. Need something from your PC back home, when you’re on the road? No problem: Use RDC to connect and send yourself the files you need. For helping others, once you have their permission, RDC gives you a way to manage, maintain, and repair their distant PCs from the comfort of your normal location, saving you travel time and frustration. That’s all good, but the built-in RDC for Windows 8.1, 10, and 11 is actually ancient, XP-era tech with fussy, hit-or-miss functionality. For many users — including me! — there’s a better, vastly simpler, and (still free) alternative. Microsoft should improve or retire RDC
Networking has never been one of Windows’ greatest strengths. For example, it took Microsoft until 1992 to ship an edition of Windows — Windows for Workgroups 3.1 — that had even basic local networking built in, despite the fact that computer networking had been around for decades and the early Internet was already up and running. It would take until 1994 before Windows finally gained complete, built-in local and Internet networking. Microsoft — and Windows — was very late to the game. But by 2001, Microsoft’s desktop networking had matured enough for Windows XP to borrow NT 4’s Terminal Services and expand and rename it as Remote Desktop Protocol, with a front end called Remote Desktop Connection, or RDC. There were two sides to the same RDC tech: Remote Desktop and Remote Assistance. They’re very similar. Remote Desktop was intended for one user to fully access and control two PCs (one local, one remote); Remote Assistance was designed to allow two people (each with an active keyboard and mouse) to simultaneously share and use the remote PC for troubleshooting, collaboration, and problem solving. Sounds like a positive story, right? And it was, back then. Trouble is, except for cosmetics, Windows’ RDC has hardly changed in the two decades that have passed since! (See Figure 1.)
In short, today’s RDC is almost a software fossil, a bit of ancient, simplistic, not-very-configurable networking technology. Still rough-edged after all these years
When Windows RDC works — and to be fair, it usually works on the majority of simple network setups — it’s fine. But when it doesn’t work — and, also to be fair, it does fail in a significant minority of cases! — RDC’s almost black-box nature makes troubleshooting and repair needlessly difficult. It’s almost binary: If RDC works, you’re golden; if it fails, you’re toast. A few days ago, for example, I needed to do maintenance on PCs in different parts of my house. Being a lazy sod, I thought I’d use RDC so I could stay at my main PC and work on the others remotely, rather than running back and forth. I hadn’t used RDC before on my current, simple, peer network, but I’d used RDC hundreds of times over the last two decades on a variety of PCs and networks, and it had usually worked. But not this time. As had sometimes happened in the past, RDC failed — with scant feedback and zero guidance as to exactly what was wrong and what I should do to fix it. Nothing I tried could get it working. All other networking between the two PCs was fine. Both could “see” each other on the network, and I could copy files back and forth, thus proving that the setup, logins, and permissions were all correct. But neither PC could establish an RDC connection to the other. I followed all the official instructions, checked everything that Microsoft, various networking Troubleshooters, and third-party sources said to check. I even uninstalled and rebuilt the complete networking stacks of both PCs, including replacing the network drivers themselves. Nothing helped. Outside of RDC, everything involving the network connections worked fine. But not RDC itself. What a silly, frustrating, waste of time! Grrr. Here’s what did work, the very first try
I was on a deadline, so I bailed out and tried a simple alternative — Google’s free Remote Desktop app. Oddly, although it’s officially called “Chrome Remote Desktop,” it doesn’t require Chrome. Built with open-source code, including Web Real-Time Communication, Google’s Remote Desktop is very widely supported and will run on most of today’s major operating systems, browsers, and smartphones. Here’s Google’s current compatibility list for its Remote Desktop:
Best of all, Remote Desktop (I’ll mostly call it RD from here on out) is super simple. Once I downloaded the small browser extension and PC add-on (the free Chrome Remote Desktop Host app) for each PC — a minute or two apiece — I fired up RD, followed the on-screen instructions (no help files needed), and watched it connect perfectly, the first time, with a full remote-control session (Figure 2). No sweat, no pain, no hassle. It just worked.
You can run the Remote Desktop session full-screen, partial-screen (as shown above), or minimized. Once connected and in the active window, use the remote PC exactly as if you were sitting in front of it. Your keystrokes and mouse movements will be sent to and acted upon by the remote PC. In the meantime, your local PC keeps working normally; switching between the local and remote PC is as simple as an Alt+Tab between windows. RD has other built-in options that give you fine control of the session’s behavior, such as choosing whether system-level input commands (e.g., Ctrl+Alt+Del) should be sent to the remote PC or kept local, whether you also want to send and receive files via the RD connection, and so on. OK, but what about security?
Remote Desktop helps keep things safe through a combination of encryption and multiple passwords (and/or two-factor authentication). By default, RD uses encrypted HTTPS to protect the data traveling between PCs. That’s probably secure enough for routine, casual use, but — same as with any Internet-based communication — you may want additional security for more sensitive data. Personally, I like to use a VPN (Virtual Private Network) to add an extra, independent layer of encryption to my online work; to help obfuscate the type, origin, or destination of the data; and, in this case, to help ensure that even RD’s creators — Google — can’t peek at what I’m doing. To prevent unauthorized access, RD requires the cooperation of two authorized users — one at each PC — to set up the connection. Unattended access is possible after that, but the initial setup requires active user involvement at both ends of the connection, for safety. Anonymous connections aren’t allowed. Identification begins at the PC itself, of course. Both users must be signed in to their own PCs as authorized users (e.g., signed in with a Microsoft account). RD itself also requires its own login using the user’s own Google account (e.g., a free Gmail address). Then, during initial RD setup, the remote PC — the one that’s about to be accessed — will automatically create a temporary, 12-digit, one-time-use access code. That code is shared (by phone, text, email, whatever …) with whoever is about to connect; they must supply RD with the correct code to be allowed to connect for the first time. The code is timed to expire in five minutes, further emphasizing that live, authorized humans must be present at both ends at the time of the initial connection. If time expires, one click allows you to generate a new code, again with that five-minute expiration to ensure that it’s either used immediately or discarded, for safety. After the initial connection, the user of the remote PC will be prompted to replace the one-time code with a user-generated PIN code that can be used for ongoing, subsequent accesses. Thus, starting RD requires passing through three security “gates” — the PC’s own login security, your Google account’s security, and the RD connection’s own one-time access code or ongoing PIN. Then, once RD is up and running, its communication is protected by at least 128-bit encryption — or more, if you’re using additional security such as a VPN. That’s sufficient security for the kinds of RD tasks I perform — and maybe for you, too. Things like running Updates on a distant PC, performing remote diagnostics and repair, moving some files to or from a remote system, and so on. But if you need higher security, there are other options available, as you’ll see in a moment. Easy setup, abundant help, simple removal
RD’s initial setup is easy: On each PC, you go to https://remotedesktop.google.com/ and follow the on-screen instructions. You’ll be asked to download and install a small browser extension, and a very small (less than 50MB) Chrome Remote Desktop Host app. It takes literally just a minute or two. RD’s on-screen instructions are well done — clear and easy to follow — and may well be all you need to zip through the setup. If you do need help, it’s available on Google’s RD help and troubleshooting pages or on various third-party help sites. But I’ll bet you won’t need any help at all! Disabling RD is also easy. You can change an RD access PIN at any time to deny access to whoever has the old PIN. You also can totally remove RD by uninstalling the Chrome Remote Desktop Host app (it uninstalls like any other app). But if RD doesn’t work for you for any reason, or if you want more features and security, there are many alternative remote-connection apps available, both free and paid, as this example Google search shows. Still, for basic remote access, it’s hard to beat Google’s free Remote Desktop: Simple, easy to set up and use, with runs-right-the-first-time reliability. Compared to Microsoft’s RDC, Google’s Remote Desktop is a breeze!
Fred Langa has been writing about tech — and, specifically, about personal computing — for as long as there have been PCs. And he is one of the founding members of the original Windows Secrets newsletter. Check out Langa.com for all of Fred’s current projects.
You’re welcome to share! Do you know someone who would benefit from the information in this newsletter? Feel free to forward it to them. And encourage them to subscribe via our online signup form — it’s completely free!
The AskWoody Newsletters are published by AskWoody Tech LLC, Fresno, CA USA.
Your subscription:
Microsoft and Windows are registered trademarks of Microsoft Corporation. AskWoody, AskWoody.com, Windows Secrets Newsletter, WindowsSecrets.com, WinFind, Windows Gizmos, Security Baseline, Perimeter Scan, Wacky Web Week, the Windows Secrets Logo Design (W, S or road, and Star), and the slogan Everything Microsoft Forgot to Mention all are trademarks and service marks of AskWoody Tech LLC. All other marks are the trademarks or service marks of their respective owners. Copyright ©2022 AskWoody Tech LLC. All rights reserved. |