Home   2026-10-22 19:56:51

←

Klanten klagen over falende RDS-verbindingen na laatste Windows Server-update

Original article

Klanten met Windows Server 2025 en 2022 klagen over problemen met remote desktop-verbindingen na de laatste update. Die cumulatieve update had wel een wijziging op het gebied van remote desktop, maar geen bekende problemen.

Nieuwe Remote Desktop Protocol-verbindingen blijven hangen op 'connecting', claimt een Reddit-gebruiker in een post die veel bijval krijgt van systeembeheerders. Alleen een reboot verhelpt het probleem, waarna het vaak snel weer optreedt. Het probleem treedt op zodra een verbinding of uitlogactie blijft haken, waardoor onder meer Taakbeheer vastloopt. Hierdoor kunnen nieuwe gebruikers niet meer inloggen.

Microsoft heeft nog niets gezegd over het probleem. Het is onbekend hoe wijdverspreid het is. De update kwam dinsdag uit. Het probleem lijkt op te treden bij alle Windows Server-versies die de update hebben gehad. De changelog vermeldde dat de update de audio bij remote desktop beter zou moeten afhandelen.

Patch Tuesday

Die update kwam dinsdag tegelijk uit met een cumulatieve update voor de desktopversie van Windows. Behalve een recordaantal patches is dat de update die voor alle gebruikers de verplaatsbare taakbalk terugbrengt en de mogelijkheid geeft de taakbalk kleiner te maken. Gebruikers kunnen Bing ook uit de zoekfunctie van Windows verwijderen. Daarnaast moet Verkenner sneller laden.

Windows Update, mei 2026

Door Arnoud Wokke

Redacteur Tweakers

Feedback • 10-09-2026 19:54
35 • submitter: Slavy

10-09-2026 • 19:54

35

Submitter: Slavy

Reacties (35)

Wij hadden onlangs een probleem waarbij wij geen remote desktop connectie meer konden maken naar onze DC's. De remote desktop services was actief maar de listening poort bleek niet te draaien> (3389)

Een reboot van de server of restart van de rdp services verhielp het probleem tijdelijk.

Als je de volgende registry key zet was het probleem weg:

value "fDenyTSconnections" onder "HKEY_LOCAL-MACHINE\SYSTEM\CurrentControlSet\Control\Terminal\Server" op 0

Standaard stond deze bij ons op 1, wat op zich op een bug lijkt want via onze GPO hadden we deze waarde op 0 gezet (=enabled)

Meer info:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-cannot-connect-remote-computer

Open Registry Editor and make sure these keys are set as follows:
  • The DWORD value fEnableWinStation has the value data of 1.

    Default path: Computer\HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp
  • The DWORD value fDenyTSConnections has the value data of .
    • Default path: Computer\HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
    • Policy path (if the policy is configured): Computer\HKEY\_LOCAL\_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Check dus op de Server of je de listening poort ziet. Als je geen 3389 poort ziet staan maar de services draait wel, zou bovenstaande registry oplossing je probleem kunnen verhelpen.

@dank dasiro, typo in DWORD value aangepast.

[Reactie gewijzigd door Tmaster op 11 september 2026 09:58]

Als je de volgende registry key zet was het probleem weg:

value "fDenyTSconnectins" onder "HKEY_LOCAL-MACHINE\SYSTEM\CurrentControlSet\Control\Terminal\Server" op 0
typo: fDenyTSconnections

[Reactie gewijzigd door dasiro op 10 september 2026 20:46]

Die key is gewoon het vinkje enable remote desktop connections to this machine. Het vinkje uit zet de waarde op 1, aan op 0. Stuk makkelijker dan regedit.
wacht even waarom kun je uberhaubt een Remote desktop connectie maken naar jouw DC.

