Category Archives: Remote Desktop (RDP)

MSA RDP Login Issue Resolved

Today could be a red-letter day for me. I’ve finally figured out how to use an MSA (Microsoft Account) to login to RDP on certain “problem” PCs. I even now understand what made them problematic, and how to fix things. And in the process, my odd MSA RDP login issue resolved itself. Hooray!

Let me explain an odd combination of circumstances that caused this situation to show up on certain laptops. Buckle up: it’s a bit convoluted.

How the MSA RSP Login Issue Resolved Itself

One of the more outstanding online sources of esoteric admin wisdom is a website named SuperUser.com. I found a reference to an item therein entitled Windows 10 Remote Desktop Credentials at another of my favorite haunts, ElevenForum. That item Unable to Access w/Remote Desktop until a Local Logon w/Password is Performed pretty much summed up what I was struggling to resolve.

Here’s the deal: for RDP to be able to use an account/password combination for remote access, that hashed data must be in the target PC’s password cache. If one only logs into that PC directly using a PIN, Windows Hello (or other biometrics), or a security token, that data never hits the cache. If that data isn’t cached, the remote login can’t authenticate and you can’t get into the PC that way. The local account technique works because it does have that data available, and thus it can serve to let the remote user in.

Where Things Get Interesting…

There’s a high-security Account setting in Windows 10 and 11 that falls under Settings → Accounts → Sign-in options that reads “For improved security, only allow Windows Hello sign-in for Microsoft accounts on this device (Recommended).” If you elect this option, you cannot login to that PC using a password. If you can’t login to the PC using a password, that info can’t make it into the cache. And then, as a side-effect, you can’t use that account to login to RDP.

So I had to disable the option,  and use the password to login locally for my chosen MSA. After a restart, I was indeed able to use that same MSA and its associated password to login to a remote session using RDP. Then I re-enabled the option and proceeded on my merry way. Problem FINALLY solved!

Just goes to show: if it ain’t one thing in Windows, it’s almost always something else. And this was “something else” indeed. Glad to have it fixed, and somewhat better understood…

Facebooklinkedin
Facebooklinkedin

Weird Full-Screen RDP Effect

I still use Windows 10 on my production desktop, but I run half-a-dozen instances of Windows 11 right now. Lately, I’ve noticed that with screen size expanded to fit the left-hand monitor — but not maximized — I get a weird full-screen RDP effect. I lose the start menu at the bottom of the screen. As I said: weird!

What Is the Weird Full-Screen RDP Effect?

The lead-in graphic for this story shows what I’m talking about from the Start Menu perspective. Up top, we see a Windows 10 Start Menu that surprisingly shows up at the bottom of a “full-screen” Windows 11 RDP window. When I hit the maximize  button at upper right, the lower (and normal) Windows 11 start menu appears. (Note: I selected “left” alignment in the Task Manager options to make it show up there for purposes of comparison and contrast).

Needless to say, when I don’t notice this and click on the full-screen Windows 10 menu, it doesn’t do anything to the Windows 11 RDP window above. This is disconcerting, to say the least. At worst, I start thinking I’ve got problems and start unnecessary troubleshooting actions. Sigh.

Why/How Did This Weirdness Present?

For some reason, this happened to me the last time I updated the Nvidia driver on my production PC. It’s now running version 516.93, installed last week. After the install completed, all the open windows moved to the right-hand (primary) monitor. That’s normal. But what’s different is that maximized RDP windows changed “auto-magically” to full-screen (but not maximized) layouts. That led me to the source of confusion when I dragged those full-screen windows to the secondary (left-hand) monitor.

Again: Weird! But by looking very closely at what I was seeing, I eventually figured out what was going on. Now I make sure to click the maximize button when using RDP. That way, I see the maximized RDP session controls at the top of the screen (see below) and know that the start menu at bottom is the start menu I want to work within that window.

Weird Full-Screen RDP Effect.controls

And that, dear readers, is how things sometimes go in Windows-world. As JRRT put it “All that glitters is not gold; not all those who wander are lost.” I wandered a bit, but ultimately figured out what was weird and why.

Facebooklinkedin
Facebooklinkedin

Use NSlookup for Machine Name Checks

Certain recent Dev Channel builds have played intermittent hob with RDP. Thus, for example, I had to switch from using the machine name to its IP address to RDP into one particular PC. In troubleshooting that issue, I quickly realize it makes sense to use NSlookup for machine name checks. Indeed as you can see in the lead-in graphic, when NSlookup resolves that name correctly, RDP will also accept that name to establish a connection.

Why Use NSlookup for Machine Name Checks?

Because it will tell you if RDP can recognize the machine name. Under the hood, both RDP and NSlookup rely on access to local DNS records to resolve the name into an IP address (see lead-in graphic). When the command line works, RDP should also be able to rely on the same underlying service — namely, DNS — to do its thing as well.

