RDP is broken and I think it's unrelated to the April 2026 update

Posted by CeC-P@reddit | sysadmin | View on Reddit | 27 comments

Yay, another RDP post. Anyway, one of our clients wants to use RDP for some reason to connect to their desktop from a laptop offsite. We already have Ninja Remote set up but sure, why not.

We've got computer A running 25H2 all latest updates. Same for computer B.
B is a laptop, wants to RDP into 25H2 once it's on the VPN.

We try to RDP into CompA by IP address, no connection, no response. Try hostname, nope.
In the registry, it's indeed still bound to port 3389
We allowed the user by username in RDP config.
RDP connections are turned on.
Terminal service is running
Outgoing RDP connections from computer A work just fine to other computers on their network.
10000 other checks are all as you'd expect.
Firewall rules say allow, etc etc etc.

But when I run netstat -an, there's no entry for port 3389. So nothing is listening on that port. WTF? That rules out external switch VLANs, firewalls, whatever, I guess.

Also, we completely turned off the windows firewall, same result. Zero failed login attempts seen in the Windows Security log on the target computer. It didn't see anything because it wasn't listening.

Now we're not using an RDP file, we just pull up the RDP application in windows and type in the IP address and hit connect. But still, we're not seeing that warning popup from the new update. I put in the reg fix for that anyway, no difference.

I think this is actually unrelated to the Windows update. Except all 10 of our newly imaged computers are refusing RDP connections and it works fine on every other system they own (which may be 24h2). So now they're blaming us. Someone set up the PCs before I worked here so maybe they did sabotage port 3389. I dunno.

I'm at a loss for how to fix or even diagnose this. Ran SFC and DISM and are waiting on an overnight reboot to re-test tomorrow but I guarantee there won't be a listener on 3389 tomorrow because there's no way 10 computers all randomly broke in the same way.

Does this still sound that like April 2026 update or something different and has anyone ran into this? According to my research, listening on 3389 in a fundamental part of the TS system and if it's not there, it's not repairable. So that would suck.

[-]

SupraCollider@reddit

Is this a domain? Are you cloning these images and just renaming them without sysprep? Kerberos and NTLM no longer support duplicate SIDs, it is a security issue finally coming to roost after years of people being way too comfortable cloning systems without sysprepping them first to clear the SID and prepare it for OoBE to generate a new one. There are ways to revert but you will need to inventory and analyze your versions. If this is the case, I suggest you do a workaround but treat it as a technical debt to pay down immediately by fixing your cloning process, reimage the duplicate machines, and adopt the new security controls fully.

[-]

techvet83@reddit

Good point. Microsoft posted this month specifically that duplicate SIDs are not supported anymore (thus walking back Mark Russinovich's famous 2009 post stating that NEWSID.EXE wasn't needed anymore).

[-]

scytob@reddit

I worked for MS when he joined, the number of incorrect things he has said about windows over the years astounds me. He is undoubtedly clever and knows a lot, but has zero self awareness or any understanding there might be something he doesn’t understand or know. For example his blogs on minwin are utterly wrong, same for history of something’s where I was in the room and know the history. He mostly writes cool utils and pontificates.

[-]

blbd@reddit

To be fair I blame Windows more than him. All of the documentation is bad. The code is not open. And when it leaks it's really awful stuff. It's an inscrutable nonsense heap. And the latest version continually malfunctions on its best days.

[-]

scytob@reddit

Err he has access to the code and thousands of people who are his colleagues who make the code.

[-]

SupraCollider@reddit

I’ll never forget the Mark Russinovich post because it always seemed like trouble to me lol. When he said not to use newsid anymore is when I learned how to sysprep, because why would you trust a computer configuration where something explicitly programmed into the architecture is ignored and treated like it doesn’t matter just because nobody was seeing what it does. Meanwhile, encryption in AD domains has been broken for years as a result and AD is like swiss cheese for insider threats if you are still following this and other 2009 era wisdom 😬

[-]

CeC-P@reddit (OP)

I wasn't there when they built them but our standard procedure is to install each one from scratch with real media

[-]

dcrowson@reddit

Duplicate SIDs just yield a password not working issue in this case. You will still get the connection.

[-]

