Category Archives: Remote Desktop (RDP)

Insider stuff, Remote Desktop (RDP), WED Blog, Windows 11

Latest Beta CU Keeps Remote MSA Login Glitch

Leave a comment

OK, then. I just logged into the ThinkPad X380 Yoga, where I run the Windows 11 Beta Channel Insider Previews.  I’ve been forced to remote into that laptop using a local account for months. But just now, I got fooled by a successful MSA login to Office immediately after login on that PC. I thought the MSA issue was fixed, but I thought wrong. The Remote Desktop Connection used my LocalOnly account to set up that remote session, after which the MSA worked fine to login through MS to access Office. Despite my hopes to the contrary, the latest Beta CU keeps remote MSA login glitch. Sigh.

Showing Latest Beta CU Fixes Remote MSA Login Glitch

If you look at the lead-in graphic, you’ll see two important things. One, Office asking me if I want to stay signed in. Two, it’s showing the account that stays that way if I agree (“Yes”) is an MSA. For the record, that is an old, expired MSA whose mail server/domain got turned off in 2024, so I don’t mind sharing it publicly. But as I explained, that’s not the same account that Remote Desktop Connection used to make the RDP connection in the first place. I got fooled!

The interesting thing, of course, is that RDP (via the Remote Desktop Connection, aka mstsc.exe) is still cannot resolve MSA lookups to the MS authentication servers during login. I’m still getting an invalid credentials error. I’ve also seen “unable to contact LSA” (Local Security Authority) errors as well. Sigh again.

Even though I tried an MSA, the error message still shows the local account.

With the update to Build 26120.6780 in the wake of KB5067103, that problem seems to persist. But, I’ve been through this on-again, off-again ability to use MSA logins for RDP for some time now. So I’m wondering: when will MS fix this thing? That’s the way things go with Insider Previews, here in Windows-World. As long as I can work around it, that’s OK!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Remote Desktop (RDP), WED Blog, Windows 11

Remote Desktop Connection LSA Error

2 Comments

Over the past couple of years, I’ve noticed that establishing an RDP session from my primary desktop to other PCs sometimes fails under specific circumstances. I’m researching a story about this for Mayank Pamar at WindowsLatest, so keep an eye out for that opus. It’ll probably hit next week. When I attempt to get into some of my Windows 11 PCs (the only kind of physical PC I have any more), my login will occasionally be refused if I use a Microsoft Account (MSA). Indeed I’ll see a Remote Desktop Connection LSA error that reads “The Local Security Authority cannot be contacted.”

What Causes Remote Desktop Connection LSA Error?

Interestingly, there are a number of possible causes. Some are easy to fix, others fall on third parties. Here’s a partial list:

  • OS can’t validate credentials, particularly MSA logins (the most common and obvious reason, but one users cannot easily fix themselves)
  • Secure channel negotiation (to exchange credentials) fails
  • Time sync or DNS resolution fails
  • Credential policies are somehow misconfigured

Time sync and DNS stuff is probably the most approachable, so they’re worth trying. For the former that means Settings > Time & Language > Date & time > Sync now (under Additional Settings). For the latter, it’s only meaningful if using manual DHCP assignment, in which case Setting > Network & Internet > Ethernet or Wi-Fi > Edit DNS Settings > define preferred and backup DNS server addresses. Most users will get their DNS server assignments via DHCP.

The other items are a bit more convoluted. I’ll get to them in my upcoming story. Here in this brief blog, I’ll “leave them as an exercise for the reader” in the classic ploy used to avoid heavy lifting in so many, many textbooks I’ve read over the years…

A Typical (and Useful) Workaround

If I can’t get into a PC using my MSA, I’ll set up a local account on the affected machine with admin privileges and use that to RDP into the machine instead. This might cause issues on machines where you want or need access to account-speicific files or data (e.g. the associated C:\users\<name> folder hierarchy). But otherwise it works OK. In a small and unscientific survey of my local fleet, I’ve had to do this on just under half the machines (4 out of 9), most of which are running Insider Preview releases (and thus, have their foibles).

Here in Windows-World, if you can’t do things the way you want to, you must sometimes do them some other way. Obtaining RDP access to some of my test and experimental PCs puts me in those shoes from time to time. So it goes!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Remote Desktop (RDP), WED Blog, Windows 11

