RDS-Farm 2025

[Ebenezer 17]

Hi, hat hier schon Jemand eine 2025er RDS-Farm in Betrieb und ist zufrieden? Ich bin gerade dabei eine aufzubauen und frage mich ob ich besser auf 2022 wechseln sollte. Zum Setup:

 

VM1 ->  RDS-Connection-Broker, RDS-Web-Access, and RDS-Licensing

VM2-4 -> RDS-RD-SERVER

 

Meine Probleme:

 

1. Benutzer können sich direkt (via IP oder DNS) auf den Session-Hosts anmelden... das sollten doch eigentlich nur Admins können, oder nicht? Ich habe hier noch eine andere 2022er RDS-Farm und da erhalten die Nutzer beim direkten Anmeldeversuch die Meldung "Der angeforderte Zugriff auf eine Sitzung wurde verweigert". Sie müssen sich also über den Broker verbinden lassen und so soll das auch hier sein!

2. Eine Benutzer-GPO (Laufwerk-Mapping) die mit der Benutzer-OU verknüpft ist, wird nicht angewendet! GPRESULT /H zeigt sie nicht an! Sie wird auch nicht gefiltert! Andere User-Policys die nicht mit der OU sondern der Domain verknüpft sind funktionieren! Im Eventlog steht auch nichts.

 

Ich bin für alle Ideen dankbar!

 

 

[cj_berlin 1.585]

Moin,

 

Re Benutzer-GPO: entweder hat jemand Loopback/Replace für den neuen Host konfiguriert, oder der RDS Session Host darf sie nicht lesen.

Re Broker-Zugriff: Bist Du sicher, dass die "Normalbenutzer" auf dem neuen RDS-SH nicht zufällig in die Admins oder Remote Desktop Users gerutscht sind?

[teletubbieland 231]

N'Abend,

 

vor 5 Stunden schrieb Ebenezer:

hat hier schon Jemand eine 2025er RDS-Farm in Betrieb und ist zufrieden? Ich bin gerade dabei eine aufzubauen und frage mich ob ich besser auf 2022 wechseln sollte.

Ja, hab ich. 

Und was versprichst Du Dir davon auf 2022 zu gehen?
Das Konzept ist seit 2012 das Gleiche.

Wenn die Richtlinien sauber definiert sind, funktioniert es unabhängig von der Serverversion.

Ansonsten: siehe Evgenij :-)

[testperson 2.012]

Moin,

 

vor 13 Stunden schrieb cj_berlin:

Re Broker-Zugriff: Bist Du sicher, dass die "Normalbenutzer" auf dem neuen RDS-SH nicht zufällig in die Admins oder Remote Desktop Users gerutscht sind?

sobald ich eine Gruppe in der Collection berechtige, wird die doch (AFAIK) auf den Workern in die Remote Desktop Users eingetragen. Ebenfalls wird man doch auch als Mitglied der lokalen Administratoren gebrokert, solange man sich nicht per "mstsc.exe /admin" verbindet. Oder reden wir hier aneinander vorbei?

 

@Ebenezerhast du mal in einer User Session, die sich per IP / Hostname mit dem Session Host verbunden hat, in der Kommandozeile bspw. ein "hostname" ausgeführt bzw. generell geprüft, auf welchem Host du gelandet bist? Hier evtl. mit mehreren Usern testen, nicht das du per Zufalls auf den Host gebrokert wirst, auf den du dich connectest.

 

Gruß

Jan

[Ebenezer 17]

Hallo Zusammen,

 

@testperson Genau, die Gruppe die man in der Sammlung unterhalb von "Benutzergruppen" einträgt, landet auf den Session Hosts in der lokalen Gruppe der Remote Desktop Benutzern! Das muss auch so sein! Es muss also noch einen anderen Mechanismus geben der dafür sorgt, dass sich ein Nutzer, der sich zwar in der lokalen RDP-Gruppe befindet, trotzdem nicht direkt auf einem Session Host anmelden kann, es sei denn er wird über den Broker verteilt!

 

@testperson Ich lande immer auf dem Session Host den ich auch via IP angegeben habe, und zwar mit unterschiedlichen Nutzern!

 

[Ebenezer 17]

Hi, also das RDP-Problem war gar keins! Wenn man sich via IP /DNS direkt mit einem Session-Host verbindet wird man manchmal auch automatisch "gebrokert"!  Das habe ich aber erst festgestellt, nachdem ich den RDSH, zu dem ich mich verbinden wollte, gesperrt habe! Wenn man sich mit einem gesperrten RDSH via DNS verbinden möchte und daraufhin umgeleitet wird, dann schlägt das fehl:

 

Es kann nicht überprüft werden, ob die beiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarm gehören.

 

Via IP klappt das!

 

Was ich immer noch nicht lösen konnte ist das GPO-Problem! Ich habe folgende OU-Struktur:

 

firma.local/company/Benutzer/Mitarbeiter

 

User-GPOs die ich hier direkt verknüpfe werden auf den 2025er Servern nicht gefunden! Auch eine Ebene drüber klappt es nicht:

 

firma.local/company/Benutzer

 

Hier aber schon:

 

 firma.local/company

 

Habt Ihr dazu eine Idee?

 

Auf 2016er RDSH in der gleichen Domäne klappt es problemlos!

 

 

 

 

[testperson 2.012]

Moin,

 

es steht zwar etwas weiter oben schon:

 

Option 1: Auf die 2025er Hosts wirkt ein GPO mit Loopbackverarbeitungsmodus mit Ersetzen (GPS: Configure user Group Policy loopback processing mode).

Option 2: Die GPOs haben in der Sicherheitsfilterung nicht die Authentifizierten User mit min. Lesen bzw. dort eine Gruppe, die die Computerkonten der neuen 2025er Hosts nichts beinhalten.

 

Gruß

Jan

[Sunny61 854]

Sind die 2025er RDS-Server in der gleichen OU wie die 2016er? Es gibt im AD eine Gruppe TERMSERVER oder so ähnlich, sind die 2025er RDS dort auch drin? Sind die Mitgliedschaften der 2025er RDS-Server gleich zu den 2016er?

[Ebenezer 17]

Am 28.6.2026 um 19:17 schrieb testperson:

Moin,

 

es steht zwar etwas weiter oben schon:

 

Option 1: Auf die 2025er Hosts wirkt ein GPO mit Loopbackverarbeitungsmodus mit Ersetzen (GPS: Configure user Group Policy loopback processing mode).

Option 2: Die GPOs haben in der Sicherheitsfilterung nicht die Authentifizierten User mit min. Lesen bzw. dort eine Gruppe, die die Computerkonten der neuen 2025er Hosts nichts beinhalten.

 

Gruß

Jan

 

Hallo Jan, danke es lag tatsächlich an Option 1! Ich bin davon ausgegangen, dass "Ersetzen" nur bei konkurrierenden Einstellungen ersetzt...

[daabm 1.479]

@Ebenezer Alt, aber immer noch richtig  https://evilgpo.blogspot.com/2012/02/loopback-demystified.html