RDP Server met constant vasthangende clients

[heggico]

Mijn vraag
Ik zie door de bomen het bos even niet meer, dus stel ik hier de vraag op de hoop dat iemand me kan wijzen op iets wat ik mogelijk over het hoofd heb gezien of iets dergelijks.

Ik heb bij een klant een terminal server staan met windows server 2016 met een stuk of 10 clients op een mix van thin clients en laptops/desktops. Nu heeft vrijwel iedereen hier last van het vasthangen van sessies als ze zijn ingelogd. Ze merken het in eerste instantie in windows explorer die niet meer reageert. Daarna word het steeds erger tot ze nergens meer op kunnen klikken.

In veel gevallen werkt het herstarten van explorer.exe om het probleem op te lossen, maar dat lijkt niet altijd het geval.

Het speelt per client gevarieerd op. De ene week komt het niet voor, de week daarop meerdere keren per dag.

Relevante software en hardware die ik gebruik
Windows server 2016
Clients vooral op windows 10

Wat ik al gevonden of geprobeerd heb

• Server updates
• Bios updates
• Client updates
• Core switch vervangen, welke redelijk oud was
• wifi/bekabeld getest
• ik vergeet vast nog iets...

Ik heb geen idee welke informatie verder benodigd is, mocht ik iets belangrijks vergeten zijn, voeg ik dat nog toe.

[ThinkPad]

CPU- / geheugengebruik?

[heggico]

CPU (Xeon silver 4110) gebruik zit over het algemeen rond de 50% met meerder clients verbonden.
Ram gebruik (36GB) zit meestal rond de 15/20GB, dus meer dan voldoende vrij.

Ik ben ook iets heel belangrijks vergeten, de terminal server draait als VM onder hyper-v

[ Voor 3% gewijzigd door heggico op 29-03-2019 17:24 ]

[Vorkie]

En je storage? Staat die niet op 100% te stampen?

[Daannn1987]

Niets in de event logs ?
Vooral system log?
Is het altijd al zo?
Gebeurd het echt bij alle clients die connecten?
Nemen ze ook printers mee?
Antivirus al eens tijdelijk uitgezet?

[ Voor 11% gewijzigd door Daannn1987 op 29-03-2019 17:33 ]

[Verwijderd]

Zet de audio service eens uit op je RDS?

[ Voor 14% gewijzigd door Verwijderd op 29-03-2019 18:27 ]

[ShaneV]

Verwijderd schreef op vrijdag 29 maart 2019 @ 18:27:
Zet de audio service eens uit op je RDS?

Hebben we zelf vorige week ook moeten doen op 2 terminal servers. Browsers begonnen opeens te crashen zonder reden. Audio service gestopt en alles start terug met werken.

[heggico]

Excuses voor de vertraging, ik had de afgelopen dagen wat weinig tijd. Audio service staat nu nog aan, omdat ik het niet in die hoek had gezocht. Ik zal deze eens uitzetten en kijken of dat verbetering brengt.

In de logs is weinig te vinden, tenminste, voor zover ik kan zien. De sessies op de server blijven ook actief, dus daar lijkt weinig mis te gaan..

Voor zover bekend is dit bij zo goed als bij alle clients. Het is niet geïsoleerd bij bepaalde types clients of een specifiek deel van het gebouw (rotte switch oid)
Soms gaat het een hele tijd goed, dan vallen ze bij bosjes uit (op dat moment is CPU/RAM/Disk usage niet te ver verhoogd)

Meestal is het ook maar 1 client die dan vast hangt, dus het is niet zo dat ze allemaal tegelijk wegvallen.

[Bas.]

Zou het eerder zoeken in je storage. Ook een check gedaan op de disk-health?

Verder beginnen met logs doorspitten op de betreffende server. Wat zie je daar in?

[ Voor 36% gewijzigd door Bas. op 02-04-2019 09:50 ]

[Urk]