Of course, this raises the question as to why my local DNS server — which runs on the boundary device from Spectrum that sits between my LAN and the cable Internet connection — sometimes fails to resolve valid machine names. Feature upgrades can cancel existing IP address leases, and require the DNS cache to be rebuilt. And apparently, recent lightning storms can also mess with that device’s DNS cache when the power fails. So, I’m learning to flush and rebuild that cache as part of local device hygiene.

At least I now know what’s going on and why I must sometimes switch from machine names to IP addresses to access certain devices. Good thing it’s easy to log into and handle the reset over the LAN. It’s always something, right?

Facebooklinkedin
Facebooklinkedin

Overcoming RDP Access Hurdles

Here at Chez Tittel, I’ve got 9 PCs in my office. 2 Desktops and 7 laptops, to be more specific. I like to access most of them from my primary desktop. That’s because it sports a couple of aging but still decent Dell 2717 Ultrasharp monitors. Over the years, I’ve encountered interesting issues in making RDP (remote desktop protocol) connections to my “Other PCs.” For me, overcoming RDP access hurdles usually involves one or more of three workarounds.

Three Workarounds to Overcome RDP Access Hurdles

These workarounds help to address a list of problems that include:

  • Can’t find remote PC
  • Can’t authenticate login credentials
  • Password error despite known, good working account/pwd pair

Workaround #1: Try the device IPv4 address

When the Remote Desktop Connection (or Remote Desktop app) simply can’t find a machine name, it’s always a good idea to try the target PC’s IPv4 address instead. As shown in the lead-in graphic for this story, it worked to get me into a Lenovo X380 Yoga I just put through a bunch of Windows 11 upgrades.

Workaround #2: Try a Different MSA

On occasion, when I try to login to a remote PC using my current Microsoft Account (MSA) it just won’t get past authentication. This is often a symptom of difficulty in getting MS authentication to work properly. When that happens, I will try another one of my known, good working MSAs (I have three, as I write this story). That does occasionally work, especially if I’ve already used that MSA on the target machine already. Go figure!

Workaround #3: Try a Local Account Instead of MSA

Sometimes, RDP will strenuously resist allowing you to establish an RDP connection over the LAN using a Microsoft Account (via its associated email address). In fact, it generates an account name/password error, even though I’m using a known, good working MSA account name and its associated password to try to login.

When that happens I’ve found that setting up a local admin account — one named, LocalU, for example — will get me right into the target PC. That’s also on display in the lead-in graphic where I had to use both workarounds at once to get into that PC. Sigh.

Remember: Where There’s a Will, There’s a Way

If you need to establish an RDP session on a remote PC, you can usually figure out a way to make such a connection work. If the preceding workarounds don’t do the trick, try the other tips in this 2021 WindowsReport story: it offers pretty good tips, tricks and advice.

 

Facebooklinkedin
Facebooklinkedin

School PC Catch-up & Cleanup

Earlier this week, the school year ended. Thus, I regained access to my Lenovo X390 Yoga laptop, which my son used as his in-school PC. As such things go, it wasn’t in terrible shape. But it had missed out on plenty of updates, including the upgrade to Windows 11. With all that effort behind me now — and a couple of interesting war stories to share — here’s the tale of a school PC catch-up & cleanup.

Tales of  a School PC Catch-up & Cleanup

I was pleasantly surprised with the machine’s state upon its return. It wasn’t even that dirty. A quick wipedown with a wet-wipe sufficed to get the fingerprints and etcetera gone. A microfiber cloth did likewise for the screen and keyboard deck.

But boy, did it need a LOT of updates. And then there was the Windows 11 upgrade, which brought me face-to-face with at least one recurrent RDP gotcha, amidst some other interesting stuff.

What Didn’t Need an Update?

I ended up using three tools to cover most of the application updates. Of course,  a visit to the Microsoft Store did likewise for the apps on this PC. Those three tools were KC Softwares Software Update Monitor (SUMo), PatchMyPC, and the built-in PowerShell winget utility. In the end, all 16 applications installed on the PC were updated, along with 54 (!) apps via the MS Store. Wow!

It was on the OS side of things where life got more interesting. After I caught up on the Windows 10 installation on the X390, I noticed that numerous prior upgrade attempts to Windows 11 had failed. Upon essaying same, I quickly realized why: Start10 was installed on that machine.

The MS installer apparently now requires that Start10 be uninstalled before the upgrade can proceed. Interestingly, earlier versions would let it through. (I had a couple of machines where Start10 would happily run on Windows 11, in fact). Uninstalling the application required some Task Manager shenanigans. I had to kill its parent process. That’s because uninstall otherwise requires a reboot and the upgrade install process was ready to fire off if the hurdle could be cleared.

A Few Bumps on the Upgrade Road

Then came the Windows 11 upgrade, which proceeded without issues this time. However, once again I could not use an MSA (Microsoft Account) to RDP into the upgraded PC. I had to set up a local account (with admin privileges). I also had to use the PC’s IP address as the target, because the machine name wouldn’t resolve. That’s interesting, because the names DO resolve in Nirsoft’s NetBScanner, as shown here:

School PC Catch-up & Cleanup.post-11

