1
Roaming Profile : Anmeldung vom ThinClient und RemoteApp-Benutzung
Hallo zusammen,
ich habe Problem bei dem ich gerade nicht weiter weiß.
Wir betreiben eine RD-Server-Umgebung mit mehreren Servern bzw. Farmen.
Nachdem eine ziemlich ressourceintensive Anwendung beschafft wurde, soll diese mit RemoteApp von einem entsprechend leistungsstarken Server aus bereitgestellt werden.
Die Benutzer selbst haben am Arbeitsplatz nur ThinClients stehen und melden sich per PDP an der Büro-Farm an.
Und jetzt mein Problem : Wenn ein Benutzer die RemoteApp startet findet ja ein komplette Anmeldung statt und es wird dann aber nur, in einem Fenster, die eine zu startenden Anwendung "ausgeliefert".
Wenn der Benutzer fertig ist beendet er das Programm. Die RDP-Sitzung wird aber nur getrennt und der Benutzer nicht abgemeldet.
Wenn der Benutzer Feierabend macht meldet er sich an dem ThinClient ab und auch die RDP-Session wird beendet und das Profil weggeschrieben.
Nach geraumer Zeit schlägt das Leerlaufsitzungslimit zu und die RDP-Session auf dem RemoteApp-Server wird beendet und das veraltete Profile über das eigentlich korrekte geschrieben.
Ergebnis : Am nächsten morgen ist der Benutzer unglücklich, weil z.B. Einstellungen weg sind.
Und jetzt mein Frage : Wie kann ich den RemoteApp-Server dazu bringen, das er entweder das zwischengespeicherte Profil wegwirft (und nicht auf dem RemoteDesktopProfilPfad speichert) oder nach Beendigung des Programm den Benutzer sofort wieder abmeldet.
Ich bin über jede Hilfe dankbar.
Beste Grüße
ich habe Problem bei dem ich gerade nicht weiter weiß.
Wir betreiben eine RD-Server-Umgebung mit mehreren Servern bzw. Farmen.
Nachdem eine ziemlich ressourceintensive Anwendung beschafft wurde, soll diese mit RemoteApp von einem entsprechend leistungsstarken Server aus bereitgestellt werden.
Die Benutzer selbst haben am Arbeitsplatz nur ThinClients stehen und melden sich per PDP an der Büro-Farm an.
Und jetzt mein Problem : Wenn ein Benutzer die RemoteApp startet findet ja ein komplette Anmeldung statt und es wird dann aber nur, in einem Fenster, die eine zu startenden Anwendung "ausgeliefert".
Wenn der Benutzer fertig ist beendet er das Programm. Die RDP-Sitzung wird aber nur getrennt und der Benutzer nicht abgemeldet.
Wenn der Benutzer Feierabend macht meldet er sich an dem ThinClient ab und auch die RDP-Session wird beendet und das Profil weggeschrieben.
Nach geraumer Zeit schlägt das Leerlaufsitzungslimit zu und die RDP-Session auf dem RemoteApp-Server wird beendet und das veraltete Profile über das eigentlich korrekte geschrieben.
Ergebnis : Am nächsten morgen ist der Benutzer unglücklich, weil z.B. Einstellungen weg sind.
Und jetzt mein Frage : Wie kann ich den RemoteApp-Server dazu bringen, das er entweder das zwischengespeicherte Profil wegwirft (und nicht auf dem RemoteDesktopProfilPfad speichert) oder nach Beendigung des Programm den Benutzer sofort wieder abmeldet.
Ich bin über jede Hilfe dankbar.
Beste Grüße
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: 214982
Url: https://administrator.de/forum/roaming-profile-anmeldung-vom-thinclient-und-remoteapp-benutzung-214982.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
1 Kommentar
Hallo.
ich denke, letzteres bringt eher etwas. Nach Beendigung der Remote-App (die ja in der Tat auch Teil einer eigenen, vollständigen Windows-Session auf dem Terminalserver ist) muß der User sogleich abgemeldet werden, das Profil mitsamt Änderungen wird zurückgeschrieben, fertig.
Was mich bloß wundert:
Ich kenne es eigentlich nur so, daß wenn eine Terminalserver- bzw. RDS-Sitzung nur mittels einer einzelnen Anwendung stattfindet (anstatt mit einem vollständig gepublishten Desktop), und diese Anwendung geschlossen wird, eigentlich auch gleich danach die Windows-Sitzung beendet wird (im Sinne von Abmeldung).
Wenn dennoch keine Abmeldung stattfindet, liegt das meist an Prozessen, die nicht richtig geschlossen werden (können).
Allererste Kandidaten dafür:
- alles, was im Systray angezeigt wird (der User aber nicht sieht, weil er bloß eine Anwendung dieser Sitzung sieht)
- Druckertreiber!
Hinsichtlich Druckertreibern auf Terminalservern gibt es Best-Practise-Empfehlungen:
- IMMER nur Classic-Treiber verwenden, idealerweise mit Microsoft WHQL od. WHCL und als Universaltreiber!
- PCL 5 geht vor PCL 6 oder PS (ich verwende nur PCL 5, wenn möglich/vorhanden), insbesondere bei HP-Druckern
- NIEMALS Hersteller-Treiber mit herstellereigenen Sonderfunktionen (Bsp. bei Kyocera: KX- oder KPDL-Treiber) verwenden, deshalb Classic!
Gib einem User testweise mal nicht nur die einzelne Anwendung, sondern den gesamten Desktop und schau ihm zu. Dann wird vielleicht schon erkennbar, was da z. B. im Systray alles eingeblendet ist, was eine vollständige Abmeldung verhindern könnte, und kontrolliere Deine Druckertreiber.
Wie gesagt, eigentlich müßte die Windows-Sitzung schon abgemeldet werden, nachdem die Anwendung geschlossen wurde. und dann gibt's auch kein Problem mit dem korrekten (und sofortigen) zurückschreiben des Profils.
Eine weitere, aber etwas aufwendige Möglichkeit, die "BadApp", die die Abmeldung verhindert, bzw. deren Prozess zu finden, ist folgende Vorgehensweise ("geklaut" bei Thomas Koetzing):
- Öffnen der Sitzungseigenschaften der noch aktiven Sitzung in der Terminaldiensteverwaltungskonsole
- Terminierung der noch laufenden Prozesse "step-by-step" und jedesmal auf eine Abmeldung warten.
- Wenn eine Abmeldung erfolgt, festhalten welcher Prozess die Abmeldung ermöglichte. Als Beispiel sagen wir mal es ist der Prozess "BadApp.exe"
- Wird BadApp.exe wirklich benötigt? Wenn nicht, dann die exe entfernen bzw. das Programm deinstallieren.
Ist etwas Arbeit, aber Du kannst dem Problem schon auf die Spur kommen.
Grüße
von
departure
ich denke, letzteres bringt eher etwas. Nach Beendigung der Remote-App (die ja in der Tat auch Teil einer eigenen, vollständigen Windows-Session auf dem Terminalserver ist) muß der User sogleich abgemeldet werden, das Profil mitsamt Änderungen wird zurückgeschrieben, fertig.
Was mich bloß wundert:
Ich kenne es eigentlich nur so, daß wenn eine Terminalserver- bzw. RDS-Sitzung nur mittels einer einzelnen Anwendung stattfindet (anstatt mit einem vollständig gepublishten Desktop), und diese Anwendung geschlossen wird, eigentlich auch gleich danach die Windows-Sitzung beendet wird (im Sinne von Abmeldung).
Wenn dennoch keine Abmeldung stattfindet, liegt das meist an Prozessen, die nicht richtig geschlossen werden (können).
Allererste Kandidaten dafür:
- alles, was im Systray angezeigt wird (der User aber nicht sieht, weil er bloß eine Anwendung dieser Sitzung sieht)
- Druckertreiber!
Hinsichtlich Druckertreibern auf Terminalservern gibt es Best-Practise-Empfehlungen:
- IMMER nur Classic-Treiber verwenden, idealerweise mit Microsoft WHQL od. WHCL und als Universaltreiber!
- PCL 5 geht vor PCL 6 oder PS (ich verwende nur PCL 5, wenn möglich/vorhanden), insbesondere bei HP-Druckern
- NIEMALS Hersteller-Treiber mit herstellereigenen Sonderfunktionen (Bsp. bei Kyocera: KX- oder KPDL-Treiber) verwenden, deshalb Classic!
Gib einem User testweise mal nicht nur die einzelne Anwendung, sondern den gesamten Desktop und schau ihm zu. Dann wird vielleicht schon erkennbar, was da z. B. im Systray alles eingeblendet ist, was eine vollständige Abmeldung verhindern könnte, und kontrolliere Deine Druckertreiber.
Wie gesagt, eigentlich müßte die Windows-Sitzung schon abgemeldet werden, nachdem die Anwendung geschlossen wurde. und dann gibt's auch kein Problem mit dem korrekten (und sofortigen) zurückschreiben des Profils.
Eine weitere, aber etwas aufwendige Möglichkeit, die "BadApp", die die Abmeldung verhindert, bzw. deren Prozess zu finden, ist folgende Vorgehensweise ("geklaut" bei Thomas Koetzing):
- Öffnen der Sitzungseigenschaften der noch aktiven Sitzung in der Terminaldiensteverwaltungskonsole
- Terminierung der noch laufenden Prozesse "step-by-step" und jedesmal auf eine Abmeldung warten.
- Wenn eine Abmeldung erfolgt, festhalten welcher Prozess die Abmeldung ermöglichte. Als Beispiel sagen wir mal es ist der Prozess "BadApp.exe"
- Wird BadApp.exe wirklich benötigt? Wenn nicht, dann die exe entfernen bzw. das Programm deinstallieren.
Ist etwas Arbeit, aber Du kannst dem Problem schon auf die Spur kommen.
Grüße
von
departure