Betreft het toevallig een fysieke en recente (14G) Dell server?
Draait de RDS server direct op een fysieke machine of is draait deze virtueel op bijv Hyper-V host? -Sorry al beantwoord zie ik

[ Voor 53% gewijzigd door Urk op 03-04-2019 13:33 ]

[heggico]

Ik had de audio-service uitgeschakeld, maar vrij kort daarna kreeg ik alweer een telefoontje dat het probleem nog steeds optrad. Nu viel me ineens op dat in de logs toch wel erg vaak een tijd resync plaatsvond. (1 a 2 seconde ieder half uur ongeveer)

Ik heb nu de tijdsync laten verlopen via nl.pool.ntp.org, eens kijken of dat verbetering geeft. Naar mijn idee kan dit best een verklaring zijn aangezien de tijd tussen server en client dan ineens kan verschillen, of zit ik dan in de verkeerde hoek te denken?

[Bas.]

heggico schreef op vrijdag 5 april 2019 @ 09:32:
Ik had de audio-service uitgeschakeld, maar vrij kort daarna kreeg ik alweer een telefoontje dat het probleem nog steeds optrad. Nu viel me ineens op dat in de logs toch wel erg vaak een tijd resync plaatsvond. (1 a 2 seconde ieder half uur ongeveer)

Ik heb nu de tijdsync laten verlopen via nl.pool.ntp.org, eens kijken of dat verbetering geeft. Naar mijn idee kan dit best een verklaring zijn aangezien de tijd tussen server en client dan ineens kan verschillen, of zit ik dan in de verkeerde hoek te denken?

Ga logs doorspitten. Dit is echt op de gok dingen proberen.

[heggico]

Daar ben ik idd aan begonnen, daarom viel deze tijd issue me ook op, al heb ik geen idee hoe ik deze niet eerder heb gezien.
Ik hoop dat dit het probleem was, anders ga ik eens verder zoeken.

[heggico]

De tijd-sync was niet het probleem. Er zijn nog steeds vasthangende clients.

Nou heb ik van de week het volgende weer gevonden, 4 minuten voordat ik een telefoontje kreeg dat er iemand weer vast hing:

code:

Naam van toepassing met fout: ShellExperienceHost.exe, versie: 10.0.14393.2339, tijdstempel: 0x5b1f1748
Naam van module met fout: twinapi.appcore.dll, versie: 10.0.14393.2848, tijdstempel: 0x5c7f62e8
Uitzonderingscode: 0xc000027b
Foutmarge: 0x000000000006d2f4
Id van proces met fout: 0xcfa8
Starttijd van toepassing met fout: 0x01d4eb79d7354c2b
Pad naar toepassing met fout: C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
Pad naar module met fout: C:\Windows\System32\twinapi.appcore.dll
Rapport-id: a8730c04-6e30-45c5-9ed3-a8895ce38e49
Volledige pakketnaam met fout: Microsoft.Windows.ShellExperienceHost_10.0.14393.2068_neutral_neutral_cw5n1h2txyewy
Relatieve toepassings-id van pakket met fout: App

Dus de server is nu even een sfc /scannow aan het draaien, kijken of dat iets oplevert, anders moet ik even verder kijken

[Verwijderd]

Probeer je AppX packages eens opnieuw in te stellen:

Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

[MAX3400]

Op basis van je startpost: het is random per client en "dus" is het profile-based of "negotiation-based".

Ik neig ernaar om te zeggen dat je last hebt van RDP clipping dus kom maar op met de exacte policies die op RDP geconfigureerd staan (server en client) maar ook je netwerklogging tussen client X en server Y.

Misschien heb je last van MAX3400 in "WINDOWS 2016: RDS Gateway upload performance"

[Creep]

Heeft het iets te maken met inactieve TS/RDS ports? Gaat het wel een tijdje goed na een reboot?

[Squ1zZy]

MAX3400 schreef op woensdag 10 april 2019 @ 10:12:
Op basis van je startpost: het is random per client en "dus" is het profile-based of "negotiation-based".

