I had an interesting interaction with Kari today. I found myself trying to get around a problem in remoting into one Skip Ahead Insider Preview PC from another PC running the same OS. No problems getting from other Windows builds into the target PC. Only problems getting from one Skippy PC to another (see my blog post on this topic Windows 10 Workaround Versus Fix). Quite naturally, I turned to Kari for input on how to address this issue, and he came up with a great workaround. By switching from a Microsoft account (often abbreviated MSA) to a local account for the RDP login, I was able to get from one Skippy PC to another without further ado. But something interesting happened along the way . . .
It drove me more than a little bit wild to see RDP reject a known, good working password when trying to fire off a session. Kari offered a great workaround: use a local account instead of an MSA. It worked!
Why say Windows 10 Is an Always-Moving Target?
Once upon a time, there were no Microsoft accounts. In fact, RDP prefigures such accounts by as long as 15-20 years. I can remember using RDP back in the NT4 days, which came along in 1996. If memory serves it was already available in Windows NT 3.51 which dates back even further. The earliest incarnation of MSA was called Microsoft Passport (it’s also been known as .NET Passport, Microsoft Passport Network and Windows Live ID). As far as I can tell, it became available around 2007.
I’ve been using an MSA to log into RDP sessions since I started getting serious about using them, back in the Windows 8 or 8.1 era (around 2012 or thereabouts). But when I told Kari what I was doing today, he chatted that he needed to make some screenshots to show me why I was having a problem. Soon thereafter, he candidly confessed that he was unaware that you actually could use an MSA for an RDP session, and had planned to show me this just doesn’t work at all.
Like me, Kari’s been using RDP since before MSAs became available. Unlike me, he didn’t try to get an MSA to work for an RDP login, so he remained unaware that these worked in any way, shape or form. Turns out that they haven’t always worked with RDP and that for some time after MSAs became available, users had to use the “local account equivalent” of an MSA — or a real, honest-to-gosh local account — to establish a working RDP session. But indeed they have worked for some time. I’ve used them every day myself for at least the last 6 or 7 years.
This just goes to show that there’s an awful lot to know and understand about Windows 10 and its inner workings. I can’t say I was pleased to learn that Kari was mistaken about his understanding of RDP logins, but I took heart from his efforts to test the workability of MSA logins before chewing on me for trying something that didn’t used to work. Before he did that, he checked and learned to his suprise that an MSA does in fact work for an RDP session in current Windows 10 versions. That’s one of the things that makes Kari such a great Windows 10 expert and researcher: he never claims or presents anything without checking it against the OS first and foremost. That’s something that I believe in, too, and that we make a hallmark of our content here at Win10.Guru.
And because Windows 10 keeps changing all the time, with new functionality coming, and old ways occasionally going, we have to keep checking — and learning — as we go. I hope you, dear readers, will benefit from this hands-on approach to a tricky and occasionally vexing OS. Cheers!
Author: Ed Tittel
Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.