none
Windows Server 2019 - RDS - Friert für mehrere Sekunden ein RRS feed

  • Frage

  • Hallo community,

    ich kämpfe seit fast zwei Monaten mit einem seltsamen Phänomen. Bereitgestellt wird eine Windows Server 2019 RDS Site (Patchstand Nov 19) bestehend aus 6 Servern. Für etwa 50 Benutzer. Im Durchschnitt bei einem gesperrten System also 10 Benutzer pro Server. Virtualisiert sind die Server auf zwei Windows Server 2016 Hyper-V Clusterknoten (Patchstand Nov 19). Die RDS-Hosts sind mit 8-10 Kernen und 24Gbyte RAM ausgestattet.

    Je nach Anzahl der Benutzer erhöht sich die Wahrscheinlichkeit, dass der Server unregelmäßig einzufrieren scheint. Bereits geöffnete Windows-Fenster lassen sich zwar noch wechseln, neue Prozesse oder gar der Zugriff auf Netzwerkpfade, Laufwerke oder Netzwerkdrucker ist nicht möglich (Die Inhalte der Ordner können nicht dargestellt werden). Die RDP-Verbindung bleibt aber stabil und flüssig, das Netzwerk ist nicht ausgelastet. Auch der Explorer lässt sich nicht mehr offnen. Nach einigen Sekunden bis Minuten arbeitet der Server dann alle getätigten Klicks und Eingaben im Zeitraffer ab. Auch das Starten gewisser Prozesse wie etwa Remote Desktop Konsole (mstsc.exe) ist in diesem Moment nicht möglich. Alle Netzwerkdrucker haben in diesem Moment den Status "Initialisierung". Der Taskmanager zeigt in diesem Moment nicht wirklich zuverlässig Daten an und hängt teilweise ebenso. Die CPU- oder RAM-Auslastung scheint aber nicht ungewöhnlich hoch zu sein. Es wirkt wie eine Art Memory-Leak.

    Zuvor war in fast gleicher Konstellation eine Windows Server 2012 R2 Site im Einsatz. Hier gab es die Probleme nicht.

    Aktuell liegt der Verdacht bei einem inkompatiblen Druckertreiber. Allerdings lässt sich schwer zuordnen wann genau das Problem auftritt. Ob dies wirklich bei der Benutzerinteraktion "Drucken" stattfindet oder einfach "nur so zwischendurch" auftritt. Im Einsatz sind Canon- und Lexmark-Drucker sowie Canon OCE.

    Die Anti-Viren-Software konnte ich bereits ausschließen, da das Phänomen auch auftritt, wenn keine AV-Software auf dem Server installiert ist. Der serverinterne Exploit-Schutz sowie Windows Defender sind via GPO deaktiviert. Die Web-Suche im Startmenü ist ebenfalls via GPO deaktiviert. Die Windows Firewall ist auf allen Profilen aus.

    Auffällig ist, dass umso mehr Benutzer auf dem Server sind, dass Problem häufiger und intensiver auftritt, obwohl der Server keine starke Auslastung erfährt. Arbeiten wenige Benutzer auf dem System tritt das Problem selten bis garnicht auf.

    Mir ist bewusst, dass die Angaben sehr oberflächlich sind, gerne gebe ich auch mehr Details, es würde mich jedoch interessieren, ob jemand ein ähnliches Verhalten kennt oder beobachtet hat.

    Vielen Dank für jegliches Feedback.

    Grüße Leon


    Montag, 23. Dezember 2019 14:58