Ik neig ernaar om te zeggen dat je last hebt van RDP clipping dus kom maar op met de exacte policies die op RDP geconfigureerd staan (server en client) maar ook je netwerklogging tussen client X en server Y.

Misschien heb je last van MAX3400 in "WINDOWS 2016: RDS Gateway upload performance"

@MAX3400 gaat voor de whiskey

RDP clipping betwijfel ik, maar de policies klinken wel interessant om eens uit te zoeken. Vind het gek dat in logs weinig te vinden is. Je zou zeggen dat voordat explorer crasht er wel een melding komt.

[heggico]

We zijn weer even verder, ik zal even wat reacties plaatsen.

Verwijderd schreef op woensdag 10 april 2019 @ 10:03:
Probeer je AppX packages eens opnieuw in te stellen:

Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Wat doet dit precies? Voor zover ik kan zien herconfigureerd dit de systeemapps zoals explorer?

MAX3400 schreef op woensdag 10 april 2019 @ 10:12:
...

Ik neig naar netwerkproblemen, dus ben nu even een pctje aan het installeren met wireshark en nog wat tooltjes. Maar wil je elke policy die maar iets met RDP te maken hebt zien? Of ben je specifiek op zoek naar iets? Het is ook puur intern dat ze met deze clients problemen hebben, dus externe firewall is niet van toepassing. Udp poort staat open in de firewall op de host.

Creep schreef op woensdag 10 april 2019 @ 10:36:
Heeft het iets te maken met inactieve TS/RDS ports? Gaat het wel een tijdje goed na een reboot?

Het gaat niet beter na een reboot, ook na langere tijd gaat het vaak gewoon goed, en af en toe fout. Ik denk dus niet dat het hiermee te maken heeft.

Squ1zZy schreef op donderdag 11 april 2019 @ 06:41:
[...]


@MAX3400 gaat voor de whiskey

RDP clipping betwijfel ik, maar de policies klinken wel interessant om eens uit te zoeken. Vind het gek dat in logs weinig te vinden is. Je zou zeggen dat voordat explorer crasht er wel een melding komt.

De crash leek me toen voor de hand liggend, maar gisteren zijn er blijkbaar weer 4 personen geweest die vasthingen en nu zie ik hier geen crashes van te voren van in de logboeken.

Ik kon in de logboeken nog steeds weinig vinden, maar in de servermanager van de extern bureaublad-services zie ik opvallend veel foutmeldingen, stom om dit niet eerder te checken, ik dacht dat dit ook in de logboeken zelf terecht kwamen.
Hier een greep uit de errors (maar er zijn er dus enorm veel meer)

code:

Onderdeelnaam:CAAUDPClientChannel, :: 'completionKey is NULL' in CAAUDPClientChannel::Shutdown at 493 err=[0x80070057], Foutcode:0x80070057
Onderdeelnaam:CClientProxyTransport, :: 'Gateway Error' in CClientProxyTransport::SetErrorStatus at 2847 err=[0x8007274c], Foutcode:0x8007274C
Onderdeelnaam:CAAUDPClientChannel, :: 'SecureTunnel' in CAAUDPClientChannel::HandleChannelConnect at 958 err=[0x8007274c], Foutcode:0x8007274C
Onderdeelnaam:CAAUDPClientChannel, :: 'DTLS Connect using all available sockets failed' in CAAUDPClientChannel::SecureTunnel at 1155 err=[0x8007274c], Foutcode:0x8007274C
Onderdeelnaam:CAAUDPClientChannel, :: 'All tries to connect to server failed with no reply ' in CAAUDPClientChannel::TryConnectToServer at 1735 err=[0x8007274c], Foutcode:0x8007274C
RDPClient_TCP: Er is een fout opgetreden bij de overgang van TcpStateConnectingTransport naar TcpStateDisconnected als reactie op TcpEventConnectionTimeout (foutcode 0x80004004).

Ik ga even googlen wat hier de oorzaak van kan zijn.

[heggico]