Copilot Unpicks Local RDP Access

Leave a comment

On my sole remaining 2018 vintage Lenovo ThinkPad X380 Yoga, I’ve been fighting RDP connectivity issues. It’s running Windows 11 24H2 Insider Preview Beta Channel Build 26100.4946. All of a sudden, I couldn’t RDP into the machine at all. MSA-based access is still stuck on a Local Security Authority (LSA) access problem. But just now, Copilot unpicks local RDP access so I can use a local admin account to access it remotely. Phew!

Grinding Through as Copilot Unpicks Local RDP Access

Something was odd about the local account setup that didn’t sit right with RDP. Even though I’d set the account up with a password, that selfsame account did not have the PasswordRequired value field set to “True.” Turns out that RDP requires this setting before it will allow any account to connect.

Copilot cheerfully took me through some PowerShell syntax that didn’t work. Then it had me run the Command Prompt alternative that finally did the trick:

net user Actname YourSecurePassword123! /active:yes
/passwordreq:yes

Obviously, I used the actual account name for the Actname placeholder, and the real password for that string. But indeed it worked. And when I made my next login attempt, I was finally able to get back into that machine.

A Word of Warning

When I asked Copilot why this might have happened it informed me that this build “introduced a wave of under-the-hood changes” into Windows 11. Specifically, in the area of identity handling where “Insider builds often tweak how MSAs and local accounts are handled — especially in relation to login tokens, SID bindings, and credential providers.” That’s confirmation of what I’ve long suspected, because I’ve found myself unable to login to RDP using an MSA numerous times.

But this is the first time I’ve also been blocked for a local account as well. I’m just glad Copilot could steer me in the right direction to get a local connection working again. Even though my test and experiment PCs are mostly in the same office as my production desktop, it’s so much more convenient to access everything from the same keyboard, mouse and display setup. For me, RDP is an essential work tool. Bugs me to no end, when it doesn’t work right, as it does occasionally break down here in Windows-World. Sigh.

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Remote Desktop (RDP), Troubleshooting, WED Blog, Windows 10, Windows 11

Chasing RDP Login Takes Too Long

Leave a comment

OK then, I’ve hit my troubleshooting time-out. Now that I’ve switched over to the Flo6 5800X build for my production desktop, I’m keeping the i7Skylake up and running in parallel. Why? So I can grab or look up things I discover I need on the new build that are only available on the old. So far, that’s included some logins that didn’t make it into the Norton Vault (only stored in Firefox on the old PC, as it turns out), various files and some app configuration data I didn’t know I’d need. Only one small problem: I can’t RDP into the account where all the stuff I need lives. I can RDP into the i7Skylake on a local admin account, but I get an LSA error when I try to log into my primary account. Alas, chasing RDP login takes too long, so I’m using TeamViewer instead. Indeed, it came up on the first try.

Why Chasing RDP Login Takes Too Long

Something has gone weird with NetBIOS and/or Domain Name resolution for RDP into the i7Skylake. That’s why I can get in using a local account, but not the MSA for the primary account. I’ve tried everything Copilot and Google can tell me about fixing that, to no avail, including:

  • Flush DNS name cache
  • Editing hosts file
  • Turning off browse service
  • Trying cmdkey explicit access in Command Prompt

And a whole bunch more. At present, I’ve spent at least 4 hours trying to MAKE it work. But RDP stubbornly refuses to let me use my MSA to log into i7Skylake.

The TeamViewer Alternative: Armadillo Time

TeamViewer doesn’t use RDP for remote access. It’s got its own set of protocols and services to manage LAN and Internet-based connections. It took me all of 15 minutes to get everything downloaded, installed, configured and running. I was able to access i7Skylake using the MSA I wanted on the first try. Go figure!

Sometimes, the best thing about beating your head against the way is how good it feels when you stop. Here in Windows-World this is not an unfamiliar sensation. If anybody knows how I can fix my RDP issue, I’d love some added insight and info. But for now, I have lots of other things to do — including a big deadline tomorrow on a writing project — so I’m taking the alternate route. If you’re not familiar with Jim Franklin’s wonderful armadillo image of that same name, check it out courtesy of Coast Monthly (it serves as the lead-in image for a terrific story).

