RDS 2019 - User GPO greift nicht

[exchangekoala 1]

Hallo zusammen, 

Ich versuche auf 2x RDS Session Hosts, diverse Einstellungen per GPO umzusetzen. Leider greifen die verlinkten Richtlinien nicht? 

Erstelle ich ein gpresult wird für den angemeldeten Benutzer einfach keine GPO angezeigt. Nicht mal eine fehlerhafte. 

Der Benutzer an sich ist in einer komplett anderen OU als logischerweise die RDS-FARM, allerdings sollte er durch die Loopback GPO die dort verlinkten User GPOs doch übernehmen oder?

 

Wo ist mein Denkfehler?

 

Gruß

exchangekoala

 

 

 

[NorbertFe 2.032]

Ich vermute, du hast die GPOs per Sicherheitsfilterung konfiguriert. Haben die Terminalserver (der Einfachheit halber Domänencomputer) Leserechte auf das GPO?

[exchangekoala 1]

Hey NorbertFe, 

Danke für deine Rückmeldung. Ja Leserechte sind vorhanden. 

Ich habe nun festgestellt ,das der für meinen Testuser zuständige Session Host die Loopback GPO an sich nicht übernommen hat.

Trotz mehrmaliger Neustarts. (Durch den Connection Broker ist der Testuser natürlich immer auf dem gleichen SH gelandet und hat anschließend keine User GPOs zu Gesicht bekommen). 

 

Erstelle ich als Admin direkt nach einem Neustart einen Report der GPO's auf dem SH, meldet dieser mir das er Netzwerk / Domäne nicht finden kann. 

Nach einem manuell ausgelösten gpupdate hat er keine Beschwerden mehr. 

Der zweite SH verhält sich nach einem Neustart regelkonform und meldet keine Fehler mit der Domäne. 

Hast du hierzu vielleicht noch eine Idee? 

 

Achso, die User GPO's greifen natürlich jetzt. Allerdings bereitet mir das Verarbeiten der GPO's nach einem Neustart Sorgen.

 

 

bearbeitet 13. November 2019 von exchangekoala

[daabm 1.352]

Als Einstieg in die Diagnose:

# for hex 0x54b / decimal 1355 :
  ERROR_NO_SUCH_DOMAIN                                          winerror.h     
# The specified domain either does not exist or could not be
# contacted.
# 1 matches found for "54b"

Der RDS findet keine Domäne...

[exchangekoala 1]

Die Fehlermeldung habe ich so schon gesucht. Allerdings macht sie wie beschrieben keinen Sinn, da dieser Fehler nur nach einem Neustart auftritt. Führe ich danach manuell ein gpupdate aus, verschwindet dieser aus dem Report und die GPO wird aktualisiert.

 

DCs sind vorhanden und auflösbar, der zweite SH macht diese Faxen ja auch nicht, beide sind erst 7 Tage alt und "baugleich".

bearbeitet 13. November 2019 von exchangekoala

[testperson 1.675]

Hi,

 

wenn du mehrere RDSHs hast und einer macht Faxen, dann schmeiß den weg und mach neu. Alternativ, wenn da schon viel Einrichtung drin steckt, dann schmeiß den "kaputten" weg und klone einen anderen.

 

Wenn der Fehler bleibt, kannst du Troubleshooten. ;) Das der erste RDSH einfach zu schnell bootet? Passiert das auch, wenn du dem Server nach dem Boot erstmal ein wenig Pause gönnst?

 

Gruß

Jan

[daabm 1.352]

Nur nach Neustart? Hast Du ein Problem mit Spanning Tree Detection? Wie lange dauert es, bis Deine Switche Ports mit dem LAN verbinden? Ansonsten siehe Jans Vorschlag: Schmeiß weg, mach neu

[exchangekoala 1]

vor 13 Stunden schrieb daabm:

Nur nach Neustart? Hast Du ein Problem mit Spanning Tree Detection? Wie lange dauert es, bis Deine Switche Ports mit dem LAN verbinden? Ansonsten siehe Jans Vorschlag: Schmeiß weg, mach neu

Wäre noch eine Idee, allerdings sitzen die VMs auf dem gleichen vSwitch im ESXi. Da kann noch nichts greifen.. ? 

Ist auch noch kein Cluster Aufbau, das da etwas dynamisch durch die Welt wandert.

Ich schaue morgen nochmal kurz nach und ansonsten fliegt der dann tatsächlich nochmal raus. ??‍♂️

 

Nachtrag: Jetzt hat er nach dem Neustarten keinerlei DNS Probleme mehr... whatever... Es ist immer das DNS.

Danke euch trotzdem!

bearbeitet 15. November 2019 von exchangekoala