Ik neig nog steeds naar een probleem met de shellexperiencehost, want ik heb de afgelopen dagen eens wat meer er op gelet, en deze melding komt toch regelmatig voor vlak voor iemand vasthangt:

code:

Het pakket Microsoft.Windows.ShellExperienceHost_10.0.14393.2068_neutral_neutral_cw5n1h2txyewy+App is beëindigd omdat het onderbreken te lang duurde.

Helaas bied google me ook met deze weinig uitkomst.
Afgelopen tijd is het wisselvallig geweest, met dagen zonder vasthangers tot dagen met meerdere per dag

[MAX3400]

Vooralsnog lees ik (nog) niet of je je hebt ingelezen in de suggestie van Verwijderd in "RDP Server met constant vasthangende clients"

Daarnaast zei je wel dat UDP open staat maar je logs in heggico in "RDP Server met constant vasthangende clients" geven toch veel errors op UDP.

Ben een beetje zoekende waarom we in anderhalf / twee weken geen oplossing vinden (middels jou) voor de errors terwijl de logs wel lijken (nadruk) te wijzen naar onze suggesties.

Andere vraag; ben je ooit doorgemigreerd van roaming / mandatory profiles? Of heb je ergens een dubbele GPO zonder inheritance die op forest-niveau toch inherited is door Microsoft?

[heggico]

De AppX package had ik al gedraaid idd, dit heeft niet geholpen.
Ik heb daarnaast ook het volgende gedraaid:
scf /scannow
DISM /Online /Cleanup-Image /ScanHealth

Voor de rest was ik nu aan het kijken naar:
https://discussions.citri...6-rds-startmenu-problems/

Waar word gewezen op de registry keys AppxAllUserStore van een "goede" server te pakken en die te gebruiken. Na een backup heb ik dat geprobeerd, maar ik kan geen keys importeren in de "foute" met de error "Er is een fout opgetreden bij een poging om toegang tot her register te krijgen."
Ik ben lokal (niet domain) admin ingelogd, ik heb die registerkey de administrator user als owner gezet (stond op de groep administrators) en nog lukt het niet. Even kijken waarom dit fout gaat...

Ik vroeg nog welke policies je zou willen zien, daar wachten ik nog op eigenlijk. Kwa profielen heb ik het even nagevraagd, maar blijkt dat deze profielen dus wel ooit gemigreerd zijn. Ik ben er van uit gegaan dat dit niet het geval was. Even op een rijtje krijgen wat daarmee is gebeurd voor de rest, want nu weet ik zelf niet meer zeker wat er allemaal met de profielen is gebeurd...

[L0g0ff]

Heb je misschien snapshots draaien rond die tijden? Of zit je antivirus dwars?

Rotte netwerk paden misschien of dns issues?

Hangt alleen je terminalserver of heel de host?

Is hebt mogelijk om die ts te clonen en de ene helft op de ene server te zetten en de andere helft op de andere? Mogelijk dat een specifieke gebruiker iets triggert.

Zou ook verklaren waarom je er soms een paar dagen geen last van hebt.

[DJSnels]

Dus de gebruikers hebben al een kleine 2 weken issues dus, hoeveel moeite is het om gewoon een nieuwe RDS uit te rollen? Daarmee sluit je in ieder geval de huidige installatie uit. Probeer het eerst met een aantal light users met alleen Office e.d. Om te checken of het wellicht een van de gebruiker-specifieke applicaties is.

[GrasshopperNL]

Ik heb ook deze problemen gehad. Opgelost met deze aanpassing.:

Op de cliënt:

`HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client`

Set `fClientDisableUDP` to 1

https://www.reddit.com/r/..._rdp_connections_failing/

[ Voor 27% gewijzigd door GrasshopperNL op 30-04-2019 00:00 ]

[heggico]

