13
RDS-Host macht neuerdings nach 18 Sitzungen dicht
Ein herrliches Problem 
Salve Kollegen.
Unser Remote Desktop Session Host (Server 2019, session-basierte Installation) besitzt 50 RDP Cals. Er wurde längere Zeit nicht mehr so intensiv benötigt, wie jetzt.
Es fiel nun auf, dass er nur noch 18 Nutzer parallel rein lässt, weitere bekamen beim Anmeldeversuch zunächst ein schwarzes Bild (Desktop will sich aufbauen), dann aber die Meldung "der Administrator hat die Sitzung beendet". Erst wenn ein anderer seine Sitzung beendet, kann ein weiterer rein.
Der RD-Lizenzmanager sagt "alles super, es sind noch viele Lizenzen frei".
SFC /scannow sagt "Dateikorruption in 2 Dateien, die mit dem Lizenzmanager zusammenhängen" - aha!
->Windows repariert mittels inplace-upgrade ->sfc findet daraufhin keine Fehler mehr, aber das Problem bleibt unverändert.
->Die RD Cals neu installiert und aktiviert (alles resettet, wie MS das bei Korruption vorschlägt) - es werden nun nur noch sporadisch überhaupt Lizenzen ausgestellt (huch!?) und es kommen weiterhin nur genau 18 Nutzer parallel rein.
Lange Rede kurzer Sinn: da auch das letzte Backup dieses Problem hat (ja, es waren wohl schon länger nicht mehr als 18 Personen drin), muss der Server neu installiert werden, es sei denn, jemand hat so einen Schwachfug schon einmal erfolgreich bekämpft und sagt mir, wie.
Ich werde nicht viel Zeit in "probier doch mal..." investieren, da er wie gesagt dringend wieder laufen muss. Bitte nur melden, wenn diese Symptome bekannt sein sollten.
Salve Kollegen.
Unser Remote Desktop Session Host (Server 2019, session-basierte Installation) besitzt 50 RDP Cals. Er wurde längere Zeit nicht mehr so intensiv benötigt, wie jetzt.
Es fiel nun auf, dass er nur noch 18 Nutzer parallel rein lässt, weitere bekamen beim Anmeldeversuch zunächst ein schwarzes Bild (Desktop will sich aufbauen), dann aber die Meldung "der Administrator hat die Sitzung beendet". Erst wenn ein anderer seine Sitzung beendet, kann ein weiterer rein.
Der RD-Lizenzmanager sagt "alles super, es sind noch viele Lizenzen frei".
SFC /scannow sagt "Dateikorruption in 2 Dateien, die mit dem Lizenzmanager zusammenhängen" - aha!
->Windows repariert mittels inplace-upgrade ->sfc findet daraufhin keine Fehler mehr, aber das Problem bleibt unverändert.
->Die RD Cals neu installiert und aktiviert (alles resettet, wie MS das bei Korruption vorschlägt) - es werden nun nur noch sporadisch überhaupt Lizenzen ausgestellt (huch!?) und es kommen weiterhin nur genau 18 Nutzer parallel rein.
Lange Rede kurzer Sinn: da auch das letzte Backup dieses Problem hat (ja, es waren wohl schon länger nicht mehr als 18 Personen drin), muss der Server neu installiert werden, es sei denn, jemand hat so einen Schwachfug schon einmal erfolgreich bekämpft und sagt mir, wie.
Ich werde nicht viel Zeit in "probier doch mal..." investieren, da er wie gesagt dringend wieder laufen muss. Bitte nur melden, wenn diese Symptome bekannt sein sollten.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670239
Url: https://administrator.de/forum/rds-host-macht-neuerdings-nach-18-sitzungen-dicht-670239.html
Ausgedruckt am: 19.01.2025 um 08:01 Uhr
13 Kommentare
Neuester Kommentar
Moin,
der Host gehört ja normalerweise zu einer Sammlung und in den Sammlungs-Eigenschaften unter Lastenausgleich gibt es einen Maximalwert für Sitzungslimits, der vielleicht gesetzt ist.
Henning
der Host gehört ja normalerweise zu einer Sammlung und in den Sammlungs-Eigenschaften unter Lastenausgleich gibt es einen Maximalwert für Sitzungslimits, der vielleicht gesetzt ist.
Henning
Nein, einzelner Host und ist selbst auch Lizenzserver. Keine Limits.
Auch kein Broker mit installiert?
Doch, ist installiert, aber nichts konfiguriert.
Moin,
keine Lösung, vieleicht ein Hinweis.
Hattet Ihr denn früher schon mal mehr als 18 Benutzer drauf?
Ich kenne in der Planung immer das Limit von 15 Benutzern.
Dafür habe ich keine Quelle, aber das haben immer alle gesagt mit denen ich zu tun hatte.
Vieleicht gibt es ein default-Limit bei 18.
Das Verhalten klingt gefühlt eher nach einem Resourcen-Problem.
Stefan
keine Lösung, vieleicht ein Hinweis.
Hattet Ihr denn früher schon mal mehr als 18 Benutzer drauf?
Ich kenne in der Planung immer das Limit von 15 Benutzern.
Dafür habe ich keine Quelle, aber das haben immer alle gesagt mit denen ich zu tun hatte.
Vieleicht gibt es ein default-Limit bei 18.
Das Verhalten klingt gefühlt eher nach einem Resourcen-Problem.
Stefan
Hattet Ihr denn früher schon mal mehr als 18 Benutzer drauf?
Ja, sicher, die 50 wurden fast getroffen.Ich habe mittlerweile festgestellt, dass alle im Lizenzmanager angezeigten Lizenzen (seit dem Reset gestern) für Nutzer ausgestellt wurden, die sehr lange nicht drauf waren (Krankheit), bzw. neue Nutzer sind (neu eingestellt zur Monatsmitte). Hm. Daraufhin habe ich eine Zombiearmee von 20 neuen Dummynutzern erstellt und diese per Skript mal per RDP losgeschickt und siehe da, nun können 16 weitere rein, so dass wir bei 34 sind! Die letzten 4 wollten dann aber wieder mit dem selben Fehler abgewiesen werden.
Was soll das bedeuten? Wo speichert Microschr. denn noch diese Infos über vergangene Sessions, wo muss ich noch altes Aufräumen?
Moin,
Dieses Problem hatte ich noch nicht, aber seit ein paar Tagen, kommt bei einem Kunden immer wieder, daß da keine RDP-Lizenzen mehr da wären und die User werden nach 60 Minuten wieder rausgeworfen. Mit dem Lizenz-Manager nachgeschaut und es sind genug Lizenzen übrig und auch aktiv.
Weiß der Geier, was MS da wieder verbockt hat.
lks
Dieses Problem hatte ich noch nicht, aber seit ein paar Tagen, kommt bei einem Kunden immer wieder, daß da keine RDP-Lizenzen mehr da wären und die User werden nach 60 Minuten wieder rausgeworfen. Mit dem Lizenz-Manager nachgeschaut und es sind genug Lizenzen übrig und auch aktiv.
Weiß der Geier, was MS da wieder verbockt hat.
lks
Mir ist dieser undurchsichtige Krempel echt zuwider.
In den AD-Nutzerobjekten steht bei allen die selber TS-Lizenzserver-ID drin... wieso also solltre der Lizenzserver selbst nur 5 (!) Stück der zuletzt 34 anwesenden Nutzern auch zählen? Was soll's, lass ihn doch auch mal, aber warum macht er bei Nutzer 35 dicht? Ressourcen sind noch massiv vorhanden.
Diese Dateikorruption scheint ihn völlig verwirrt zu haben. Einen Tag gebe ich ihm noch, dann wird er exekutiert. Was Wochenendarbeit bedeutet
In den AD-Nutzerobjekten steht bei allen die selber TS-Lizenzserver-ID drin... wieso also solltre der Lizenzserver selbst nur 5 (!) Stück der zuletzt 34 anwesenden Nutzern auch zählen? Was soll's, lass ihn doch auch mal, aber warum macht er bei Nutzer 35 dicht? Ressourcen sind noch massiv vorhanden.
Diese Dateikorruption scheint ihn völlig verwirrt zu haben. Einen Tag gebe ich ihm noch, dann wird er exekutiert. Was Wochenendarbeit bedeutet
Ich glaube, nun verstehe ich, was los ist.
Wenn man den Lizenzserver resettet, muss man auch die ausgegebenen Lizenzen (die von der vorigen Instanz ausgegeben wurden) devalidieren, indem man das AD-Attribut "MSTSExpireDate" der User auf einen Wert vor heute ändert. Dann bekommen sie zumindest mal sofort neue Lizenzen ausgestellt. Ich werde es nun also live beobachten können, ob wir noch einmal an das Limit stoßen.
Wenn man den Lizenzserver resettet, muss man auch die ausgegebenen Lizenzen (die von der vorigen Instanz ausgegeben wurden) devalidieren, indem man das AD-Attribut "MSTSExpireDate" der User auf einen Wert vor heute ändert. Dann bekommen sie zumindest mal sofort neue Lizenzen ausgestellt. Ich werde es nun also live beobachten können, ob wir noch einmal an das Limit stoßen.
"Ahhhh!" - So klingt Erleichterung.
Die Lösung: nachdem die Lizenzen nun munter wieder zugeteilt wurden, verschwand das Problem nicht.
Nach viel Gegrübel, Gegoogle und Log-Gewälze wurde klar, dass eine Veränderung am Server, die schon etwas zurückliegt, nun zum Problem wurde:
Ich hatte eine starke Grafikkarte eingebaut, um die CPU bei Videos zu entlasten und hatte per GPO auch angewiesen, diese in RDP-Sitzungen zu nutzen - was auch nachweislich geschah. Hätte ich lieber bleiben lassen sollen. Googelt man, findet man viele Leidensgenossen, die berichten, dass irgendwo oberhalb von 10 Sitzungen die Probleme anfangen und Sitzungen schlicht nicht erstellt werden. im Anwendungseventlog findet sich "faulting application name: dwm.exe" - der Fenstermanager crasht gleich zu Beginn der Sitzung. Bei uns trat das meist bei 18 Sitzungen auf.
Nun wird wieder alles in Software gemacht und die Probleme sind wie weggepustet: 40 Leute problemlos drauf.
Nvidia gibt für non-partitionierbare-Karten meines Wissens auf RDS-Hosts keine Garantie oder Support, dass das läuft, somit kann ích nur davor warnen, das zu versuchen.
Zu dumm, dass damals nach Einbau der Karte keine große Zahl an Usern drauf war, sonst wäre das Problem damals schon aufgefallen und weitaus schneller auf die Karte zurückgeführt worden.
Die Lösung: nachdem die Lizenzen nun munter wieder zugeteilt wurden, verschwand das Problem nicht.
Nach viel Gegrübel, Gegoogle und Log-Gewälze wurde klar, dass eine Veränderung am Server, die schon etwas zurückliegt, nun zum Problem wurde:
Ich hatte eine starke Grafikkarte eingebaut, um die CPU bei Videos zu entlasten und hatte per GPO auch angewiesen, diese in RDP-Sitzungen zu nutzen - was auch nachweislich geschah. Hätte ich lieber bleiben lassen sollen. Googelt man, findet man viele Leidensgenossen, die berichten, dass irgendwo oberhalb von 10 Sitzungen die Probleme anfangen und Sitzungen schlicht nicht erstellt werden. im Anwendungseventlog findet sich "faulting application name: dwm.exe" - der Fenstermanager crasht gleich zu Beginn der Sitzung. Bei uns trat das meist bei 18 Sitzungen auf.
Nun wird wieder alles in Software gemacht und die Probleme sind wie weggepustet: 40 Leute problemlos drauf.
Nvidia gibt für non-partitionierbare-Karten meines Wissens auf RDS-Hosts keine Garantie oder Support, dass das läuft, somit kann ích nur davor warnen, das zu versuchen.
Zu dumm, dass damals nach Einbau der Karte keine große Zahl an Usern drauf war, sonst wäre das Problem damals schon aufgefallen und weitaus schneller auf die Karte zurückgeführt worden.
1
Nebenbei: Welche Methode hast du für die Grafikkarte angewendet und welche Grafikkarte ist es?
Mit dem Thema habe ich mich auch mal beschäftigt und das war mir dann mit den vGPU's und Lizenzen zu teuer.
Mit dem Thema habe ich mich auch mal beschäftigt und das war mir dann mit den vGPU's und Lizenzen zu teuer.
Kein vgpu. Wie beschrieben ist das ein sessionbasiertes Deployment und kein VDI.
Kannst du mir da ein paar Details zukommen lassen? Gerne PN.