DC`s zouden in core mode moeten draaien en beheerd worden via shell.
Dat zou je dan doen om de attack surface te verkleinen. Maar ja, wil je Active Directory, DNS, DHCP en alle andere zut beheren die op de DC staan dan moet je weer een beheerserver inrichten met al die management tools op een OS met een GUI. Ja je maakt het was lastiger, maar je verplaatst de attack vector alleen. Helemaal erg : de tools draaien vanaf een werkstation.

Ter referentie : ik beheer nu een setje Exchange Servers die op Windows Core draaien. Ja het kan en ja het werkt. Maar het beheer is een leercurve ten opzichte van een server met een Desktop OS erop.
Naast full server ook je DC als beheer server gebruiken? Denk dat ik eens rond zou moeten kijken bij jullie krijg meer het gevoel dat er veel open kansen liggen voor redhat.

Een DC werkt security technische anders dan een member server. Daarom is het ook niet toegestaan en supported om andere applicatie op een DC te hosten. Enige uitzondering waren de SBS maar dan had je het over enorm kleine bedrijven. Die zouden geen onprem meer moeten hebben.

Als dat het nivo van beheer is dan denk ik dat we na account compromise zo aardig wat stappen lateral movement kunnen doen.

En voor exchange is het gewoon een non issue daar hoef je helemaal niet op de server te komen,. Ik heb langetijd nog design en beheer gedaan voor 200 servers cluster.

Heb zelf al een paar keer support gedaan bij een full domain compromise, kan het je niet aanraden.

[Reactie gewijzigd door Scriptkid op 11 september 2026 07:38]

Beheer voor 200 MKB klanten werkt dan ook totaal anders.
weet niet wat je definitie van MKB is,

Maar < 10 servers kun je best een beheer werkstation neer zetten en >10 servers zou je ze beter kunnen moven SAAS of IAAS. en dan heb je beheer stations er bij zoals bastion.
Je hebt ook nog een heel segment met 0 of 1 servers. En als je dat op een enterprise manier wilt beheren dan krijg je er 2 grote problemen bij.

1) De kosten lopen dermate op dat vrijwel geen enkele klant dit kan (is niet gelijk aan wil) betalen.
2) Daarnaast heb je zeer goede engineers nodig die dit kunnen en die komen niet voor een job waar ze 95% van de tijd onder hun niveau moeten werken.
segmenten met 0 servers hoeft je toch niet op aan te loggen ?

segmenten met 1 server hebben toch een route naar dat segment dan kan er ook een from open staan vanuit een managed machine.

Maar goed deze segmenten zouden al SAAS moeten zijn of IAAS , of virtual en dan maakt 1 server extra niks uit zit in de zelfde licenties van de host etc.

zeer goede engineers valt wel mee, elke junior kan je dit leren in 1 a 2 weken, it aint rocket science.

We hebben heel veel klanten en zelf ook projecten gedaan waar dit gewoon heel goed gaat. En ja if you pay peanuts of outsourced aan de goedkoopste , dan kun je challanges krijgen.
Segmenteren, segmenteren, segmenteren.

Zet je DC's in een eigen netwerk met alleen toegang via rdp vanuit je beheer omgeving. Daar staat een groepje machines met beheertools en voorzien van MFA, bijv. DUO security.

Die beheer machines zelf mag je niet met RDP bij kunnen, daar zou ik een indirecte remote beheer tool voor gebruiken zodat de beheer zone NIET vanuit een "productie" omgeving toegankelijk is. Een 2e fysiek systeem in een dmz netwerk met ook mfa puur voor een remote (jumphost achtige) verbinding naar die beheer omgeving zou nog kunnen, maar wel met strikte policies over wie erop kunnen aanmelden en wanneer.

Of je nou rdp gebruikt of een remote powershell het moet heel duidelijk afgebakend zijn waar je dat vanaf kunt doen en dat moet maximaal beveiligd zijn.
Joh dat is overal het niveau. Het vervelende is dat als je de boel helemaal dichttimmert dat een collega met minder ervaring er niks meer mee kan en de senior altijd de sjaak is. Met DCs is dat nog te overzien, maar Exchange moet je vaker babysitten. Remote beheer is overigens ook gewoon een attack vector, zoals gezegd verplaats je hem alleen.
zeker maar een Exchange server compromise of een beheer server compromise is een heel andere vector, en bij remote beheer connect je als je het goed doet in het isolated stukje van wat je beheerd en met rechten om alleen dat stukje te beheren. Je doet geen remote beheer met local admin.

Bij een beheer server compromise zijn je edb`s in tact, bij een Exchnage server compromise zijn je EDB files at risk en kun je beschouwen als verloren.

Inloggen op een DC zou ook alle SOC red flags moeten triggeren, als je het als beheer server gaat gebruiken ziet men heel snel niet meer het verschil tussen valid , niet nodig en attack

[Reactie gewijzigd door Scriptkid op 11 september 2026 08:02]

Ik ben het in de basis met je eens, dus het is geen tegenargument, maar als je beheerserver is gehackt dan is het een kwestie van tijd voor je een total breach hebt. Het is een kwestie van afwegingen maken, en hoeveel budget/tijd je krijgt van degene die het budget bepaalt of de rekeningen betaalt. Ik vind het altijd moeilijk om de 'absolute best practices' van pentesters te lezen, want de realiteit is helaas dat je er meestal gewoon geen tijd of geld voor krijgt
Yep totdat je gehacked ben,

Dan staat er in een eens tonnen aan budget.

Ton uitgespaard 10 miljoen kosten gemaakt voor breach contain

[Reactie gewijzigd door Scriptkid op 11 september 2026 09:01]

Loopt de laatste tijd sowieso niet zo lekker met Microsoft producten.
Wij hadden vorige week last van hangende inloggers op de RDP systemen (2025).
Scherm bleef zwart maar reageerde nog wel op een logoff, opnieuw inloggen ging meestal wel goed.

Vanaf gisteravond veel time-outs op connecties met Azure SQL databases.
Lijkt nu opgelost