DrNoobSauce@reddit

Correct. I just dealt with this for a client and the connection still prompts for the password, but tell you it's wrong every time (even if correct).

Jimmayx@reddit

I know it’s basic but is the network adapter set to public which blocks all inbound requests?

Considering they turned it on and set it up without us there, probably. I'll check.

JerikkaDawn@reddit

Everyone blaming the SID because they just read about it and ignoring "nothing listening on 3389."

Curious201@reddit

if you only have EDI failures during specific trading windows, i would stop treating it as a generic “RDP is broken” problem and build a timeline first. exact disconnect time, user, source IP, RDP gateway or VPN path, server event logs, app logs, firewall logs, and whether other sessions dropped at the same minute. the WiFi angle may be real for remote users, but it does not explain everything unless the disconnects line up with client-side network changes. i would also check session host resource spikes, idle/session timeout policies, UDP vs TCP behavior for RDP, and whether the EDI app is sensitive to brief network drops that normal users would never notice. if the April update is suspected, compare patched and unpatched hosts or roll one test host back only if you can reproduce the failure. otherwise it becomes another patch-blame rabbit hole.

ender-_@reddit

I've had a problem like this before – RDP was enabled, RDP service was running, but not listening on any port, and nothing I did fixed that. The only thing that worked was upgrading to a newer Windows 10 build.

king-kam-@reddit

Just RDP using Ip address instead of hostname. Its been a longstanding problem that using hostname doesnt always resolve and connect with RDP or C$ with newly joined devices until alot of time on the domain and network and multiple restarts and gpupdates. Its just faster & easier to save your rdp connections with IP instead. You can name the saved rdp connection with whatever name you want but still connect using IP instead of hostname.

Chareon@reddit

Hostname is required for Kerberos. Using IP forces it to fall back to NTLM, which you should have disabled. You do have it disabled right? (I get it, lots of places don't yet. But it's on it's way out anyways, so best get used to it not existing.)

thetokendistributer@reddit

Funny. I had a similar issue today. Normally I just enable it via settings. But this time it didnt just work. So I went through the same steps as you, still not listening on 3389. Restart and good to go.

Insec_Bois@reddit

I second the SIDCHG comment. Check if the SIDs of machine a and machine b match, and if they do, you'll have to run SIDCHG on them (it's honestly a little scary lol)

gonein62seconds@reddit

I had this today on a newly installed win11 25h2.

I disabled rdp first. Then I deleted the remote desktop certificate Enabled rdp Rebooted

I was also able to get it listening on port 3389 by disabling NLA. But I didn't want to leave that off, hence the above steps.

Enough_Pattern8875@reddit

Use IIScrypto to check ciphers.

Disable tls1.3 on the client and host systems and test RDP access again.

smarthomepursuits@reddit

Yeah, ran into this the last few months I'm

SID change is the culprit.

buy a site wide license for this: https://www.stratesave.com/html/sidchg.html

alphaxion@reddit

Can you ping the FQDN of the system they're trying to RDP into from the remote laptop?

If not, what is the reason?

Doesn't resolve? Then you need to find out why DNS isn't resolving. (could be VPN client isn't getting correct config, or DNS traffic isn't allowed)

Does resolve, but times out? Do you allow RDP traffic across the VPN? If you do, is there a local firewall on the RDP system that is denying access to the VPN subnet? Or denying access to RDP entirely?

autogyrophilia@reddit

I've had this problem happen on 3 different computers ever since 24h2 dropped. No error, just no socket in tcp/3389 and thems the breaks.

I've managed to fix it without reimaging because the first case was my laptop and thusly my baby.

Get an installation medium and perform a recovery install :

Start-Process -FilePath "D:\setup.exe" -ArgumentList "/auto upgrade /quiet /noreboot" -Wait

You can also try using the system->recovery->reinstall option on windows settings.

Doing this generates a new SID and it is possibly the specific root cause of this behavior that there are duplicate SIDs

Seems unlikely for my case, but it may be a case for other people experiencing similar issues.

PS_TIM@reddit

There used to be a bug where you had to turn off rdp via server manager and turn it back on and it would fix it.

Zatetics@reddit

Is there a 3391 listener?