Facebooklinkedin
Facebooklinkedin
Copilot+ PCs, Insider stuff, Recent Activity, Remote Desktop (RDP), WED Blog

Snapdragon X Wakes Into RDP Session

Leave a comment

Here’s an interesting tidbit to consider. Lenovo having sent me a splendid Yoga AIO 32Ill10 last month, with its brilliant 31.5″ display, I’ve been using it a lot. Last night, I put it to sleep when I went to bed using its lock screen power controls. That’s something like what you see in the lead-in graphic, where I chose the middle option labeled “Sleep.” This morning, I observed that the Snapdragon X wakes into RDP session, as I poked the Window Terminal session I had running remotely on my desktop. No hesitation, no delay, just an instant response to my command input. Nifty!

What Snapdragon X Wakes Into RDP Session Means

Snapdragon X includes an Instant Wake feature, which describes its ability to resume activity from sleep in a second or two (no noticeable delay). I didn’t realize that the Modern Standby and Always Connected capabilities that support this feature would also maintain an RDP session until I started typing into the Windows Terminal pane I had open on that remote desktop this morning.

This is great for a variety of reasons, including:

  • Cutting down on light output in my office when the whole house is sleeping.
  • Saving energy not used to keep the lock screen showing even when away from the unit itself (or the desktop holding its RDP session)
  • Letting me get right back to work doing remote stuff without having to log back into RDP first. Older Windows PCs lose their network connections when put to sleep, in my experience.

Another Copilot+ PC Advantage?

AMD and Intel alternatives to Snapdragon CPUs are getting the very features that make Snapdragon X do its thing so well (e.g. Modern Standby and Always Connected). But Copilot says that these systems won’t get them across the board until 25H2 updates go into general release. I’m guessing this means they’ll work on some of the Insider Previews already, but that one can’t count on general availability until after 25H2 hits a target PC.

Indeed Copilot alluded to those famous words of frustration in this context — namely “gradual rollout.” Here’s the quote from whence this observation springs: “Feature rollout is staggered: Snapdragon systems got first dibs; AMD and Intel systems are receiving Copilot+ features gradually through updates.”

As is often the case in Windows-World, YMMV applies to Copilot+ PCs that don’t include Snapdragon CPUs. That, in a nutshell, explains why I begged and pleaded with Lenovo to send me some review units with Snapdragon X circuitry. Thanks, people — I’m grateful to have access to this stuff!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Remote Desktop (RDP), WED Blog, Windows 10, Windows 11

MS Support Eases Office 2024 Transfer

Leave a comment

I guess it was inevitable. As part of my Microsoft MVP award benefits I get a license for Office 2024 for Home and Business. Turns out it’s a single-use (single device) license. I had installed it on a test machine last year, and returned same without uninstalling that software. When I tried to install it again on my nearly-complete replacement desktop, I couldn’t activate my valid license because it was already in use. I knew what I had to do — put a call into Microsoft. But to my great surprise and delight, MS Support eases Office 2024 transfer. I did it all via online chat, too.

How MS Support Eases Office 2024 Transfer

Here’s how the process went. I followed a license transfer link on the MS Support pages (depicted as the lead-in graphic). Then, I logged into that page using the same MSA tied to that license. Next. I entered “transfer license” into the Need more help? field, and selected the resulting “Transfer your Office license…” at the top of the options list. Then I clicked “Contact Us,” and started an online chat with MS support rep Kath (screen name “Kathleen”).

I’ve been on the phone with MS Support dozens of times in my 3-plus decades of working with Windows and Office. This call went as smooth as glass. Interestingly, Kath sent me an image (.img) file to use as my Office installer (that’s a first for me). But I knew enough to mount that file as I would an ISO and run the installer from there. The install went through without a hitch, and when I fired Word off for a first run, it prompted me for the license key. And this time, because Kath had unbound the license from its previous device, the key was authenticated and activated. I’m in business!

The Vexing Climb to Working Outlook

I futzed around with the Outlook app for a while, but wasn’t able to get it to work. That’s because my email provider uses a non-standard domain name for its outgoing SMTP mail server, not the standard default (smtp.mailchannels.net). The Outlook (classic) client provides the facility to override that default, but I couldn’t figure out how to make that happen in the app.

