Jump to content

Frage bzgl. Loginskript "best practise" und Terminalserverprofil-Problem


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Windows-Gemeinde,

 

ich bin nun in die Situation gekommen, ein kleines Netz - ca. 15 Clients und ein Win2003-Server - zu betreuen, in welchem eine Terminalserverphilosophie gepflegt ist. Die Leute melden sich am lokalen Windows schon im AD an, machen aber dann alles in einer Terminalserversitzung. Der Windows-Server ist entsprechend groß dimensioniert. Mein Respekt auch groß. Er wurde länger nicht gewartet, so ein Einsatz von Externen in diesem Bereich kostet nun mal auch: Und so stehen 12 Milliarden Windows-Updates an.

Man hat da richtig Geld für diese Lösung ausgegeben - für mich eher unüblich in einer so kleinen Umgebung. Zumal die Support- und Ausfallfragen bei einem zentralen Terminalserver noch einmal eine Prise schärfer sind als bei einem einfachen AD mit Fat Clients. Na ja, das ist ein anderes Thema. Ich habe theoretisch auch die Möglichkeit, das Konzept umzukrempeln. Nur ein AD muss es bleiben.

 

Nun, ich habe schon ziemlich tiefe Windows-Kenntnisse, auch in gewissem Maße Server 2003/AD. Bevorzugte immer (noch) Netware, vor allem Berechtigungsangelegenheiten waren da immer transparenter und besser einzurichten. Sehr schöne Möglichkeiten auch über das Loginskript. Ich komme daher zur ersten Frage.

 

[Loginskript]

a) Soweit ich weiß, muss auf "Freigabe\skript.cmd" in den Eigenschaften des User-Objekts verwiesen werden, d.h., ich muss zunächst einen Ordner mit Loginskripten freigeben? Werden Loginskripte im %path% gefunden? Wie ist da die beste Vorgehensweise?

 

b) Ich will ein zentrales Loginskript haben, das dann ein User-Loginsrkipt aufruft. Alle bekommen also bspw. "login.cmd", und darin will ich dann ein "call %username%.cmd" unterbringen. Muss die aufgerufene cmd dann als absoluter Pfad gebracht werden? UNC? Ist das so überhaupt sinnvoll?

 

Bei Netware war das so: Ein Loginskript für den Bereich, und darin gab es dann "if member of VERWALTUNG then map root t HD1:\path\path" - Man konnte also auf Gruppenmitgliedschaft prüfen. Geht das mit Windows eigentlich auch?

 

[benutzerprofile auf dem Terminalserver]

Muss ich diese explizit im AD in dem Terminaldienstetab des Userobjekts angeben? Bei allen Usern ist dies nämlich nicht so. Aber: Lege ich einen neuen User an, bekommt er auf dem Client ein Profil, aber auf dem Terminalserver in der Remotedesktopsitzung nicht: "Das lokale Benutzerprofil konnte nicht geladen werden". Und der Nutzer kann sich nicht anmelden.

Ich hätte gedacht, auch hier legt Windows einfach eine Kopie des "Default User"-Ordners an. Dieser liegt auch im Profilpfad.

 

Viele Grüße

Michael

Link zu diesem Kommentar

ich bin nun in die Situation gekommen, ein kleines Netz - ca. 15 Clients und ein Win2003-Server - zu betreuen, in welchem eine Terminalserverphilosophie gepflegt ist. Die Leute melden sich am lokalen Windows schon im AD an, machen aber dann alles in einer Terminalserversitzung. Der Windows-Server ist entsprechend groß dimensioniert. Mein Respekt auch groß. Er wurde länger nicht gewartet, so ein Einsatz von Externen in diesem Bereich kostet nun mal auch: Und so stehen 12 Milliarden Windows-Updates an.

 

Für die Windows Updates gibts den WSUS.

 

[Loginskript]

a) Soweit ich weiß, muss auf "Freigabe\skript.cmd" in den Eigenschaften des User-Objekts verwiesen werden, d.h., ich muss zunächst einen Ordner mit Loginskripten freigeben? Werden Loginskripte im %path% gefunden? Wie ist da die beste Vorgehensweise?

 

Du kannst die Loginscripte auch ins Sysvol bzw. Netlogon legen. Anmelde Skripe - Möglichkeiten und Funktionen

Du kannst allerdings auch den TS-Benutzern per GPP eigene Scripte zuweisen. Einsatz von Gruppenrichtlinien auf einem Terminal Server und GPP - Group Policy Preferences - Gruppenrichtlinien Einstellungen

 

b) Ich will ein zentrales Loginskript haben, das dann ein User-Loginsrkipt aufruft. Alle bekommen also bspw. "login.cmd", und darin will ich dann ein "call %username%.cmd" unterbringen. Muss die aufgerufene cmd dann als absoluter Pfad gebracht werden? UNC? Ist das so überhaupt sinnvoll?

 

