Alles zum Thema Windows Server sowie Windows IT Pro Themen — Q & A zu den Windows Server Versionen NT / 2000 / 2003 / 2003 R2 / 2008 / 2008 R2: Rollen, Features, Konfiguration, Troubleshooting
2K3R2 - Frage bzgl. Loginskript "best practise" und Terminalserverprofil-Problem
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.
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.
Zitat von perren
[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?
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.
Zitat von perren
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.
Zitat von perren
[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.
ich hab hier mal zu ne Frage, wenn ich mir das alles durchlese dann müßten doch wenn ich in der GPO beim Loopbackverarbeitungsmodus "Zusammenführen" einstelle, alle lokalen Einstellungen auch auf den TS-Server übernommen?
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.
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.
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)
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.
Zitat von perren
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.
Zitat von perren
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.
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.
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.
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.