Long story short: I’ve got nearly everything I need to transition from the old i7Skylake desktop (working on it right now) to the new Flo6 desktop (running an RDP session into it right now). I’ll run both systems in parallel for a while, but switch Flo6 into service on my actual desk Monday, and move i7Skylake to a monitor on the next desk over in my office. That way, as I transition from the old machine to the new, I’ll retain easy access to the old to grab anything I realize I’m missing on the new machine from its predecessor.

This turned out to be a great way to get over the Outlook hump yesteday, in fact. When I couldn’t get the Outlook auto-configure to work, I was able to open the old client, examine its configuration in detail, and see the default-vs-actual domain name issue for outgoing mail. Very handy! I’m sure I’ll be doing that again in the next week, probably  several times.

What’s Left, Transition-Wise?

I’ve still got to set up and customize PowerShell (install OhMyPosh, switch to a compatible font, add bunches of tools and utilities, etc.). I will also check over what’s running on i7Skylake and decide what I want to move from old to new PC. At a minimum that will include MS Solitaire, some kind of PDF client, Amazon Kindle, Audacity, possibly a new Corel PaintShop version, Jabra Direct (for my awesome headset), Powerchute Serial Shutdown, UniGetUI, VS Enterprise, and Zoom workplace.

That should — and probaby will — take a while. I’ve been using my current desktop since 2016 more or less daily, so it’s still going to be something of a shock to switch. Stay tuned. I’ll keep writing about this, as it remains a major preoccupation for me coming up.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Recent Activity, Remote Desktop (RDP), Troubleshooting, WED Blog

Thunderbolt Share Gets Interesting

4 Comments

OK, then. I asked Lenovo to send me another Thunderbolt 4 capable laptop so I could try out the new Intel Thunderbolt Share app. Looks like I’m at least temporarily stymied, and have learned some things I don’t especially like, either. Indeed, Thunderbolt Share gets interesting from the get-go possibly because of licensing issues. Right now, I’m stymied because when I run a TB4 cable between my 2 TB-equipped laptops right now, I can never get past the “Waiting for connection” screen shown above. Sigh.

Thunderbolt Share Gets Interesting Because…?

Notice the disclaimers beneath “Connect both Computers” in the foregoing screencap. I may be stuck on the clause that reads:

At least one PC or Thunderbolt accessory must be Thunderbolt Share licensed by the manufacturer

From what I can tell, the newest of my pair of PCs — the only one that could possibly qualify here — had its Windows image burned on November 20, 2024. Given that Thunderbolt Share made its debut in May of the same year, it’s entirely possible that Lenovo didn’t license this program for the ThinkPad T14s Gen5. At any rate it’s not working between my only TB4-capable laptops right now. I’ve asked Lenovo for help, and we’ll see what happens. But there’s more…

Thunderbolt Share Won’t Open in RDP Session

My usual way of working on test and eval PCs is to RDP using  Remote Desktop Connection (mstsc.exe) on my primary desktop. That’s what I tried first to get into Thunderbolt Share on the two target machines. Guess what? Thunderbolt Share won’t launch from inside an RDP session. I have to physically use the target PCs to get the app to run. I have to laugh…

Once launched,  it keeps running if I then remote into either the P16 or the T14s. But of course, it’s stuck at “Waiting for connection” right now. So I’m getting nowhere, fast. That means my plans to compare TB4 cable transfer speeds against GbE and Wi-Fi transfers are on hold for now. Stay tuned. I hope to get this straightened out soon.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Microsoft 365, Remote Desktop (RDP), WED Blog

Windows App Replaces Remote Desktop May 2025

Leave a comment

Based on other recent MS announcements, looks like May is “retirement month” for multiple apps and applications. The latest item scheduled for a retirement party (but no gold watch) is Remote Desktop. Yesterday, the Windows IT blog featured an item entitled “Windows App to replace Remote Desktop…” to announce the changeover. Interestingly, the same blog post also advises continued use of Remote Desktop Connection (RDC) for plain vanilla remote access. When the Windows App replaces Remote Desktop (May 2025), RDC remains a primary remote access tool.

Once Windows App Replaces Remote Desktop, Then What?