IMHO sollte es ausreichen, wenn die %username%.cmd im gleichen Verzeichnis wie die login.cmd liegt. Und wenn Du in den Scripten mit Pfaden arbeitest, dann immer mit UNC-Pfaden.

 

Bei Netware war das so: Ein Loginskript für den Bereich, und darin gab es dann "if member of VERWALTUNG then map root t HD1:\path\path" - Man konnte also auf Gruppenmitgliedschaft prüfen. Geht das mit Windows eigentlich auch?

 

Jepp, entweder über die IfMember.exe oder Du regelst es über Sicherheitsgruppen in den Group Policy Preferences.

 

[benutzerprofile auf dem Terminalserver]

Muss ich diese explizit im AD in dem Terminaldienstetab des Userobjekts angeben? Bei allen Usern ist dies nämlich nicht so. Aber: Lege ich einen neuen User an, bekommt er auf dem Client ein Profil, aber auf dem Terminalserver in der Remotedesktopsitzung nicht: "Das lokale Benutzerprofil konnte nicht geladen werden". Und der Nutzer kann sich nicht anmelden.

Ich hätte gedacht, auch hier legt Windows einfach eine Kopie des "Default User"-Ordners an. Dieser liegt auch im Profilpfad.

 

Mit TS-Profilen hab ich fast noch nie gearbeitet, die haben aber mit den "normalen" Profilen nichts zu tun. Du mußt also für die TS-Benutzer eigene Profile anlegen. Am besten Du erstellst dir einen Beispiel TS-Benutzer, den kopierst Du dann immer nur. Schon hast Du alles wichtige drin.

Link zu diesem Kommentar

Du musst im AD auf jedenfall die Terminalservices Profilpfade eintragen und dafür Ordner mit ensprechenden Rechten im Netzwerk erstellen. Danach bekommt der User nach dem ersten login ein Standprofil reingespielt. Am besten wäre es wenn der User sich das einfach einmal einrichtet. Theoretisch ist es teilweise möglich Profile von den lokalen Maschinen in den TSprofilpfad zu kopieren und dann zu laden wenn es sich um kompatible OS handelt(XP 2003), allerdings würde ich davon abraten, da es teilweise zu seltsamen Vorkommnissen kommen kann. Z.b Standardrucker nicht einrichtbar und anderes.

Link zu diesem Kommentar
Für die Windows Updates gibts den WSUS.

Schon klar, auch in meinen Netware-Welten werkeln WSUSe sehr zuverlässig ohne AD (man muss halt überall lokale Richtlinien anpassen). Ist halt ein übernommener Terminalserver wg. Wegfall eines anderen Dienstleisters, und da muss man aufpassen.

 

Bzgl. Loginskript SYSVOL/Netlogon hatte ich mittlerweile auch nachgelesen, danke. ifmember.exe nehme ich an ist aus dem Resource Kit? (kann ich jetzt nicht nachsehen)

 

Mit TS-Profilen hab ich fast noch nie gearbeitet, die haben aber mit den "normalen" Profilen nichts zu tun. Du mußt also für die TS-Benutzer eigene Profile anlegen. Am besten Du erstellst dir einen Beispiel TS-Benutzer, den kopierst Du dann immer nur. Schon hast Du alles wichtige drin.

 

Was mich gewundert hat war, dass im AD-Objekt des Nutzers unter "Terminal Services Profile" bei keinem Nutzer etwas unter "Profile Path" eingetragen war. Und alle konnten sich am Terminalserver anmelden.

 

Hat das wirklich nichts mit den normalen Profilen zu tun? D.h., in der Umgebung gibt es auch Roaming Profiles, die Nutzer können sich auch gleichzeitig an jedem PC direkt anmelden. Ich denke ja, was ich jetzt nicht testen kann, dass ich neue User nur einfach einmal direkt hätte anmelden müssen. Ich war nämlich als Admin angemeldet und wollte den neu angelegten User in einer Remotedesktopsitzung anmelden. Das war doch bestimmt der Fehler.

Link zu diesem Kommentar
Bzgl. Loginskript SYSVOL/Netlogon hatte ich mittlerweile auch nachgelesen, danke. ifmember.exe nehme ich an ist aus dem Resource Kit? (kann ich jetzt nicht nachsehen)

 

Soweit ich weiß ist die aus dem Resource Kit. Download details: Resource Kit Web Package: IfMember.exe

 

Was mich gewundert hat war, dass im AD-Objekt des Nutzers unter "Terminal Services Profile" bei keinem Nutzer etwas unter "Profile Path" eingetragen war. Und alle konnten sich am Terminalserver anmelden.

 

Wenn dort kein spezieller Pfad eingetragen ist, wird ein lokales Profil auf dem TS angelegt/verwendet.

 

Hat das wirklich nichts mit den normalen Profilen zu tun? D.h., in der Umgebung gibt es auch Roaming Profiles, die Nutzer können sich auch gleichzeitig an jedem PC direkt anmelden.

 

