I have two laptops on the same domain. One has been running Windows 11 Pro for a while and even with a recent update to 24H2, has no problems connecting to remote RDP hosts or to my local NAS via SMB. The other laptop I just upgraded from Windows 10 22H2 to Windows 11 24H2 and lost the ability to connect via RDP or SMB.
The messages were always about failed NTLM connections.
Update See the August 21 update below for a simple solution.
Hours of analysis with three AIs (ChatGPT, Gemini, and Perplexity) had me checking all kinds of NTLM settings, SMB settings, cipher suites, etc. As far as I could see, all settings matched between the two laptops. One AI led towards the conclusion re. RDP that the TCP connection was failing before the authentication step, but I didn’t get far enough to confirm or fix that.
Then Perplexity cited this obscure thread about how re-installing the Windows Server Essentials connector solved the problem:
Well yes, the failing laptop probably had the Essentials 2016 connector installed. I uninstalled it when I decommissioned the 2016 Essentials server. I tried re-installing it, but the installation won’t finish if there is no 2016 Essentials server on the network.
The thread referenced the 2012 R2 Essentials connector, specifically WSEClient-x64.msi, available here:
I installed that on my “bad” Windows 11 24H2 laptop. The installation finished without any prompts for server name etc. After a reboot, both RDP and SMB started working again. Amazing.
Essentials Errors
It’s interesting that, without any configuration, the Windows Essentials services are automatically set to Disabled:
Not so with the tasks. I started getting .NET crashes at every reboot on C:\Program Files\Windows Server\Bin\ClientOperator.exe. The stack trace mentioned FileBackup, which of course is not configured. Perplexity led me to the correct path for Essentials tasks:
Task Scheduler Library > Microsoft > Windows > Windows Server Essentials
The specific culprit is the File history Settings Synchronization task, but I’m disabling all of these:
Reference
These event logs, under Applications and Services Logs, are relevant for troubleshooting RDP connections:
Client side
- Microsoft-Windows-TerminalServices-RDPClient/Operational
- TerminalServices-ClientActiveXCore/Operational
Host (Target) side
- Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
And these more specific tips from Perplexity:
-
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
-
Look for errors around the time of your failed connection attempt. Event IDs like 143, 142, or 226 are relevant (especially related to connections, disconnects, and handshake failures).
-
-
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
-
Successful logins will yield events like ID 24 (disconnect), 25 (reconnect succeeded), and failures may appear as missed session starts.
-
-
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
-
Event ID 261 (“Listener RDP-Tcp received a connection”) appears even for failed handshakes—the server acknowledges an attempt, even if handshake fails.
-
Update August 21, 2025
By comparing registry values with and without the Essentials connector, I believe I’ve nailed down the cause of this issue.
TL;DR Export your current HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry as a backup. Try adding the key and values from #1 below. Reboot and see if you can connect.
1. If a Windows 11 24H2 machine never had the Essentials connector installed, it has this key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"Auth132"="IISSUBA"
"NtlmMinClientSec"=dword:20000000
"NtlmMinServerSec"=dword:20000000
RDP and SMB work correctly.
2. If a machine previously had the Essentials connector installed but it has been removed, this key is missing:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
RDP and SMB fail to connect.
3. If you re-install the 2012 R2 Essentials connector on the machine from #2, it adds this key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
"BackConnectionHostNames"=hex(7):31,00,32,00,37,00,2e,00,30,00,2e,00,30,00,2e,\
00,31,00,00,00,00,00
Note that this value of BackConnectionHostNames is a string representing the loopback address, 127.0..0.1.
RDP and SMB work correctly.
According to Perplexity, the MSV1_1 key “controls settings for the MSV1_0 authentication package, which implements NTLM (NT LAN Manager) authentication in Windows.” if this key is missing entirely (#2), NTLM now defaults to “deny.” If the key is present, even with a “benign” value like BackConnectionHostNames (#3), NTLM can work. I’ve found that using the value from a standard install (#1) also restores RDP and SMB functionality.
Orca
As further confirmation, I opened WSEClient-x64.msi in Orca, a developer tool for analyzing and changing installer files. Here you can see the place where the installer adds the BackConnectionHostNames registry value:
It’s a powerful reminder that legacy components can still hold sway in unexpected ways. This will definitely be saved in my troubleshooting toolkit!
[Advertising URL removed.]