Category Archives: Remote Desktop (RDP)

RDP Absence P16 Fixed

It’s been weird. I had trouble accessing my Lenovo ThinkPad P16 Mobile Workstation for an attorney call last Friday. I couldn’t see it while it was hooked up on Ethernet but it worked OK in Wi-Fi. Today, i finally figure out why that was happening and RDP absence P16 fixed as a result. Deets follow…

How to Get RDP Absence P16 Fixed…

The ever typical error message that shows up when RDP can’t find a PC by desigation (computer name in this case) appears in the lead-in graphic above. Because I already fixed my P16 problem, I used “P15” as the machine name. Since there ain’t no such beast on my LAN, of course it provokes the old familiar “can’t find the computer…” error message shown. But that’s what I was seeing for the P16.

Took me a while to figure out why. If you follow this blog you know I had a Panasonic Toughbook FZ-55 on loan here for some time (unboxing post). While it was hooked up to the LAN it used the Ethernet port my P16 normally uses. On the P16 I switched to Wi-Fi.

That was the problem: with a new NIC for Wi-Fi the P16 also got a new set of IPv4 and v6 addresses. When I hooked back into Ethernet, RDP knew nothing about this. So when I accessed the P16 by name it went looking for it on its Wi-Fi associated IP address. No go!

Fixing the Mix-up

Removing info from RDP requires deleting associated keys in the Registry. I had to visit the key named

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default

to reset the RDP roster. With the old (and incorrect) entry removed I had to go through initial RDP connection set-up again for the P16. But that was easy (provide a password for the Windows login I use) and done. Now things are working again on the Ethernet connection. Only problem is, I’ll have to remember to do this again if I switch back to Wi-Fi (or just use the IPv4 address, which is how I got back in and ultimately how I figured things out).

And isn’t that just the way things go in Windows-World sometimes. If it ain’t one thing, it’s another!


Hello Default Blocks Enhanced Mode Login

Here’s an interesting Catch-22 — for me, anyway. If you want to move data into or out of a VM easily, you must run that VM in an”Enhanced session.” OTOH, if you run a VM in that mode, you can’t login. First, you must tweak a setting with the Enhanced session turned off for the moment. Why? Because a Hello default blocks enhanced mode login unless it’s turned off. Let me explain…

Unless Turned Off Hello Default Blocks Enhanced Mode Login

If you look at the lead-in graphic, you’re also looking in on a VM window via an RDP session. You can see the pull down menu from the control bar shows its “Enhanced session” setting is enabled (blue checkmark against light blue background).

Unfortunately, because of Windows OS defaults upon installation, a VM will also have the Settings → Accounts → Sign-in options set with “Require Windows Hello sign-in for Microsoft accounts” turned on. Alas, that means the Enhanced session VM window will come up, but it won’t respond to the mouse or keyboard to show a login prompt with its PIN or password text entry box. You can’t login under these circumstances until you uncheck the “Enhanced session” item, log in to the VM, then visit Settings and turn off the afore-mentioned Hello sign-in requirement. Once that is done, you can turn the Enhanced session back on, and it will work just fine to let you login. Go Figure!

See the Setting Info…

Here’s a screencap of the “Require Windows Hello…” stuff from Windows 10. The one in Windows 11 is virtually the same.

If you are like me, you use both RDP and VMs together regularly. That means this little maneuver is a useful and necessary part of post-install set-up/clean-up.


Remote Access Window Clips Seconds Display

It’s a “one step forward, one step back” situation. The latest Windows 11 Insider release to the Beta Channel brings optional seconds back to the Taskbar clock. But using a remote access windows clips seconds display, as shown in the lead-in graphic. I’ve posted a report about this to the  feedback hub. Amusingly, it’s attracted an MS response from 3 months ago that says (in condensed form) “We fixed this in the Dev channel 3 months ago.” Uhhh … not really … I see it right there so it isn’t fixed.

Note: I included a snip of the Winver output from the Beta Channel Build 22624.1470 above the Taskbar clock to document its release of origin. You can see about half of the time read-out from that clock at the lower right (enough to tell that it says 11:51:45 AM, in fact).

Reporting Remote Access Window Clips Seconds Display

Here’s what I wrote to the Feedback Hub:

Text from my Feedback Hub report Friday 3/24

One more thing: when you make this change in Build 22624.1470, it doesn’t affect taskbar display until after a reboot. And indeed, upon rebooting the clock initially showed up initially sans seconds display. They showed up later on, as the PC went through its desktop initialization process after I’d logged in. That was kind of interesting, too…