The kicker for some users — including your humble author — lurks in the tag line on the Windows App page in the MS Store. It reads “Requires work or school account,” which means not just a Microsoft Account (MSA) per se, but one with Entra ID capabilities and attributes. Indeed, most people get those through work or school (hence, the tagline) because it costs upwards of US$20 monthly for a properly-qualified Microsoft 365 subscription.

Those who want to use the Windows App must provide an appropriate and qualified MSA to use it. I’m still pondering whether I want to shoulder those costs. But when May comes and goes, none of us, across all MSAs, will have Remote Desktop to kick around any more.

Here in Windows-World, “plus ça change” (in English: “the more things change, the more they stay the same”) is not just a catch-phrase, it’s a way of life. That said, it looks like May 2025 will be a little more change-forward than other months this year. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Remote Desktop (RDP), WED Blog

Recent RDP Hiccups Confirmed

Leave a comment

I’ll be darned. It isn’t often that my local minor Windows gotchas make the news. But there they were this morning on Windows Latest: Windows 11 24H2 RDP hangs on login, RDP session connecting issues reported. For at least the last month or so, I’ve had RDP sessions hang on the login screen, and stay stuck there. Now that I think upon it, the client on the “other side” must’ve been some version of 24H2 (Canary, Beta, Release Preview or Production). That’s why I say: recent RDP hiccups confirmed.

What to Do When Recent RDP Hiccups Confirmed

In my case, this turns out to be a minor enough gotcha that I’ll keep doing what I’ve already been doing. Of course, now I can start waiting — and looking — for some relief from MS. Turns out that if you close the hung RDP session and reconnect to that client, the connection works 90+% of the time. That’s good enough for Windows work here at Chez Tittel.

I have, however, noticed that the Remote Desktop app is less subect to the hiccup (though still not completely immune). I can’t function with remote access of some kind. That’s because I’ve got 6 Windows 11 PCs in my office, and 3 more upstairs. And you guessed it: all are running Windows 24H2 of some kind by now.

A Group Policy Fix May Do the Trick

WindowsLatest also reports that changing the value for a particular node in the Windows Group Policy tree can fix this issue. That node is:

Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections

Open Select network detection on the server. Next, make sure that value is set to Enabled, then give it a value of  Turn off Connect Time Detect and Continuous Network Detect.

According to the story, that should fix things, with no reboot required. Let’s see … goes off to check … seems to work as described. At least, the half-dozen connections I just tried all came up, sans hiccups. I’ll see how things go longer term and report back here if anything fails in the interim.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Remote Desktop (RDP), WED Blog, Windows 10, Windows 11

RDC vs. Remote Desktop

Leave a comment

I make remote connections to Windows PCs all the time, every day. I often switch between the Remote Desktop  Connection (RDC, aka mstsc.exe) and the Remote Desktop app (9WZDNCRFJ3PS in the MS Store). Lately, I’ve noticed that the .exe is prey to a hiccup to which the app is not — namely, RDC will often hang at the lock screen with spinning balls frozen when I start a remote session. Remote Desktop never does this. Because I know RDC better than Remote Desktop I used to prefer it. Because I favor speedy in-and-out over redoing my link I’m now leaning toward the latter. Thus, in my recent estimation of RDC vs. Remote Desktop, the app is gaining favor.

More Differences in RDC vs. Remote Desktop

This got me to wondering about other differences between the older exe and the newer UWP app. Looks like Remote Desktop can do other stuff that RDC cannot, too, including:

  • Auto updates through the MS Store (Winget handles mstsc.exe)
  • Modern UWP app interface with thumbnails and minimal controls (Full-Screen and Disconnect only)
  • Access a complete remote desktop or access one remote app without running a complete remote desktop
  • Works across MacOS, iOS/iPadOS, Android, Chrome and Web browsers (IDKICDT)
  • Multi-monitor support lets Remote Desktop map multiple monitors from remote client to host desktop
  • Works with Azure Virtual Desktop and Windows 365 Cloud

In some situations, I can see where single-app remoting could be good. I also like support for multiple client OSes and monitors. I wish I had the ability to try out the cloud capabilities, too. Sounds like fun.

Maybe It’s Time to Join the 21st Century?

I’m thinking I should be using Remote Desktop more than RDC. I think I’ll try it for a while and see how it goes. It could be that some of my issues with VMs might also be MIA in the newer app. Let’s find out!

Facebooklinkedin
Facebooklinkedin