As you can see both RyzenOfc and DinaX390 resolve inside NetBScanner, but neither name resolves inside RDP. Weird!

I’ll be filing feedback hub reports on those glitches later today. That’s it for now on “The Return of the School PC.” More will follow as I observe and learn more along the way…

Note Added 1 Day Later

I have gotten machine names to resolve on both problem PCs now. The Ryzen PC was affected by the recent lightning strike, and lost its network sharing settings and name resolution upon the next reboot. After running DISM /restorehealth and turning RDP off, then back on, it started working again.

On the X390, after I used RAPR to forcibly delete obsolete and duplicate drivers, then rebooted, the name resolution starting working there again, too. They now show up in positions 2 and 4 in the following set of File Explorer network PC icons:

I still can’t log into either machine using RDP with an MSA (Microsoft Account). Thank goodness the local account workaround (admin level accounts only, please) still does that trick! I’m guessing this is a separate issue and will report it to Feedback Hub accordingly.

 

Facebooklinkedin
Facebooklinkedin

RDP Goes MIA Following KB4014650 Update

Yesterday (May 10) was Patch Tuesday. A plethora of updates hit for Windows 10 and 11 across most versions. Right now, various Windows news outlets are reporting issues with some of the updates just released. Naturally, I wanted to check to see if any of my PCs were affected, In reaching out to my various systems, I noticed RDP goes MIA following KB4014650 update to at least one of my Windows 11 Dev Channel PCs.

FWIW, that’s different from issues reported elsewhere (see this WindowsLatest story for an example). Most revolve around issues related to .NET Framework 3.5 problems.

Fixing RDP Goes MIA Following KB4014650 Update

On my Lenovo X12 Hybrid, the symptoms of trouble were easy to spot. Even though the Belkin Thunderbolt 3 dock remained plugged in, the system saw neither its GbE connection, nor the nominal 5TB HDD plugged into one of its USB-C ports. Thus I knew something was up with peripheral connections. Fortunately, an unplug/re-plug operation brought both the dock and the drive back into service.

One of my X380 Yogas was unaffected by the update, and RDP kept working as always. Amusingly, the second instance (both machines are identical except that one has a Toshiba/Kioxa SSD, while the other has a Samsung, of which both are OEM varieties) did not come up right away. A visit to Settings → System → Remote Desktop to turn Remote Desktop off, then turn it back on, did the trick for this machine.

Neither fix was a big deal: each was obvious and thus easily identified, and likewise easy to fix. I can only wish all my Windows problems were this lacking in subtlety and amenable to repair. Long experience teaches me otherwise.

Shades of Other Days & Other Fixes

I can remember days when Windows 10 updates would routinely mess with my Network and Sharing Center settings. Advanced sharing settings for Private, Guest or Public, and All Network elements would routinely revert to their defaults. So then, I would have to re-set them to the way I wanted them to be. This latest set of issues strikes me as something in that vein. Hopefully, it will be just a one-time blip rather than a new continuing gotcha. Time will tell: I’ll keep watching, and report what I find. Stay tuned!

Facebooklinkedin
Facebooklinkedin

MSA Login Doesn’t Connect Via RDP

Here’s an interesting problem that I apparently share with lots of people. Try searching on “can’t login to RDP” or “MSA login to RDP doesn’t work.” You’ll see what I mean. For me, MSA login doesn’t connect via RDP from my trusty Win10 production desktop to my new Ryzen 5800X build. Sigh.

So, of course I went through all kinds of contortions and research to try to get it working. I tried a variety of GPO settings, registry hacks and more, all without getting any love.  I spent 45 minutes trying to make this work to no avail. Even though I double-checked my passwords (and in one case, reset it just to make darn sure) I kept getting errors. Either “The password used to connect to the remote PC didn’t work” or “The credentials didn’t work” (RDP app and mstsc.exe, respectively).

MSA Login Doesn't Connect Via RDP.rdp-app-error

Words alone can’t convey the frustration in using a known, good, working password and getting such an error. Ouch!

When MSA Login Doesn’t Connect Via RDP, Use Local Account

Then, in several of the posts I read online, I noticed that similarly afflicted individuals succeeded in opening an RDP session using a local (client) account. So I set up a local account on the client PC using the “Add account” facility in Settings → Accounts → Other Users. Hint: you have to say you don’t know the user’s sign-in info to get to the right screen, where you choose the “Add a user without a Microsoft account” (MSA) to create a local account. Sigh again.

So, I created an account named LocalU, and then promoted it to Administrator status. Then, on my next RDP attempt into that PC the login succeeded using that account name and its associated password.

Even though you can’t always make Windows do exactly what you want, you can often find a way to get what you need through some workaround. This is actually a pretty good example. I can’t say I’m happy about this (and plan to report it to Feedback Hub next). But at least I can RDP into my new desktop. This will be very important when I start migrating files and stuff from the current production desktop to what will be my new production desktop next month.

Stay tuned! I’ll keep you posted as things progress in their usual “two steps forward, one step back” fashion. Should be fun…

Facebooklinkedin
Facebooklinkedin