@L0g0ff Het is niet zo dat de RPD sessie hangt. Ze kunnen nog steeds met sommige programma's verder werken, maar explorer vensters en de taakbalk hangen vast. Het is dus niet zo dat de hele RDP sessie niet meer reageert. Het is dan ook puur voor een enkele client tegelijk, en niet voor alle users in een keer.

@DJSnels Het liefst had ik de problemen natuurlijk gewoon snel opgelost, maar gewoon een nieuwe RDP uitrollen begint langzamerhand toch aantrekkelijk te worden. Mogelijk dat dat de problemen gewoon oplost.

@GrasshopperNL Dat ziet er naar uit als een totaal ander probleem, want het gebeurt een tijdje nadat de client gewoon gebruik heeft gemaakt van de RPD. niet tijdens inloggen en ze krijgen ook geen foutmeldingen. Explorer reageert gewoon niet meer. Al kan ik ook op de clients UDP eens uitzetten..

Aangezien het vooral een 3tal users is die eigenlijk alleen deze problemen hebben ga ik deze zowieso al eens een nieuw profiel geven, kijken wat dat gaat doen.

[heggico]

Ik heb nieuwe profielen aangemaakt voor de grootste probleemgevallen, maar 2 uur daarna kreeg ik alweer een telefoontje dat iemand met het nieuwe profiel vasthing. Het zit hem dus echt ergens anders in.

Ik ga nog even verder met bovenstaande mogelijke oplossingen. Daar ben ik helaas nog niet aan toe gekomen.

[floorcleaner]

Komt het probleem ook voor als er minder users tegelijk werken ? Heb je daar een idee van ?

[BLACKfm]

Hoe lang speelt dit al? Ik kan uit de informatie hier niet ophalen (of heb er overheen gelezen) of het een nieuwe server betreft of dat deze al een tijdje (maanden/jaren) draait. En of er daarvoor ook problemen waren.

Mogelijk is één en ander te herleiden naar bepaalde installaties / instellingen in het verleden?

[kevinyfz]

Wellicht door een programma zoals Startisback zodat ze hun gewende startknop krijgen?

Wellicht een programma in de rechtermuisknop. Denk aan bijvoorbeeld een zip programma. Iets wat met de explorer te maken heeft lijkt mij?

[MAX3400]

kevinyfz schreef op dinsdag 14 mei 2019 @ 10:58:
Wellicht door een programma zoals Startisback zodat ze hun gewende startknop krijgen?

Wellicht een programma in de rechtermuisknop. Denk aan bijvoorbeeld een zip programma. Iets wat met de explorer te maken heeft lijkt mij?

Je denkt dat gebruikers dit soort "meuk" mogen installeren?

[kevinyfz]

MAX3400 schreef op dinsdag 14 mei 2019 @ 11:29:
[...]

Je denkt dat gebruikers dit soort "meuk" mogen installeren?

Gebruikers niet.. De beheerder wel lijkt me. Als meerdere gebruikers aangeven dat ze niet kunnen wennen aan de nieuwe startknop in een 2016 omgeving kan ik mij voorstellen dat een beheerder eventueel een programma installeert zoals startisback.

[Urk]

Zoals al eerder hierboven gevraagd maar nooit antwoord op ontvangen: betreft het hier als Hyper-V host een recente fysieke Dell server? 13G of 14G?

[heggico]

kevinyfz schreef op dinsdag 14 mei 2019 @ 10:58:
Wellicht door een programma zoals Startisback zodat ze hun gewende startknop krijgen?

Zucht, je was in de goede richting. Op verzoek van gebruikers was classic shell geinstalleerd. Nadat we deze verwijderden verdwenen alle problemen met hangende clients als sneeuw voor de zon.

Ik zat allemaal weer veel te lastig te denken, het antwoord was zo simpel.

Bedankt voor de hulp allemaal! Afgelopen 2 weken heeft 1 persoon vast gehangen met een ander probleem, dus het lijkt opgelost.

Dit was natuurlijk iets wat ik niet gemeld had in dit topic, excuses hiervoor, anders was het waarschijnlijk al een stuk eerder gevonden.