Vanmiddag ook problemen tijdens inrichten van een nieuwe laptop, kon geen verbinding voor updates maken tijden de setup.
Standaard wacht ik altijd even met Windows Updates op onze omgeving, juist vanwege dit soort taferelen. Het doet soms meer kwaad dan goed.
Je zal maar net je AVD omgeving hebben bijgewerkt en 350 man kan niet inloggen...
Ik vermoed dat de titel RDP moet bevatten ipv RDS ik dacht even dat het over aws ging :+
RDS is gewoon correct. Heeft niets mer AWS te maken. RDS is gewoon de Remote Desktop Services van Windows.
RDP: Remote Desktop Protocol

RDS is de service die Windows draait. En RDP is wat die service aanbied.
En blijkbaar gebruikt AWS hun Relational Database Service met de RDS afkorting (ondanks dat iedereen database afkort als DB).
Aha weer iets bijgeleerd dank! Had niet door dat RDS de service was kende enkel het protocol. Ik ben iets beter bekend met Linux systemen.
Aha, dank voor de correctie. Heb zelf nooit met AWS gewerkt, vandaar dat ik de kennis over deze afkorting niet had ivm AWS.
In het artikel wordt nergens "Remote Desktop Services" genoemd. Wel "Remote Desktop Protocol". Over het algemeen is het goed gebruik om gebruikte afkortingen minstens 1x uit te schrijven, tenzij het om algemeen bekende afkortingen gaat.

RDP is verder veel gangbaarder dan RDS als het gaat om het benoemen van dit soort verbindingen, net als dat je ook eerder over een SSH-verbinding spreekt dan een SSHD-verbinding.
RDS is de service, maar in de titel staat "RDS-verbindingen". In die context vind ik RDP ook beter passen.

Remote Desktop Protocol verbindingen vs Remote Desktop Services verbindingen.
dan wacht ik wel met de update, ik gebruik RDS .
Gelukkig heb je RDP op servers niet vaak nodig /s. Nou ja, ik ben inmiddels het stadium van boosheid wel voorbij, en het is maar weer ouderwets incompetentie van Microsoft accepteren. Niet-gehaalde oplostijden in de SLA worden gewoon "vendor issue" en niet ons probleem.
Ik gebruikte RDP, maar nadat mijn tot server verbannen oude desktop ineens versleuteld was gewoon weer terug naar Rustdesk na herinstallatie.
Ik denk dat Microsoft met hun Virtual Desktop daar ook gebruik van maakt.
Dus zelfs in de cloud zal dit een issue zijn.
Klopt azure rds 2016 server gaf ineens de melding "Kan de taak die u probeert uit te voeren niet voltooien, omdat Externe bureaublad-services momenteel bezig zijn. Probeer het over enkele minuten opnieuw. Overige gebruikers zouden zich nog steeds gewoon moeten kunnen aanmelden."
Ah vandaar dat ik niet kon verbinden.
Na fysiek inloggen kon ik wel weer inloggen via rdp.
Quality control is echt kansloos bij Microsoft de laatste tijd, en het wordt alleen maar erger. Echt beschamend.
Dat wordt nu door AI en gebruikers in de eerste updateringen gedaan, die afdeling is binnen Microsoft al geruime tijd opgedoekt ;)
Daarom Microslorp dus, en men betaalt ook gewoon nog vlotjes voor die bagger...
Ik kreeg hier vanochtend ineens de klacht dat men na uitloggen niet meer kon inloggen op de rds server 2016. Melding "

Kan de taak die u probeert uit te voeren niet voltooien, omdat Externe bureaublad-services momenteel bezig zijn. Probeer het over enkele minuten opnieuw. Overige gebruikers zouden zich nog steeds gewoon moeten kunnen aanmelden." De rds machine 1 dag teruggezet en het probleem is verholpen. T weekend de updates opnieuw draaien en testen...
Blijkbaar is Microsoft inmiddels wakker geworden: het staat nu officieel als known issue bij de september‑update voor Server 2022. Ze bevestigen dat RDS na de update kan blijven hangen of helemaal niet meer reageert:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2022#remote-desktop-services-might-stop-responding-after-sept--2026-security-update

Je kunt de falende code wijziging op Server 2022 uitzetten met een Feature Override (staat nu in test bij mij): https://gists.mickert.dev/fdf0c8e94b7b7a497e3168345dd2848e

Er gaan ook berichten rond dat je het tijdelijk kunt wegwerken via een GPO‑instelling, maar ik kan die policy zelf nog nergens terugvinden in de documentatie:
https://www.reddit.com/r/Action1/comments/1wcgwbw/comment/p9a9z3z/

Kort gezegd: Microsoft erkent het probleem, fix is onderweg, en er lijkt een workaround te bestaan maar de officiële GPO‑route is nog even zoeken.

[Reactie gewijzigd door mick77 op 12 september 2026 12:28]


Om te kunnen reageren moet je ingelogd zijn