What To Do About “the Clip?”

There’s not much one can do about this issue because Windows 11 still lacks icon size controls for the taskbar. From what I hear these controls are planned for inclusion in some upcoming Windows 11 release. If MS doesn’t get around to fixing this admittedly minor if not miniscule issue, access to icon sizing will probably take care of things at some later date.

I’ll also note that this issue does not occur when I log directly into that test machine (a Lenovo ThinkPad X380 Yoga [8th-gen Intel CPU, Intel graphics, 16 GB RAM]). So it really is an issue with the way the Remote Desktop  Connection application handles taskbar display at the moment. Just for grins, I also tried a connection through the Remote Desktop UWP app. For the record, it clips that window’s clock display, too. Thus, it looks like a taskbar height issue FWIW.



Remote Wi-Fi Driver Update Magic

I remember the networking wars of the late 1980s. That was when Token Ring, ARCnet, LocalTalk and other physical media vied with Ethernet for market- and mindshare. Indeed, I’ve worked with versions of Ethernet all the way back to 10Base2 and 10Base5. Thus, I successfully upgraded the Wi-Fi drivers on my 2018 vintage Lenovo ThinkPad X1 Extreme (running Windows 11) with bemusement and appreciation minutes ago. Based on how earlier Windows versions worked, there was surely some remote Wi-Fi driver update magic involved.

The lead-in graphic is the Intel installer pane that announces a successful Wi-Fi driver install. What’s interesting about this? It’s inside a Wi-Fi based RDP session. I’m working on my production PC via Remote Desktop Connection to the X1 Extreme. It restored itself automatically once the driver install finished. It came back up, even though the connection dropped as that update occurred. No working driver means no Wi-Fi during the switchover from old to new.

What Makes Remote Wi-Fi Driver Update Magic Happen?

Good question! RDP apparently recognizes enough about the dropped session to bring it back to life. And FWIW, that occurs during the first “retry” — by default, RDP attempts resuscitation up to 5 times — without undue muss or fuss.

What makes this noteworthy? I can remember that even Windows 7 could not restore RDP sessions dropped during driver updates. Windows 8 (and 8.1) were hit or miss. It’s only since Windows 10 came along in 2015 (General Availability: 7/29/2015) that this capability has been both mainstream and dependable.

Once upon a time, Wi-Fi driver updates meant the end of open RDP sessions. Recovery was impossible: the only way back in was to fire Remote Desktop Connection up, and start afresh. It’s a small thing, really, but one I’ve learned to appreciate in modern Windows versions.

Thanks IEEE!

Modern Wi-Fi testifies to robust and practiced driver design. Indeed, it keeps working in the face of many predictable difficulties. Replacing drivers is a case in point, but Wi-Fi just keeps on chugging along. And that’s despite various source of interference, occasional hiccups with power, wireless gateways, and more. Having followed the technology as it’s grown and sped up I’m grateful it works well.


Recent 22H2 RDP Mystery Widely Reported

For a while there, I was wondering if I’d done something wrong. I’d just gotten RDP working on my P360 Ultra. But after upgrading to Windows 11 22H2, it stopped working again. Annoyingly, it showed the same symptoms I’d just been able to fix  — connection briefly made, then dropped. But nothing I tried was able to return it to work. In frustration, I switched to TeamViewer free (which worked properly no sooner than installed on client and server PCs). Now, I’m reading my recent 22H2 RDP mystery widely reported in the Windows media. Here’s a taste, from MSPowerUser.

Info on Recent 22H2 RDP Mystery Widely Reported

As I read the symptoms described in reporting on the 22H2 RDP issues, I thought to myself: “This sounds familiar.” And indeed, the error message shown strongly supports one of the possible outcomes to which that language leads:

installing the update caused their Remote Desktop on Windows 11 system to fail to connect (or connect only to disconnect or freeze later).

For the P360, the connection would briefly appear as the RDP title bar at the top of my second monitor. It would, however, stay black. In 10 seconds or so, the error message from the lead-in graphic would pop up. Sigh.

Why Did I Drive Myself Crazy?

The funny thing about this error message — and it’s definitely not funny, ha-ha — is that it’s the same darn one I had just fought through and fixed the week before. In that case, it turned out to be a registry hack that fixed my problem.