Das eine hat mit dem anderen normalerweise nichts zu tun.

 

Ich denke ja, was ich jetzt nicht testen kann, dass ich neue User nur einfach einmal direkt hätte anmelden müssen. Ich war nämlich als Admin angemeldet und wollte den neu angelegten User in einer Remotedesktopsitzung anmelden. Das war doch bestimmt der Fehler.

 

Das hab ich nicht ganz verstanden. ;)

Link zu diesem Kommentar

Danke für die Antworten. Was sich herausstellte:

Der Server legte keine Profile an, weil er halbwegs down war. Lief auch schon viele Monate durch. Nachdem ich den User zum Admin machte, ließ sich Windows nämlich auch zu einer konkreteren Fehlermeldung herab: "Es steht nicht genügend Speicher zur Verfügung". Na ja, das stimmte zwar RAM- und HD-technisch nicht, aber es musste halt ein Reboot her. Dann lief der Laden wieder.

Link zu diesem Kommentar
Ich weiß nicht wie das mit den aktuellen Betriebssystemen ist, aber bei W2K und W2003 gabs die Empfehlungen einen TS mind. einmal in der Woche neu zu starten.

Ist ja ein 2K3. Jedoch ist ja auch so ein Neustart (den würde da ein Mitarbeiter vor Ort durchführen) mit Risiken behaftet (von rausgekegelten Sitzungen mit anschließenden Fehlermeldungen beim User bis hin zum Server, beim Booten irgendwo hängen bleibt) -> dann müssen die Supportstrukturen stimmen. Tun sie aber nicht. (Warum? Kommt auch keiner von Euch drauf - Das Zauberwort fängt mit "Spa" an und hört mit "ren" auf) ;) Führt hier aber zu weit.

Link zu diesem Kommentar
Ist ja ein 2K3. Jedoch ist ja auch so ein Neustart (den würde da ein Mitarbeiter vor Ort durchführen) mit Risiken behaftet

 

Du kannst den Neustart schon mit der shutdown.exe forcieren. Offene Sitzungen lassen sich mit tsdiscon disconnecten.

 

(von rausgekegelten Sitzungen mit anschließenden Fehlermeldungen beim User bis hin zum Server, beim Booten irgendwo hängen bleibt)

 

Die Benutzer müssen informiert werden, dass am z.B. Freitag Abend um 23.00 Uhr die Server gebootet werden. Wer sich nicht korrekt abmeldet hat verloren. Hört sich schlimm an, manche lernen es aber nur durch Schmerzen.

 

-> dann müssen die Supportstrukturen stimmen. Tun sie aber nicht. (Warum? Kommt auch keiner von Euch drauf - Das Zauberwort fängt mit "Spa" an und hört mit "ren" auf) ;) Führt hier aber zu weit.

 

Du bist ja vor Ort, also mußt Du versuchen etwas zu verändern. ;)

Link zu diesem Kommentar

Ich bin auch nur beauftragt und selten vor Ort. Zwar richtet man sich nach meiner Philosophie, die ich auch durchsetzen will, aber am liebsten nur selten :-| (-> $$$)

 

Angenommen, ich regle das per scheduler. Ist tsdiscon wichtig, d.h. werden Sitzungen, die trotz gutem Zureden nur getrennt wurden, "sauberer" beendet, als wenn man shutdown.exe einfach brachial dranlässt?

 

Ich finde Deinen Hinweis gut. Ich denke, ich werde da eine gewisse Regelmäßigkeit einführen.

Link zu diesem Kommentar

Angenommen, ich regle das per scheduler. Ist tsdiscon wichtig, d.h. werden Sitzungen, die trotz gutem Zureden nur getrennt wurden, "sauberer" beendet, als wenn man shutdown.exe einfach brachial dranlässt?

 

Ich weiß es nicht. Das mußt Du ausprobieren. Shutdown -f könnte natürlich bewirken, dass dabei ein Profil kaputt gemacht wird, also dürfte es besser sein die Sessions vorher mit tsdiscon zu beenden.

 

Ich finde Deinen Hinweis gut. Ich denke, ich werde da eine gewisse Regelmäßigkeit einführen.

 

Dann gleich noch einen, installiere unbedingt UPHC auf dem Server. Der Dienst hilft verhindern, das ein Profil kaputt geht.

Link zu diesem Kommentar
Dann gleich noch einen, installiere unbedingt UPHC auf dem Server. Der Dienst hilft verhindern, das ein Profil kaputt geht.

Joo, den hatte ich schon immer auf dem Schirm, seit ich auf meinen privaten Clients mit XP/Truecrypt/TCGina zu tun hatte. Hat mich auch immer gewundert, dass das nicht im OS fest eingebaut wurde im Rahmen von Windows Update beispielsweise... Aber ab Vista/2008 ist er glaube ich nicht mehr nötig.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...