4
Remote Desktop Gateway Server2016 - RD-RAP Verwaltung sehr langsam (Powershell, WMI)
Hallo Leute,
wir haben hier eine hochverfügbare RDS Farm mit Server 2016.
Im Remotedesktop Gateway werden ja die Ressourcenautorisierungsrichtlinien (RD-RAP) konfiguriert.
Nun haben wir dort bereits ca 1000 Einträge drin (Die Leute schalten sich im Homeoffice auf Ihren PC auf, daher haben wir auf dem Gateway eine 1:1 Beziehung und so viele Einträge).
Ich finde, das sind nicht wirklich viele Einträge für so ein System.
Nun habe ich mir kleine Powershell Skripts geschrieben, welche eine neue RD-RAP anlegen bzw. löschen um das ganze nicht immer elendig von Hand klicken zu müssen.
Funktioniert auch alles. Allerdings ist das ganze Handling mittlerweile grottenlahm! (Am Anfang war es deutlich zackiger!)
Alleine das löschen einer RD-RAP dauert > 3 Minuten auf einem Server - und da wir 2 Gatewayserver haben, dauert alleine dieser kleine Vorgang > 6 Minuten!
Ist alles kein Beinbruch, aber es nervt gewaltig, vorallem bei mehreren Änderungen.
Beim ausführen des Kommandos rödelt der WMI Provider Host mit ca 18% auf der Kiste. Man sieht im Eventlog unter WMI-Activity auch dass da was gemacht wird.
(Event ID 5857)
Nur warum der "Mist" so dermaßen lang dauert, erschließt sich mir nicht.
Kann doch net sein, dass das Ding bei den wenigen Einträgen schon dicke Backen macht?
Jemand ne Idee/Lösung woran ich schrauben kann?
LG
KangarooJack
wir haben hier eine hochverfügbare RDS Farm mit Server 2016.
Im Remotedesktop Gateway werden ja die Ressourcenautorisierungsrichtlinien (RD-RAP) konfiguriert.
Nun haben wir dort bereits ca 1000 Einträge drin (Die Leute schalten sich im Homeoffice auf Ihren PC auf, daher haben wir auf dem Gateway eine 1:1 Beziehung und so viele Einträge).
Ich finde, das sind nicht wirklich viele Einträge für so ein System.
Nun habe ich mir kleine Powershell Skripts geschrieben, welche eine neue RD-RAP anlegen bzw. löschen um das ganze nicht immer elendig von Hand klicken zu müssen.
Funktioniert auch alles. Allerdings ist das ganze Handling mittlerweile grottenlahm! (Am Anfang war es deutlich zackiger!)
Alleine das löschen einer RD-RAP dauert > 3 Minuten auf einem Server - und da wir 2 Gatewayserver haben, dauert alleine dieser kleine Vorgang > 6 Minuten!
Ist alles kein Beinbruch, aber es nervt gewaltig, vorallem bei mehreren Änderungen.
Import-Module RemoteDesktopServices
Remove-Item -path "RDS:\GatewayServer\RAP\$Computername" -Confirm:$False -Recursive Beim ausführen des Kommandos rödelt der WMI Provider Host mit ca 18% auf der Kiste. Man sieht im Eventlog unter WMI-Activity auch dass da was gemacht wird.
(Event ID 5857)
Nur warum der "Mist" so dermaßen lang dauert, erschließt sich mir nicht.
Kann doch net sein, dass das Ding bei den wenigen Einträgen schon dicke Backen macht?
Jemand ne Idee/Lösung woran ich schrauben kann?
LG
KangarooJack
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: 587813
Url: https://administrator.de/contentid/587813
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
4 Kommentare
Neuester Kommentar
Kann doch net sein, dass das Ding bei den wenigen Einträgen schon dicke Backen macht?
Doch ist aber so. Das sind viel zu viele Einträge, dafür ist das Teil nicht wirklich ausgelegt da stetig dran zu arbeiten, und WMI-Abfragen und Methoden sind nun mal arg lahm. Vor allem bei Enumerations und das muss der jedes mal nach jedem Lösch- und Hinzufügevorgang.daher haben wir auf dem Gateway eine 1:1 Beziehung und so viele Einträge
Das ist ineffizient und überflüssig wenn man schon in den AD-Egenschaften festlegt an welchen Maschinen der User sich anmelden darf, oder alternativ per GPO die Gruppe RemoteDesktopUsers der Maschinen füllt.
Moin,
Das ist die falsche Methode. Sowas regelt man über Gruppen. Dann muss man auch nicht bei jeder Änderung gleich da ran.
Doch.
Dann lies Dich mal in objektorientierte Datenbanken und ihre Vor- und Nachteile ein.
WMI basiert auf einem objektorientierten Datenmodell namens Managed Object Format. Solche Datenbanken haben den großen Vorteil, dass man das Datenmodell fast schon beliebig und jederzeit ändern kann. Sie werden aber schnell furchtbar laaaaaaaaaaaaaaaaangsam. Deshalb nimmt man sie auch nur für kleine Aufgaben mit wenig Datensätzen.
Liebe Grüße
Erik
Zitat von @Kangaroojack:
Nun haben wir dort bereits ca 1000 Einträge drin (Die Leute schalten sich im Homeoffice auf Ihren PC auf, daher haben wir auf dem Gateway eine 1:1 Beziehung und so viele Einträge).
Nun haben wir dort bereits ca 1000 Einträge drin (Die Leute schalten sich im Homeoffice auf Ihren PC auf, daher haben wir auf dem Gateway eine 1:1 Beziehung und so viele Einträge).
Das ist die falsche Methode. Sowas regelt man über Gruppen. Dann muss man auch nicht bei jeder Änderung gleich da ran.
Ich finde, das sind nicht wirklich viele Einträge für so ein System.
Doch.
Nur warum der "Mist" so dermaßen lang dauert, erschließt sich mir nicht.
Dann lies Dich mal in objektorientierte Datenbanken und ihre Vor- und Nachteile ein.
WMI basiert auf einem objektorientierten Datenmodell namens Managed Object Format. Solche Datenbanken haben den großen Vorteil, dass man das Datenmodell fast schon beliebig und jederzeit ändern kann. Sie werden aber schnell furchtbar laaaaaaaaaaaaaaaaangsam. Deshalb nimmt man sie auch nur für kleine Aufgaben mit wenig Datensätzen.Liebe Grüße
Erik
Hallo fullcrum, Erikro,
danke für euere Antworten zu dem Thema.
a) Die Server+Verwaltungskonsole lacht sich vollkommen schlapp über die 1000 Einträge und man kann in wenigen Sekunden einen Eintrag hinzufügen oder löschen. Ist aber halt manuelles geklicker und fehleranfällig. Wäre für so ne Lösung auch ein Witz, wenn da schon EndeGelände wäre. Nur über die Powershell ist es so grottenlahm bei der Konfiguration.
b) in der Konsole wird eh NUR mit Gruppen gearbeitet um die Zugriffe zu steuern. Das hat 0 mit dem befüllen der lokalen RemoteDesktopBenutzer Gruppe auf den Clients zu tun oder gar mit der Steuerung wer sich wo anmelden darf in den Einstellungen des Benutzerkontos.
Ich hab es zwischenzeitlich zum Glück gelöst.
Der Zauber ist halt in der Powershell CIM zu benutzen statt WMI.
Vorher hat der Konfigurationsvorgang insgesamt ca 8 Minuten für einen Eintrag auf den beiden Server gedauert - jetzt sind es noch 30-40 Sekunden je nachdem wie schnell man die beiden nötigen Variablen von Hand eintippt.
danke für euere Antworten zu dem Thema.
a) Die Server+Verwaltungskonsole lacht sich vollkommen schlapp über die 1000 Einträge und man kann in wenigen Sekunden einen Eintrag hinzufügen oder löschen. Ist aber halt manuelles geklicker und fehleranfällig. Wäre für so ne Lösung auch ein Witz, wenn da schon EndeGelände wäre. Nur über die Powershell ist es so grottenlahm bei der Konfiguration.
b) in der Konsole wird eh NUR mit Gruppen gearbeitet um die Zugriffe zu steuern. Das hat 0 mit dem befüllen der lokalen RemoteDesktopBenutzer Gruppe auf den Clients zu tun oder gar mit der Steuerung wer sich wo anmelden darf in den Einstellungen des Benutzerkontos.
Ich hab es zwischenzeitlich zum Glück gelöst.
Der Zauber ist halt in der Powershell CIM zu benutzen statt WMI.
Vorher hat der Konfigurationsvorgang insgesamt ca 8 Minuten für einen Eintrag auf den beiden Server gedauert - jetzt sind es noch 30-40 Sekunden je nachdem wie schnell man die beiden nötigen Variablen von Hand eintippt.
$RdsGwRap = Get-CimInstance -Namespace "root/CIMV2/TerminalServices" -ClassName "Win32_TSGatewayResourceAuthorizationPolicy" -ComputerName $Server
$RdsGwRap = Invoke-CimMethod -Namespace "root/CIMV2/TerminalServices" -ClassName "Win32_TSGatewayResourceAuthorizationPolicy" -ComputerName $Server -MethodName Create -Arguments @{Name = "$ComputerName"; Description = ""; Enabled = $true; ResourceGroupType = "CG"; ResourceGroupName = "DOMAIN\"+"$ComputerGroup"; UserGroupNames = "DOMAIN\"+"$UserGroup"; ProtocolNames = "RDP"; PortNumbers = "3389"}
Moin,
Naja, das ist ja auch eine andere Schnittstelle, über die da zugegriffen wird.
Doch. Da stehen bei uns nur Gruppen drin und keine User. Wenn ein User Zugriff auf einen TS haben soll, dann kommt er in die entsprechende Gruppe.
Stimmt. Das macht man mit GPOs. https://www.tech-faq.net/anmeldung-am-computer-verweigern/
Das sowieso. WMI ist deprecated und wird nicht mehr weiterentwickelt. https://docs.microsoft.com/de-de/powershell/scripting/whats-new/breaking ...
Tja, mit Gruppen und GPOs ist das ein Abfallprodukt beim Einrichten des Users. Wenn er neu anfängt oder die Abteilung wechselt, muss er sowieso in die richtige Gruppe und die richtige OU. Damit hat er dann alle notwendigen Rechte und gut ist. Das einzige, dass man leider nicht mit der Methode hinkriegt, sind die Anmeldezeiten. Aber die kann man per Skript beim Anlegen des Users eintragen.
Aber jeder, wie er es mag. Und ich weiß jetzt, dass es die Klasse Win32_TSGatewayResourceAuthorizationPolicy gibt. Wer weiß. Vielleicht kann ich das mal brauchen.
Liebe Grüße
Erik
Zitat von @Kangaroojack:
a) Die Server+Verwaltungskonsole lacht sich vollkommen schlapp über die 1000 Einträge und man kann in wenigen Sekunden einen Eintrag hinzufügen oder löschen.
a) Die Server+Verwaltungskonsole lacht sich vollkommen schlapp über die 1000 Einträge und man kann in wenigen Sekunden einen Eintrag hinzufügen oder löschen.
Naja, das ist ja auch eine andere Schnittstelle, über die da zugegriffen wird.
b) in der Konsole wird eh NUR mit Gruppen gearbeitet um die Zugriffe zu steuern. Das hat 0 mit dem befüllen der lokalen RemoteDesktopBenutzer Gruppe auf den Clients zu tun
Doch. Da stehen bei uns nur Gruppen drin und keine User. Wenn ein User Zugriff auf einen TS haben soll, dann kommt er in die entsprechende Gruppe.
oder gar mit der Steuerung wer sich wo anmelden darf in den Einstellungen des Benutzerkontos.
Stimmt. Das macht man mit GPOs. https://www.tech-faq.net/anmeldung-am-computer-verweigern/
Ich hab es zwischenzeitlich zum Glück gelöst.
Der Zauber ist halt in der Powershell CIM zu benutzen statt WMI.
Der Zauber ist halt in der Powershell CIM zu benutzen statt WMI.
Das sowieso. WMI ist deprecated und wird nicht mehr weiterentwickelt. https://docs.microsoft.com/de-de/powershell/scripting/whats-new/breaking ...
Vorher hat der Konfigurationsvorgang insgesamt ca 8 Minuten für einen Eintrag auf den beiden Server gedauert - jetzt sind es noch 30-40 Sekunden je nachdem wie schnell man die beiden nötigen Variablen von Hand eintippt.
Tja, mit Gruppen und GPOs ist das ein Abfallprodukt beim Einrichten des Users. Wenn er neu anfängt oder die Abteilung wechselt, muss er sowieso in die richtige Gruppe und die richtige OU. Damit hat er dann alle notwendigen Rechte und gut ist. Das einzige, dass man leider nicht mit der Methode hinkriegt, sind die Anmeldezeiten. Aber die kann man per Skript beim Anlegen des Users eintragen.
Aber jeder, wie er es mag.
Und ich weiß jetzt, dass es die Klasse Win32_TSGatewayResourceAuthorizationPolicy gibt. Wer weiß. Vielleicht kann ich das mal brauchen. Liebe Grüße
Erik