Alle Antworten

  • Moin,

    ich habe das persönlich noch nicht erlebt, aber ein paarmal in der Community gehört.

    Nur um sicherzugehen: Deine Gegenüberstellung 2012R vs. 2016 --> hattet ihr früher 2012er RDSH auf 2012er Hyper-V und jetzt 2019er RDSH auf 2016er Hyper-V oder sah die Konstellation irgendwie anders aus?

    Ansonsten würde ich einen PerfMon Trace auf Gast *und* Host anschmeißen (CPU, Auslagerung, Plattenlatenz, Warteschlangenlänge) und abwarten bis der Freeze wieder beginnt und dann wieder vorbei ist. Dann weiß man vielleicht mehr...


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 24. Dezember 2019 08:41
  • Hallo Herr Smirnov,

    die Windows Server 2012 R2 RDS Site lief exakt auf dem gleichen Hyper-V Cluster basierend auf Windows Server 2016. Das Hyper-V Cluster wurde also nicht verändert/geändert.

    Ich habe zum gegeben Zeitpunkt bisher nur ProcMon Logs gesammelt. Allerdings sind die Datenmengen auf einem RDS-Hosts extrem... 

    Warteschlange und PerfMon ist auf jeden Fall noch einmal eine Idee.

    Danke und schönes Feiertage.

    Dienstag, 24. Dezember 2019 09:09
  • Gibt es hierzu neue Erkenntnisse??

    Ich habe dieses Problem auch bei Windows 2019 RDS Sammlungen. Ich dachte das es am Client liegt, also habe ich alle Windows 10 Clients auf !909 gehoben aber leider passiert es immer noch.

    Freitag, 14. Februar 2020 09:01
  • Hallo Kalf1,

    ich konnte das Verhalten "umgehen", indem ich die SMB-1 Unterstützung für den SMB-Client auf den RDS-Servern nachinstalliert habe. Klar ist dies keine Lösung und nicht auf Dauer zu empfehlen, verschafft aber Zeit zur weiteren Analyse. Bei mir war es vermutlich ein veralteter Drucker-Treiber von Canon (VarioPrint) der das Problem aufgrund der fehlenden Abwärtskompatibilität im SMB-Client verursachte.

    Hier noch mein Artikel dazu:

    https://it-feed.de/windows-server-2019-mit-rds-citrix-virtual-app-sessions-freeze-und-verlust-von-smb-sitzungen/

    Viel Erfolg weiterhin!

    • Als Antwort markiert LGawinski Sonntag, 16. Februar 2020 19:45
    • Tag als Antwort aufgehoben LGawinski Sonntag, 16. Februar 2020 19:46
    • Als Antwort markiert LGawinski Montag, 17. Februar 2020 12:36
    • Tag als Antwort aufgehoben LGawinski Montag, 24. Februar 2020 13:13
    Sonntag, 16. Februar 2020 19:45
  • Hallo miteinander,

    ich würde gerne nochmal nachhaken, ob jemand einen anderen Ansatzpunkt, als die SMB-1 Unterstützung hat.

    SMB-1 ist bereits installiert, aber das Problem besteht nach wie vor. Diagnose ist nicht möglich, weil weder auf der CPU/Speicher/HD/Netzwerk irgendeine Last zu entdecken ist. Eine parallele Sitzung läuft wie geschmiert, aber auf der anderen steht das System scheinbar.


    Mittwoch, 19. Februar 2020 11:54
  • Hallo J.P.Endress,

    ihr stellt doch sicher Drucker in eurer RDS-Umgebung bereit? Kannst du sagen, welche Druckertreiber ihr einsetzt? Ggf. gibt es hier parallelen. 

    Sofern ihr einen zentralen Printserver habt, kannst du prüfen ob die definierten Drucker- Standardeinstellungen korrekt und unmittelbar auf die RDS-Hosts propagiert werden?

    Kannst du bitte auch mit folgendem PowerShell-Befehl prüfen, welche Dialekte via SMB gesprochen werden, währen das Problem auftritt:

    Get-SmbConnection

    Grüße




    • Bearbeitet LGawinski Freitag, 21. Februar 2020 12:32
    Freitag, 21. Februar 2020 10:43

  • Hallo,
    in der Tat ist das Problem bei mir heute erneut aufgetreten... Es war ein Monat lange ruhe und heute tritt es wieder auf. Bin gerade etwas ratlos.

    Einzige Änderungen, Installation der folgenden Updates:
    - KB4537759
    - KB4532691 (CU 2020-02)
    - KB4524244

    Interessant ist höchstens das CU 2020-02. In diesem Update geht es unter anderem um:

    - Updates zum Speichern und Verwalten von Dateien.
    - Updates zur Optimierung der Sicherheit bei Verwendung von externen Geräten (z. B. Gamecontroller, Drucker und Webcams) und Eingabegeräten wie Maus, Tastatur oder Tablettstift.

    Außerdem haben wir eine zusätzliche Schriftart (Font) installiert.

    Wenn das Problem auftritt hängt der gesamte SMB-Client. Kein Benutzer hat mehr Zugriff auf Shares oder Drucker...

    Ich bin echt ratlos und für jeden Tipp dankbar...

    • Bearbeitet LGawinski Montag, 24. Februar 2020 13:20
    Montag, 24. Februar 2020 13:19
  • Hallo zusammen,

    ich habe am Dienstag einen Virenscanner auf dem Fileserver installiert und danach ist der gesammte Betrieb zusammengebrochen. Am Folgetag habe ich den Kaspersky wieder deinstalliert und den Windows Defender habe ich erstmal deaktiviert gelassen.

    Siehe da: Alles gut. Terminalserversitzungen ohne irgendwelche Probleme und die Clients im Betrieb laufen wie geschmiert.

    Jetzt begebe ich mich also auf die Suche nach einem Virenscanner, der mit Windows Server 2019 umgehen kann und dann hoffe ich, dass ich das Problem im Griff habe.

    Freitag, 6. März 2020 11:03
  • Hi Leon,

    wir haben ein ähnliches Problem.
    Konnte dein Problem gelöst werden?

    Gruß Dedi
    • Bearbeitet Dedi75 Montag, 31. August 2020 15:15
    Montag, 31. August 2020 15:15
  • Ich habe damals Avast installiert und den Windows Defender deaktiviert gelassen.

    Seit dem habe ich Ruhe und keine Klagen mehr gehört und das Verhalten auch selber nicht mehr beobachtet.

    Montag, 31. August 2020 15:34
  • Hallo Dedi,

    das Problem konnte wir leider bis jetzt nicht beheben bzw. haben wir bis heute keinen klaren Rückschluss darauf, welche Komponente der Verursacher war/ist. Es ist aber über drei Monate lang nicht mehr aufgetreten bis vor kurzer Zeit... Seit etwa 2-3 Wochen ist es wieder present.

    Folgende Dinge haben wir bisher bei uns ausgeschlossen:

    - Viren Scanner (Drittanbieter und MS Defender)
    - Threat Detection (Kernelebene)
    - Sysprep der Systeme
    - Arbeitsspeicher (Hypervisor)
    - Hardware (Hypervisor)
    - Ressourcen der VMs (CPU, RAM, Netzkwerk)

    Ich habe parallel ein ähnliches System von Grund auf neu installiert und auch diesem "frischen" System tritt das Phänomen auf. Auch die Hardware für den Hypervisor wurde gewechselt. Der zuletzt gemeinsame Nenner:

    - Windows Server 2019 Standard (1809) mit RDS-Rollen
    - Citrix Virtual Apps 1909
    - Storage-System | CIFs für Profile und Ordnerumleitungen
    - Office 2019 Standard

    Die letzten beiden Punkte werden aktuell wieder verstärkt begutachtet. Ich bin mir sicher, dass es kein Leistungsproblem, sondern vielmehr ein Konflikt (Applikationsebene) ist.

    Es steht bei uns noch die exakte Netwerkpaket-Analyse via Wireshark aus. Procmon brachte leider Erkenntnisse.

    Derzeit überprüfe ich die Office Telemetry als Verursacher sowie die CIFs-Mechanismen auf dem Storage-Systemen.

    Vielleicht hilft es bei der Analyse. Für alle Erkenntnisse bin ich dankbar!

    Montag, 31. August 2020 18:22
  • ipv6 ? Ich lass das mal einfach so stehen. Bitte keine Debatten deswegen, einfach mal testen.


    Montag, 31. August 2020 20:48
  • @J.P.Endress: IPv6 ist sei Beginn an deaktiviert, wenn dann wäre nur das Aktivieren eine Möglichkeit. Allerdings wurde im Verlauf der Analyse auch die NIC der VM vollständig neuinstalliert.



    • Bearbeitet LGawinski Dienstag, 1. September 2020 08:09 Rechtschreibfehler
    Dienstag, 1. September 2020 08:08
  • Hallo @LGawinski,

    wir haben exakt das gleiche Problem seid wir bei Kunden Server 2019 einsetzten.

    Unterschiedliche Netze, unterschiedliche Hardware (ESX / Hyper-V).

    Der einzige gemeinsame Nenner ist eben Server 2019.

    Habt Ihr bisher eine Lösung finden können? 

    beste Grüße

    Dienstag, 7. September 2021 11:18
  • Moin,

    ich habe gesehen, dass das schon etwas älter ist. Da aber dieses Problem öfter beobachtet wird, möchte ich meine Erfahrung beisteuern.

    Zu Beginn des Threads wurde allgemein auf Perfmon hin gewiesen, in der Folge wurden aber keine Ergebnisse diskutiert. Dies ist aber wirklich der beste Ansatzpunkt. Ich habe bis zu 130 User auf mehreren Terminal Servern verwaltet und dabei folgende Erfahrungen gemacht:

    1. Hat der Server mehr als nur ausnahmsweise CPU Lasten von über 30%, bemerken alle Benutzer Einschränkungen (eine rein empirische Beobachtung von mir).

    2. 24 GB RAM pro virtuellen Server für 10 Benutzer (wie vom Thread Ersteller angegeben) ist natürlich extrem knapp. Firefox und ein PDF pro Nutzer sprengen da ja bereits jeden Rahmen. Ich halte es für möglich, dass ein solcher Server nur im Swapping ist.

    3. Zumindest noch vor ca. 3 Jahren, als ich zuletzt mit Kaspersky gearbeitet habe, konnte ich ebenfalls regelmäßig feststellen, dass Kaspersky auf Mehrbenutzer Systemen die Festplattenzugriffe enorm bremsen kann. Eine Beobachtung, die ich mit ESET nicht mehr mache.

    4. Den Microsoft Defender habe ich bislang bei mir nie in einer Gleichung mit Performance Problemen gehabt. Soll heißen, ich habe nie Auswirkungen durch (De-)Aktivieren gesehen. Ich persönlich sehe keine Veranlassung, ihn zu Deaktivieren.

    5. Wie es um den Festplatten Speicher bestellt ist, habe ich ggf. überlesen. Aber gerade die Festplatten I/Os sind natürlich wichtig, wenn mehrere Terminal Server (wie hier beschrieben) auf einem Host laufen. Ist ein Server am Swappen (s.o.) zieht das natürlich alle anderen VMs runter, selbst wenn RAM und CPU im Überfluss da ist.

    Ich hoffe, das hilft jemandem weiter.

    Donnerstag, 18. November 2021 16:50
  • Hallo Leon,

    alles, was in diesem Thread an Symptomen, Analyse- und Reparaturversuchen, usw. beschrieben wurde, haben wir in einem Kundenprojekt ebenfalls durch. Ich zähle nicht noch mal auf, aber es ist ein reiner 2019er Hyper-V auf dem ausschließlich 2019er Server sowie ein 2019er RDS-Server im Einsatz sind.

    Wird auf über Laufwerksbuchstaben gemappte Freigaben zugegriffen oder über einen freigegebenen Drucker gedruckt kommt es sporadisch zu einer Klemme aller Sitzung auf dem selben RDS-Server (aber nur auf diesen), wenn diese auf ein gemapptes Laufwerk zugreifen wollen oder drucken wollen. Wer das nicht macht, kann während so einer Klemme, die durchaus mal bis zu 10 Minuten dauern kann, ohne Problem weiterarbeiten.

    Das Problem gibt es von Anfang an, seit wir den Kunden ca. Mitte Ende 2020 auf Windows Server 2019 modernisiert haben. Seit ca. 1 Jahr ist auch der Microsoft Support mit der Sache befasst, leider jedoch ineffektiv und ohne Ergebnisse.

    Die RDS-VM wurde zwischenzeitlich komplett neu installiert und ausgerüstet und sogar auf eine ganz andere Hardware mit 2019er Hyper-V verschoben. Immer die gleichen "Klemmer", denen wir nicht auf die Spur kommen.

    Hast Du inzwischen von einer Lösung erfahren?

    Donnerstag, 10. März 2022 17:04
  • MS hat das Problem endlich behoben

    https://support.microsoft.com/en-us/topic/february-15-2022-kb5010427-os-build-17763-2628-preview-d29de7d8-9646-486b-b9b1-c8e4fbe6bac0

    wir haben seit dem keine Probleme mehr und keine Blackscreen mehr.

    Donnerstag, 10. März 2022 17:56