I jumped to the erroneous conclusion that my old problem had come back, and spent a good 2-3 hours trying to fix it. I knew it had to be something in the registry, but I couldn’t figure out what. Then, recognizing it was taking too much time to troubleshoot, I simply switched over to TeamViewer.

As it turns out, that was exactly the right strategy. Apparently a LOT of people are having RDP troubles with 22H2. So that workaround comes recommended for others who might find themselves in the same boat. OTOH, the MSPowerUser story suggests another reghack that may see some users clear to restored RDP access. I might have to try it, and see if it works for the P360 Ultra.

And that’s the way things sometimes go, here in WindowsWorld. If and when this gets fixed, I’ll report back. Stay tuned!



Advanced Sharing All Fixes PING

Apocryphally, PING stands for “Packet InterNet Groper” (or perhaps, “Packet Inter-Network Groper”). Actually, I think it comes from submarine-speak. There, a PING denotes the return sound that sonar makes when reflected. I’ve been troubleshooting a persistent RDP issue with the Lenovo P360 Ultra SFF PC. En route, I just fixed an inability to PING that node. Changing Advanced Sharing All fixes PING, as far as I can tell. Deets follow…along with an RDP fix.

Why Say: Advanced Sharing All Fixes PING?

First off, I relaxed all entries under the “All Networks” heading in Advanced sharing settings (Control Panel). Then, PING started working on the P360 Ultra. Easy-peasey, but not terribly safe.

Interestingly, I then went back and changed the settings to their defaults. That’s “the other option” in all thee cases shown. PING kept working, but the sharing was tightened back up.

Comparing P16 and P360 Ultra

What’s even more interesting is that the other “new machine” here does RDP and PING just fine. That’s the latest Lenovo Loaner here at Chez Tittel: the P16 Mobile Workstation. I’ve had no issues with networking and RDP on that other machine. But I was still unable to remote into the P360 Ultra.

I switched to the Remote Desktop app, and got a more informative error code: 0x4. In researching possible fixes, I found a reghack under that heading at TechDirectArchive. Since I’d already tried everything else recommended in that story, I tried that too.

Here’s the Remote Desktop app with the P360 Ultra under its wired IP address: Problem solved!

It had me create a new Regkey named MaxOutstandingConnections in HKLM\CurrentControlSet\Control\Terminal Server. As suggested, I set its value to 0x10000. And guess what? Both the Remote Desktop Connection application (mstsc.exe) and the Remote Desktop app (show above) now work!

Go figure. All I can say is “What a relief!” It’s been driving me bananas…



RDP Mystery Finally Resolved

For years now, I’ve wondered why some of my RDP connections work only some of the time. Now I know why, and it’s provokes a Homer Simpson response “Doh!” Now that I’m done laughing at myself, let me explain how I got that RDP mystery finally resolved.

I was working with my various Thunderbolt docks this weekend, and I noticed that a previously not-working RDP connection started working again. Turns out that of necessity devices with both GbE and Wi-Fi adapters have separate and distinct IP addresses for each such adapter. Therein lies the key to the mystery, as shown in the lead-in graphic.

Explaining How RDP Mystery Finally Resolved Itself

This all started when I had to move my X12Hybrid dock upstairs. When I disconnected from the dock, and its GbE connection, the RDP connection defined for X12Hybrid (also the machine name used in RDP) resumed working. Then it hit me: because the GbE connection uses a different IP address from the Wi-Fi connection, my RDP definition works only when the IP address it knows about matches the address actually in use. Again: “Doh!”

You can see this clearly in the dual windows shown in the lead-in graphic. PowerShell is in top position, and shows that nslookup stores the IP address associated with the Wi-Fi interface ( But when I plug the GbE interface in, it takes a different address instead. That private IP address ends with .39, as shown in the NetBScanner window at bottom of the same graphic.

How to Adapt to Changing Connections

The primary router on my local network is an Arris model: it comes from Spectrum as part of its Internet connection and services. I’ve not figured out how to forcibly reset its address tables for DNS lookups on Windows machine names. Instead, I use NirSoft NetBScanner when an RDP connection fails and enter the correct IP address instead of machine name in its “Computer” data field. This works every time.

By observation, it looks like this data updates every 24 hours or so. If I leave the RDP connection unchanged (no switch from Wi-Fi to GbE, or vice-versa) over that interval, nslookup eventually matches the current address. But at least I now know why this is happening, and why using the IP address for the NIC in use fixes the issue.

That’s the way things go here in Windows World, where I still manage to surprise myself by  relearning the obvious. Sigh.


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 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…


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.


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?