11
Ein paar Fragen zum RD-Deployment unter 2012 R2
Hallo in die Runde,
hab da mal ein paar Fragen zum RD-Deployment, da ich ein paar komische Dinge feststelle, eventuell weiss jemand woher das kommt, oder hat es schon selbst festgestellt.
Zur Umgebung:
4x RDS-Host unter 2012 R2 (Als Farm geschaltet)
1x SessionBroker 2012 R2
1x Domaincontroller (2012 R1)
1x Fileserver (2012 R2) (Profile in Form der UPD)
Zu den Fragen:
1) Mir fiel in letzter Zeit auf, das der 1. RDS-Host (der hat zwei IP-Adressen, seine eigene und eine für den Farmbetrieb) abends enorm viele .bak-Eintragungen bei ProfileList ausweist.
Die löschen wir dann einfach. Am nächsten Tag sind die aber wieder da. Um das Deployment mit den UPD's zu stabilisieren und diese ominösen temporären Profile einzuschränken, haben wir der Sammlung das Recht entzogen temporäre Ordner zu erstellen. Danach das ganze wieder beobachtet.
Nun wird es aber spannend. Temporäre Profile mittels UPD haben wir so gut wie keine mehr. Die Server haben morgens beim einloggen auch erstmal keine .bak-Eintragungen. Aber plötzlich im laufenden Betrieb, bei Usern die angemeldet sind, bspw. auf RDS-Host #3, entsteht auf dem Host #1 ein .bak-Eintrag. Prüfe ich nun am SessionBroker, wird die Sitzung weiterhin am Host #3 angezeigt, jedoch mit einer Trennungsuhrzeit, obwohl der Status weiterhin aktiv ist. Mein Verdacht ist nun, das durch kurze Remote-"Abrisse" der User selbst gar nichts merkt, aber die Remotesitzung nochmal am SessionBroker Anfragen führt, die dann zu einem Eintrag am Host #1 führen (war ja der Anmeldeserver morgens).
Hierzu mal ein paar Screenshots:
So zeigt es der SessionBroker an - auffällig, ca. 4-5 Minuten nach der Anmeldezeit, wird ein Trennungsereignis angezeigt und daraus eine Leerlaufzeit ermittelt, Status aber weiterhin "Aktiv"
Der Registry-Eintrag am Host #1 führt für diesen User einen .bak-Eintrag - der User arbeitet aber nicht auf diesem Host, sondern
er arbeitet hier auf diesem Host, da stimmen die Eintragungen auch:
2) Auch interessant, ich kann mich auf allen drei Host's mittels Schatten auf die User spiegeln. Bei Host #1 erhalte ich aber umgehend einen Spiegelungsfehler mit dem Hinweis, die Sitzung wäre gar nicht vorhanden.
Hab die letzten zwei Tage mal alle Ereignislogs auf den betreffenden Servern (Host#1 und Sessionbroker) geprüft, steht aber nichts dazu drin. Soher auch keine Ahnung, wieso der Fehler überhaupt ausgelöst wird.
Netzwerkeinstellungen von Host #1 sind identisch mit den anderen drei Servern (Host #2 ist sogar ein Klone von 1)
3) Obwohl in der RD-Sammlung vermerkt ist, das kein temporäres Profil angelegt werden darf, hat er dies in einem Fall bei einem User dennoch gemacht. (Komischerweise, bei rund 80 Anmeldungen, nur einer der davon betroffen war)
4) Muss ich eigentlich bei der Konstellation den Host #1 als Anmeldeserver nutzen oder kann nicht der SessionBroker das direkt übernehmen und weiterleiten? Wenn ich auf die IP-Adresse vom SessionBroker gehe, legt er mir dort direkt eine Remotesitzung an und verweist mich nicht auf die Farm.
5) Gelegentlich verlieren die User auf den Host's den Standarddrucker (grüner Haken ist weg, Drucker selbst noch da). Ändere ich den Standarddrucker und gehe wieder auf den alten zurück, taucht kein Haken mehr auf. Ich muss den Drucker dann meist entfernen und über \\prtsvr\DruckerName einfügen. Danach ist er wieder da und lässt sich als Standarddrucker auswählen. Dieses Problem scheint daher nicht von der Druckerwarteschlange zu kommen, diese werden dabei nicht neugestartet. Der Drucker läuft dann aber ganz normal.
So, das wäre es auch schon, wenn jemand eine Idee oder Tipps hat, wäre ich sehr verbunden.
Grüße
Forseti
hab da mal ein paar Fragen zum RD-Deployment, da ich ein paar komische Dinge feststelle, eventuell weiss jemand woher das kommt, oder hat es schon selbst festgestellt.
Zur Umgebung:
4x RDS-Host unter 2012 R2 (Als Farm geschaltet)
1x SessionBroker 2012 R2
1x Domaincontroller (2012 R1)
1x Fileserver (2012 R2) (Profile in Form der UPD)
Zu den Fragen:
1) Mir fiel in letzter Zeit auf, das der 1. RDS-Host (der hat zwei IP-Adressen, seine eigene und eine für den Farmbetrieb) abends enorm viele .bak-Eintragungen bei ProfileList ausweist.
Die löschen wir dann einfach. Am nächsten Tag sind die aber wieder da. Um das Deployment mit den UPD's zu stabilisieren und diese ominösen temporären Profile einzuschränken, haben wir der Sammlung das Recht entzogen temporäre Ordner zu erstellen. Danach das ganze wieder beobachtet.
Nun wird es aber spannend. Temporäre Profile mittels UPD haben wir so gut wie keine mehr. Die Server haben morgens beim einloggen auch erstmal keine .bak-Eintragungen. Aber plötzlich im laufenden Betrieb, bei Usern die angemeldet sind, bspw. auf RDS-Host #3, entsteht auf dem Host #1 ein .bak-Eintrag. Prüfe ich nun am SessionBroker, wird die Sitzung weiterhin am Host #3 angezeigt, jedoch mit einer Trennungsuhrzeit, obwohl der Status weiterhin aktiv ist. Mein Verdacht ist nun, das durch kurze Remote-"Abrisse" der User selbst gar nichts merkt, aber die Remotesitzung nochmal am SessionBroker Anfragen führt, die dann zu einem Eintrag am Host #1 führen (war ja der Anmeldeserver morgens).
Hierzu mal ein paar Screenshots:
So zeigt es der SessionBroker an - auffällig, ca. 4-5 Minuten nach der Anmeldezeit, wird ein Trennungsereignis angezeigt und daraus eine Leerlaufzeit ermittelt, Status aber weiterhin "Aktiv"
Der Registry-Eintrag am Host #1 führt für diesen User einen .bak-Eintrag - der User arbeitet aber nicht auf diesem Host, sondern
er arbeitet hier auf diesem Host, da stimmen die Eintragungen auch:
2) Auch interessant, ich kann mich auf allen drei Host's mittels Schatten auf die User spiegeln. Bei Host #1 erhalte ich aber umgehend einen Spiegelungsfehler mit dem Hinweis, die Sitzung wäre gar nicht vorhanden.
Hab die letzten zwei Tage mal alle Ereignislogs auf den betreffenden Servern (Host#1 und Sessionbroker) geprüft, steht aber nichts dazu drin. Soher auch keine Ahnung, wieso der Fehler überhaupt ausgelöst wird.
Netzwerkeinstellungen von Host #1 sind identisch mit den anderen drei Servern (Host #2 ist sogar ein Klone von 1)
3) Obwohl in der RD-Sammlung vermerkt ist, das kein temporäres Profil angelegt werden darf, hat er dies in einem Fall bei einem User dennoch gemacht. (Komischerweise, bei rund 80 Anmeldungen, nur einer der davon betroffen war)
4) Muss ich eigentlich bei der Konstellation den Host #1 als Anmeldeserver nutzen oder kann nicht der SessionBroker das direkt übernehmen und weiterleiten? Wenn ich auf die IP-Adresse vom SessionBroker gehe, legt er mir dort direkt eine Remotesitzung an und verweist mich nicht auf die Farm.
5) Gelegentlich verlieren die User auf den Host's den Standarddrucker (grüner Haken ist weg, Drucker selbst noch da). Ändere ich den Standarddrucker und gehe wieder auf den alten zurück, taucht kein Haken mehr auf. Ich muss den Drucker dann meist entfernen und über \\prtsvr\DruckerName einfügen. Danach ist er wieder da und lässt sich als Standarddrucker auswählen. Dieses Problem scheint daher nicht von der Druckerwarteschlange zu kommen, diese werden dabei nicht neugestartet. Der Drucker läuft dann aber ganz normal.
So, das wäre es auch schon, wenn jemand eine Idee oder Tipps hat, wäre ich sehr verbunden.
Grüße
Forseti
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 272441
Url: https://administrator.de/contentid/272441
Printed on: April 19, 2024 at 20:04 o'clock
11 Comments
Latest comment
zu 1)
Wenn die Sitzung des Users auf Host #3 getrennt wird und eine temporäre Sitzung auf Host #1 entsteht müsste dem User das doch auffallen da seine Programme ja in der neuen Sitzung nicht mehr laufen oder sehe ich das falsch? Oder meinst du er trennt seine Sitzung bewusst und RD-SH #1 erzeugt "einfach so" mal eine Temp-Sitzung?
zu 3)
Du kannst dich mit einer passenden rdp File auf die Sammlung am RD-CB verbinden. Wenn du noch keine Remote Apps bereit gestellt hast und dich per Webseite anmeldest läßt sich diese dort runter laden. Sieht in etwa so aus:
[...]
gatewayusagemethod:i:0
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:RDCB.DOMAIN
workspace id:s:RDCB.DOMAIN
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.SITZUNGSAMMLUNG
use multimon:i:1
alternate full address:s:RDCB.DOMAIN
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
signature:s:[...]
Wenn die Sitzung des Users auf Host #3 getrennt wird und eine temporäre Sitzung auf Host #1 entsteht müsste dem User das doch auffallen da seine Programme ja in der neuen Sitzung nicht mehr laufen oder sehe ich das falsch? Oder meinst du er trennt seine Sitzung bewusst und RD-SH #1 erzeugt "einfach so" mal eine Temp-Sitzung?
zu 3)
Du kannst dich mit einer passenden rdp File auf die Sammlung am RD-CB verbinden. Wenn du noch keine Remote Apps bereit gestellt hast und dich per Webseite anmeldest läßt sich diese dort runter laden. Sieht in etwa so aus:
[...]
gatewayusagemethod:i:0
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:RDCB.DOMAIN
workspace id:s:RDCB.DOMAIN
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.SITZUNGSAMMLUNG
use multimon:i:1
alternate full address:s:RDCB.DOMAIN
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
signature:s:[...]
Zitat von @ukulele-7:
zu 1)
Wenn die Sitzung des Users auf Host #3 getrennt wird und eine temporäre Sitzung auf Host #1 entsteht müsste dem User das
doch auffallen da seine Programme ja in der neuen Sitzung nicht mehr laufen oder sehe ich das falsch? Oder meinst du er trennt
seine Sitzung bewusst und RD-SH #1 erzeugt "einfach so" mal eine Temp-Sitzung?
zu 1)
Wenn die Sitzung des Users auf Host #3 getrennt wird und eine temporäre Sitzung auf Host #1 entsteht müsste dem User das
doch auffallen da seine Programme ja in der neuen Sitzung nicht mehr laufen oder sehe ich das falsch? Oder meinst du er trennt
seine Sitzung bewusst und RD-SH #1 erzeugt "einfach so" mal eine Temp-Sitzung?
Das ist ja das kuriose an der Sache, der User scheint nicht wirklich getrennt zu sein. Dennoch entsteht der Bak-Eintrag auf Host #1 und gleichzeitig zeigt der SessionBroker in der Übersicht (Status ist weiterhin aktiv) das eine Trennung durchgeführt worden wäre. Irgendetwas passiert, aber ich weiss nicht was. Der User selbst trennt aber die Sitzung nicht. Ein Verdacht wäre eventuell der Bildschirmschoner. Achja, der User wechselt auch nicht den Host, vor dem Ereignis ist er auf Host #3 und danach auch. Als wenn Host #1 einfach einen Phantom-Eintrag erzeugen würde.
zu 3)
Du kannst dich mit einer passenden rdp File auf die Sammlung am RD-CB verbinden. Wenn du noch keine Remote Apps bereit gestellt
hast und dich per Webseite anmeldest läßt sich diese dort runter laden. Sieht in etwa so aus:
Sry ich meinte nicht zu 3) sondern zu 4). Auch wenn du keine Remote Apps verwendest (und vor allem keine bereit gestellt hast) kannst du dich dort einmal anmelden und bekommst nur die passende RDP File angeboten. Die öffnest und speicherst du dir am besten mal und diese Verbindet sich dann auf den RD-CB der dich dann an die Farm verweist.
Ah okay - jetzt wird es Licht 
- das probier ich mal aus.
- das probier ich mal aus.
oder auch nicht - Wenn ich im IE den Webfeed auswähle, erhalte ich zwar das Icon für die RDS-Sammlung, kann diese auch ausführen, aber nicht speichern, runterladen oder deren Eigenschaften prüfen.
Wenn ich eine normale RDP-Session öffne und den RD-SessionBroker eintrage, erhalte ich eine Zugriffsverletzung, da ja der Domänenbenutzer sich nicht am SessionBroker anmelden kann/darf. Irgendwie vertrakt.
Wenn ich eine normale RDP-Session öffne und den RD-SessionBroker eintrage, erhalte ich eine Zugriffsverletzung, da ja der Domänenbenutzer sich nicht am SessionBroker anmelden kann/darf. Irgendwie vertrakt.
Also wenn ich mich mit dem Firefox auf https://<RD-WebAccessServer>/RDWeb mit meinem User anmelde kann ich per Rechtsklick die RDP File öffnen oder speichern.
nope - macht er nicht. Mit Links- oder Rechtsklick öffnet er sofort die Datei. Wenn ich STRG+Klick mache öffnet er zwar das Kontextmenü, soweit bin ich bereits, aber die Option Ziel speichern unter: ist ausgegraut.
Okay, zumindest ein Problem gelöst, die Weiterleitung im IIS (für sprechende Namen) war daran schuld, das er das Kontext nicht aufgemacht hat. Nachdem ich die Weiterleitung deaktiviert habe, konnte ich das Kontext normal öffnen, Problem ist aber weiterhin, das speichern ausgegraut ist.
Okay, zumindest ein Problem gelöst, die Weiterleitung im IIS (für sprechende Namen) war daran schuld, das er das Kontext nicht aufgemacht hat. Nachdem ich die Weiterleitung deaktiviert habe, konnte ich das Kontext normal öffnen, Problem ist aber weiterhin, das speichern ausgegraut ist.
So, ein wenig Zeit ist vergangen und konnte nun mal ein paar Dinge in der Zwischenzeit lösen.
Der RDWeb funktioniert nun, wichtig war hier, das der Client-PC das Zertifikat der Stammzertifizierungsstelle kennt/installiert hat. Danach konnte der Browser auch die Verbindung speichern und ausführen.
Punkt 4) ist damit gelöst. Man könnte zwar die RDP-Datei umschreiben und damit auch an die PC's verteilen, aber in einigen Fällen führte dies dazu, das die RDP-Datei dann nicht mehr lesbar war. Also haben wir diese einfach kurzerhand vom RDWeb runtergeladen und verteilt, die hat dann ohne Problem funktioniert und kann über Bearbeiten auch noch angepasst werden.
Punkt 1) Zumindest konnte ich da rausfinden, das die Anzeige der Verbindungstrennung, keine direkte Auswirkung auf die .bak hat. Diese scheint überwiegend direkt bei der Anmeldung selbst erzeugt zu werden, oder wenn sich Users abends nicht sauber abmelden (z. Bsp. Trennen).
Kennt dazu aber bereits jemand eine Idee, wie man die .bak gleich vermeiden kann?
Die anderen PUnkte 2,3,5 bestehen weiterhin, ohne Besserung.
Der RDWeb funktioniert nun, wichtig war hier, das der Client-PC das Zertifikat der Stammzertifizierungsstelle kennt/installiert hat. Danach konnte der Browser auch die Verbindung speichern und ausführen.
Punkt 4) ist damit gelöst. Man könnte zwar die RDP-Datei umschreiben und damit auch an die PC's verteilen, aber in einigen Fällen führte dies dazu, das die RDP-Datei dann nicht mehr lesbar war. Also haben wir diese einfach kurzerhand vom RDWeb runtergeladen und verteilt, die hat dann ohne Problem funktioniert und kann über Bearbeiten auch noch angepasst werden.
Punkt 1) Zumindest konnte ich da rausfinden, das die Anzeige der Verbindungstrennung, keine direkte Auswirkung auf die .bak hat. Diese scheint überwiegend direkt bei der Anmeldung selbst erzeugt zu werden, oder wenn sich Users abends nicht sauber abmelden (z. Bsp. Trennen).
Kennt dazu aber bereits jemand eine Idee, wie man die .bak gleich vermeiden kann?
Die anderen PUnkte 2,3,5 bestehen weiterhin, ohne Besserung.
Wenn ich das richtig verstehe hast du jetzt einen User der immer ein Temp Profil bekommt, oder betrifft das viele User?
UPDs können sich ziemlich zickig verhalten. In diesem Fall würde ich die betreffende UPD einfach mal löschen und neu erzeugen lassen. Ich habe mich während meiner Tests dann gegen UPD entschieden und für Redirected Folders.
UPDs können sich ziemlich zickig verhalten. In diesem Fall würde ich die betreffende UPD einfach mal löschen und neu erzeugen lassen. Ich habe mich während meiner Tests dann gegen UPD entschieden und für Redirected Folders.
1
Ja, die UPD war am Anfang recht zickig, das ist wahr. Aber aktuell, gerade durch den Farmbetrieb ist es eine nicht schlecht Alternative.
Zum Temp-Profil: Eigentlich ist es so, das diese nur bei der Anmeldung und da nur gelegentlich entstehen. Pro Woche haben wir evtl. 7-10 Temp-Profile, allerdings bei rund 100 Usern, die sich täglich an- und abmelden.
In vielen Fällen hilft es dann einfach den Registry-Eintrag .bak zu entfernen und gut ist.
Nun hatte ich die Idee, einfach das Deployment für temp-Anmeldungen zu sperren, Haken gesetzt, aber das ignoriert er (warum auch immer).
Den MSTSC-Link vom Rdweb testen wir nun seit einer Woche bei rund 5 Usern, die ursprünglich auch mal Temp-Anmeldungen hatten. Hier scheint es nun zu funktionieren (aber ist auch erst eine Woche rum) - sollte das weiterhin so bleiben würden wir dann es generell austauschen.
Einziger Haken bei dem rdweb-MSTSC - wenn das Kennwort abgelaufen ist und sich der User anmeldet, wird die Verbindung erst gar nicht aufgebaut, sprich der Anwender kann sein Passwort nicht mehr selbst ändern. EIn kleines Problem aktuell.
Zum Temp-Profil: Eigentlich ist es so, das diese nur bei der Anmeldung und da nur gelegentlich entstehen. Pro Woche haben wir evtl. 7-10 Temp-Profile, allerdings bei rund 100 Usern, die sich täglich an- und abmelden.
In vielen Fällen hilft es dann einfach den Registry-Eintrag .bak zu entfernen und gut ist.
Nun hatte ich die Idee, einfach das Deployment für temp-Anmeldungen zu sperren, Haken gesetzt, aber das ignoriert er (warum auch immer).
Den MSTSC-Link vom Rdweb testen wir nun seit einer Woche bei rund 5 Usern, die ursprünglich auch mal Temp-Anmeldungen hatten. Hier scheint es nun zu funktionieren (aber ist auch erst eine Woche rum) - sollte das weiterhin so bleiben würden wir dann es generell austauschen.
Einziger Haken bei dem rdweb-MSTSC - wenn das Kennwort abgelaufen ist und sich der User anmeldet, wird die Verbindung erst gar nicht aufgebaut, sprich der Anwender kann sein Passwort nicht mehr selbst ändern. EIn kleines Problem aktuell.
Mal ein kleiner Zwischenstatus:
Wir haben nun bei den Usern, die häufiger mit einem Temp-Profil aufgefallen sind, von den normalen MSTSC-Verbindungen auf einen RDWeb-Access umgestellt. Kurioserweise, ohne das wir am Profil was gemacht haben (also neu erstellt oder ähnliches), melden sich die User nun regulär an und auch User, die gelegentlich mal ein Temp-Profil hatten, kommen nun ohne Problem in das System. (Hier gilt aber immernoch die alte MSTSC bzw. bei Linux Rdesktop-Verbindung)
Fazit: Die im Eingangspost erwähnten .bak-Eintragungen entstehen weiterhin auf dem ersten RDS-Host. Alle anderen Server sind hier nun unauffällig.
Ein wenig weitergeforscht ergab nun folgende Information. Das angemeldete Profil (befindet sich also bei Host 2-4) hält scheinbar noch eine gewisse Verbindung zum angemeldeten Server (evtl. Heartbeat?) - ist der Server überlastet oder kann nicht schnell genug reagieren (schätzungsweise auch in beide Richtungen) wird die Verbindung als "disconnected" markiert - was sie aber nicht wirklich ist. Hierzu gibt es auch von Seiten MS eine kurze Information, das sich eine UDP gelegentlich mal trennen kann, muss aber das mal näher noch prüfen.
Das Phänomen kommt aber, bei näherer Prüfung, nur bei den Usern vor, die eine MSTSC nutzen. User mit RDWeb-Access melden sich eh direkt am Sessionbroker an und werden dann auf die Hosts 1-4 geleitet. Bei der MSTSC verbindet sich der Client aber mit dem Host 1 und wird von da aus weiterverbunden.
Wir haben nun bei den Usern, die häufiger mit einem Temp-Profil aufgefallen sind, von den normalen MSTSC-Verbindungen auf einen RDWeb-Access umgestellt. Kurioserweise, ohne das wir am Profil was gemacht haben (also neu erstellt oder ähnliches), melden sich die User nun regulär an und auch User, die gelegentlich mal ein Temp-Profil hatten, kommen nun ohne Problem in das System. (Hier gilt aber immernoch die alte MSTSC bzw. bei Linux Rdesktop-Verbindung)
Fazit: Die im Eingangspost erwähnten .bak-Eintragungen entstehen weiterhin auf dem ersten RDS-Host. Alle anderen Server sind hier nun unauffällig.
Ein wenig weitergeforscht ergab nun folgende Information. Das angemeldete Profil (befindet sich also bei Host 2-4) hält scheinbar noch eine gewisse Verbindung zum angemeldeten Server (evtl. Heartbeat?) - ist der Server überlastet oder kann nicht schnell genug reagieren (schätzungsweise auch in beide Richtungen) wird die Verbindung als "disconnected" markiert - was sie aber nicht wirklich ist. Hierzu gibt es auch von Seiten MS eine kurze Information, das sich eine UDP gelegentlich mal trennen kann, muss aber das mal näher noch prüfen.
Das Phänomen kommt aber, bei näherer Prüfung, nur bei den Usern vor, die eine MSTSC nutzen. User mit RDWeb-Access melden sich eh direkt am Sessionbroker an und werden dann auf die Hosts 1-4 geleitet. Bei der MSTSC verbindet sich der Client aber mit dem Host 1 und wird von da aus weiterverbunden.
