LLZwerg

Weil wir als Hoster auftreten und Kunden Zugriff auf unsere Terminalserver geben, damit sie unsere Programme dort ausführen können. Derjenige, der hier war, war auch MLP, den wir eingeladen hatten, weil unser Modell über Forum wohl doch eher schlecht bzw. schlecht verständlich zu beschreiben ist. Da wir inzwischen auch von 3 Anbietern, die das SPLA-Modell anbieten, jetzt nochmal jemanden hier hatten, die sich das bei uns genauer angeschaut haben und alle dasselbe sagten, sollte das passen. Gruß Timo

Sorry erstmal, daß ich mich nicht weiter gemeldet hatte. Wir hatten vor kurzem jetzt mal jemanden hier um das genauer zu besprechen und dabei kam dann zutage, daß wir das Lizenzmodel SPLA benötigen (das Modell war mir bisher allerdings noch unbekannt). Danke aber für die Antworten und eure Bemühungen. :) Gruß Timo

Mit LV meine ich Lizenzverwaltung. Und eine Möglichkeit der Kontrolle hatte ich bei den Device-CALs (hatten wir bisher auf W2k) noch nicht gefunden. Wer sich anmelden konnte, der bekam auch eine Lizenz. Ich wüßte nicht, wie ich das hätte verhindern können. Selbst eine Einschränkung der IPs bei den VPN-Verbindungen hätte da wenig gebracht, wenn die Kunden NAT einsetzen und ihr gesamtes Netz auf eine Adresse umsetzen. Wenn das doch gehen sollte und ich da immer was übersehen habe, würde mich brennend interessieren, was ich übersehen habe. :) Die Kunden greifen auf die Server zu um unsere Software zu nutzen. Die Software ist ein Frontend für den Zugriff auf unsere Datenbanken. Das läuft auf unseren Servern, damit kundenseitig nichts installiert werden muß und da die Datenbankserver bei uns im RZ stehen. Die Software ist in dem Fall quasi von uns gemietet. Gruß Timo

Danke für die Infos erst mal. Die LV von Microsoft mochte ich irgendwie noch nie so wirklich, weil man so gar keine Kontrolle über die Vergabe der Lizenzen hat. :) Die Anwendungen sind unsere eigenen Programme (also von unseren Entwicklern programmiert), nichts von Microsoft oder ähnliches. Was von Drittanbietern eingesetzt wird, ist mit den entsprechenden Anbietern entsprechend geklärt, daß wir entweder eine General-Lizenz haben, die Lizenz pro Server vergeben ist oder aber eine Concurrent-Lizenz ist. Es geht also hier wirklich nur um die reine Anmeldung an unsere Terminalserver. Die Frage ist dann nun, wie wir als Anbieter garantiern sollen, daß sich nur die vom Kunden gekaufte Anzahl an Usern anmeldet. Bei Device-CALs ist es ja klar. Von einem PC kommt eine Anmeldung, Lizenz wird vergeben. Und selbst da ist es nicht wirklich zu kontrollieren, weil man ja nicht angeben kann, für welches Device eine Lizenz vergeben werden darf. Wer sich anmeldet, der bekommt auch eine Lizenz. Bei User-CALs könnte ich es höchstens noch an der Anzahl der im AD eingerichteten Usern halbwegs kontrollieren, indem ich nur eine Anmeldung pro User zulassen. Der User kann dann aber ja auch wieder von unterschiedlichen Personen genutzt werden (dann halt nur nicht gleichzeitig). Aber wie zum Teufel soll man kontrollieren, daß der User im AD vom Kunden nicht über verschiedene Mitarbeiter genutzt wird (Schichtdienst, Halbtagskräfte, etc.). Ist ja dann im Prinzip eine reine Vertrauenssache zum Kunden, da wir das auf den Servern nicht kontrollieren können. Danke und Gruß Timo

Guude, wir sind hier gerade dabei eine neue Terminalserver-Farm unter Windows 2008 aufzusetzen. Darauf sollen dann unsere Kunden über VPN-Verbindungen und Standleitungen zugreifen um unsere Anwendung zu nutzen. Bisher hatten wir Device-CALs, wollen aber nun, da die Steuerung über die Lizenzvergabe im Prinzip nicht wirklich möglich ist (bei Win2k war es lizenztechnisch günstiger wegen der "eingebauten" Lizenzen bei XP und Win2k), User-CALs einsetzen. Von Kundenseite sollen insgesamt ca. 150 User zugreifen. Zeitgleiche Zugriffe beschränken sich aber auf 40 User. Nun meine Frage zur Lizenzierung, da ich weder bei Microsoft noch hier im Forum etwas finden konnte, was mir die Frage wirklich beantwortet hat. Benötigen wir nun - 150 Lizenzen, weil 150 User zugreifen KÖNNTEN - 40 Lizenzen, weil nur 40 zeitgleich zugreifen - Lizenzen abhängig der im AD eingerichteten User (wovon ich aber nicht ausgehe, weil ich zumindest finden konnte, daß die Lizenzen wohl personenbezogen sind) Bei Microsoft habe ich nur das hier gefunden: LicensingMode Auszug: Values 2 CALs are configured Per Device: Configures Terminal Server to require that each connected client computer has a valid Terminal Server Client Access License (CAL). If the client computer has a Terminal Server CAL, it can access more than one Terminal Server. 4 CALs are configured Per Session: Configures Terminal Server to provide one Terminal Server CAL for each active client session. 5 LicensingMode is not configured Wichtig hierbei finde ich bei Wert 4 die Bemerkung „for each ACTIVE client session“. Für mich heißt das, daß eine User CAL nur solange benötigt wird, solange die Sitzung auch aktiv ist, also concurrent users und nicht fest zugeordnet. Wobei ich da aber auch wieder die Formulierung Per Session nicht so richtig zuordnen kann, aber auf der Seite geht es ja um die Lizenzierung von Terminalservern und daher gehe ich davon aus, daß hier die Lizenzierung pro Benutzer gemeint ist (denn nur die finde ich in der Aktivierung des Terminalservers). Oder liege ich da falsch? Ich bin da im Moment etwas ratlos, zumal wir von diversen "Microsoft Partnern" auch unterschiedliche Aussagen bekommen haben. Danke und Gruß Timo

Mit der LV von 2008 habe ich mich zwar noch nicht so sehr beschäftigt, aber ich gehe mal davon aus, daß sich das Freigabeverhalten nicht sonderlich geändert hat. Demnach sollte eine Lizenz eine Gültigkeit von 90 Tagen haben. Wenn in der Zeit keine Anmeldung von dem PC mehr erfolgt müßte Sie freigegeben werden. Die neuen PCs sollten dann erst mal eine temporäre Lizenz bekommen. die 90 Tage gültig ist und danach erst eine richtige Lizenz benötigen. Daher solltest Du bei einem direkten Austausch keine Probleme bekommen. Ich schreibe bewußt "sollte", weil ich mit der LV die Erfahrung habe, daß die Freigabe einer Lizenz nicht immer sauber funktioniert. Allerdings war es da bisher auch immer recht problemlos möglich, über die Hotline ein Lizenzpaket auf dem Server neu zu installieren. Damit wird dann das alte Paket ungültig (bleibt in der Übersicht aber vorhanden) und das neue Paket wird für die Ausstellung weiterer Lizenzen verwendet. Gruß Timo

Naja, das Profil wird halt komplett vom DC geladen und überklatscht das alte. Und damit ist dann auch die ntuser.man weg. Der entsprechende User hat auf sein Profil alle Rechte, da er in der Sitzung ja ggfs. auch schreibenden Zugriff auf seinen Registry-Bereich haben muß. Andere (außer dem Admin) haben keinen Zugriff auf das Profilverzeichnis. Gruß, Timo

Ne, das ist leider nicht ganz was ich suche, aber trotzdem danke für die schnelle Antwort. :) Einen Windows-DC haben wir nicht im Einsatz, das läuft über einen Unix-Server (die DC-Software heißt Gosa). Aber das Profil soll nicht generell verbindlich sein, sondern nur auf den Terminalservern. Auf dem DC soll ntuser.dat schon bleiben, nur auf den Terminalservern sollte er die Profile nicht wieder zurückspeichern. Wie gesagt, unter 2000 hat das noch funktioniert, da waren auf dem Terminalserver dann die ntuser.dat und die ntuser.man im Profil und er hat nicht zurückgespeichert. Nur auf 2003 wird die ntuser.man immer wieder weggeworfen bei einer Neuanmeldung. Ich weiß jetzt allerdings nicht, ob da nur eine Einstellung fehlt, oder ob 2003 das anders handhabt als Windows 2000. Da konnte ich auch leider nichts zu finden. Gruß, Timo

Hallöchen, ich habe auf Windows 2003 Terminalservern ein Problem und hoffe, hier hat jemand eine Idee dazu. Zunächst mal die Konstellation: DC ist ein Samba-Server, auf dem auch die Benutzerprofile gespeichert werden. Die User arbeiten an Workstations, an denen sie auch Änderungen an ihren Profilen vornehmen dürfen. Auf 2 W2k3 Terminalservern wird von zu Hause gearbeitet. Das Problem besteht nun darin, daß sich bei manchen Usern durch die Anmeldung an die Terminalserver verschiedene Einstellungen ändern, wenn sie darüber arbeiten (z.B. Druckereinstellungen, weil der Drucker am PC auf dem Terminalserver nicht bekannt ist). Als die Terminalserver noch unter Windows 2000 gelaufen sind, habe ich in den entsprechenden Profilen auf dem Terminalserver einfach die ntuser.dat in ntuser.man umgeändert, um das Profil auf dem Terminalserver verbindlich zu machen. Dann wurde das Profil auf den Terminalservern vom DC neu geladen, aber bei der Abmeldung nicht zurückgeschrieben. An den Workstations waren die Profile weiterhin änderbar. Bei 2003 besteht aber nun das Problem, daß das Profil immer bei jeder Anmeldung komplett überschrieben wird. D.h., wenn sich der User anmeldet, dann ist auch das Profil nicht mehr verbindlich und wird zurückgeschrieben. Ich hab hier im Board und unter Google schonmal gesucht, konnte aber nirgens etwas über Änderungen diesbezüglich bei W2k3 finden. Hat dazu jemand eine Idee oder vielleicht das gleiche Problem schonmal gehabt und lösen können? Danke und schonmal und Gruß, Timo

Hm, das ist ne Idee. Hätte ich gleich mal testen sollen. :) Läuft zwar auch damit nicht, aber geht nen Schritt weiter. Zumindest bleibt es da nicht beim Zuweisen der Parameter hängen. Das Schreiben der Parameter funktioniert damit im Gegensatz zum direkten Aufruf. Leider startet aber ntbackup dann noch nicht. Da muß ich wohl nochmal etwas weiter suchen. Wäre zwar nicht so schön, wie ich es gerne hätte, aber besser als ein eigenes Script für jede Sicherung. :) Danke und Gruß, Timo

Hallöchen, bin leider heute erst dazu gekommen wieder etwas daran zu testen. Mit einem Domain Admin geht es auch nicht. Auch hier bleibt das Script hängen, wenn ich die Parameter-Zuweisungen im Script aktiv habe. Hat sonst noch jemand eine Idee, warum es bei der manuellen Ausführung ohne Probleme läuft, aber nicht als Task? Danke und Gruß, Timo

Hallöchen, ich hab jetzt schon bei Google und hier eine Weile ohne Ergebnis gesucht. Mein Problem ist, daß ich ein VB-Script, das mit Parametern arbeitet, als geplanten Task ausführen möchte. Das Script läuft problemlos, wenn ich es manuell aufrufe, aber als Task wird es zwar gestartet, aber nicht abgearbeitet (manuell wird ntbackup gestartet, als Task bleibt ewig wscript hängen). Den Task habe ich sowohl manuell als auch im Task-Planer mit dem User Administrator ausgeführt. Wenn ich im Script das Auslesen der Parameter auskommentiere funktioniert das Script auch im Taskplaner, wenn ich es drinlasse bleibt der Task einfach hängen und arbeitet scheinbar nach der Zuweisung der Parameter zu den entsprechenden Variablen nicht mehr weiter. Hier mal das Script: Der Aufruf bei diesem komischen Smiley im Quote steht für "hc: off" (ohne Leerzeichen). Um sicherzugehen, daß es nicht an dem Aufruf von NTBackup oder dem Netzlaufwerk liegt, habe ich auch das schonmal komplett auskommentiert (also alles hinter der Parameterzuweisung) und stattdessen einen Part eingesetzt, der die Parameter in eine lokale Datei schreiben würde (was auch wieder manuell funktioniert aber nicht als Task). Der Aufruf des Scripts ist sowohl als Task als auch manuell folgender: script.vbs 5 ts02 woche-1 test Ich habe auch schon einiges probiert, allerdings bisher ohne Erfolg. Nur wenn ich die Zuweisungen für nummer, verzeichnis, conf_datei und save_name auskommentiere läuft das Script auch als Task. Allerdings kann man z.B. Notepad mit dem Aufruf notepad.exe c:\test.txt als Task ausführen, es scheint also ein Problem beim Script zu sein, wenn Argumente im Script verarbeitet werden sollen. Hat hier jemand evtl. eine Idee, woran das liegen könnte? Mir fällt da langsam nichts mehr ein. Ich würde gerne nur ein Script für die ganzen Sicherungen nutzen, das ich mit Parametern entsprechend steuern kann und nicht für jede Sicherung ein neues Script hinsetzen (Scripts ohne Parameter funktionieren auch als Task), weil ich das etwas unschön finde. Danke und Gruß, Timo

Hm, beim SMS kann ich leider nicht viel helfen, da ich damit noch nicht allzuviel zu tun hatte. Die Auswertung per Script ist allerdings recht aufwendig, wenn es sehr viele PCs sind. :)

Für die Anmeldezeiten der User habe ich bei uns auch ein Script laufen. Da erfasse ich zwar zur Zeit keine Zeiten, aber das läßt sich einfügen. Ich schau mir das Script mal an und stelle es dir dann hier rein. Die Stellen, an denen Änderungen vorgenommen werden müssen, markiere ich dann entsprechend. Gruß Timo Edit: Ich hab das Script, was bei uns läuft, mal entsprechend abgeändert und mit Kommentaren versehen: Was hier zwischen Hochkommata steht, sind die Kommentare, der Rest sind die ausgeführten Kommandos im Script. Das Script wäre jetzt z.B. für das Abmelden eines Users. Wenn du Hochfahren des PCs, Runterfahren, Anmeldungen von Usern und Abmeldungen protokollieren willst, dann mußt du dir 4 Scripts erstellen, sie entsprechenden benennen (z.B. pc-start.vbs, pc-shutdown.vbs, user-logon.vbs und user-logoff.vbs) und sie entweder im AD oder am PC in den Group Policies an den entsprechenden Stellen hinterlegen (Skripts für Starten/Herunterfahren und Skripts für Anmelden/Abmelden). Auf den entsprechenden PCs muß allerdings der Windows Scripting Host laufen, damit die VB-Scripts ausgeführt werden können. Du kannst als Pfad für die Log-Datei auch einen Netzwerkpfad wählen (macht das sammeln erheblich leichter). Hier solltest du dann aber mit UNCs arbeiten, weil Laufwerksfreigaben evtl. nicht sofort zur Verfügung stehen (z.B. "\\server01\freigabe01\logfile_" & computername &".txt"). Ansonsten muß am Script nur im vorletzten Aufruf die Aktion, die geschrieben wird, geändert werden. Beim Skript für Start/Herunterfahren solltest du username entfernen, weil er hier noch nicht wichtig ist. Den Chr(9) (ist ein Tab) solltest du aber drinlassen, damit es paßt, wenn du es in Excel auswerten willst. Die Zeile sollte dann folgendermaßen aussehen: LogWrite.WriteLine now & Chr(9) & Chr(9) & "start" Wenn du die Log-Dateien später zusammenführen willst, solltest du auch den computernamen noch ins Log schreiben. (z.B. LogWrite.WriteLine now & Chr(9) & computername & Chr(9) & username & Chr(9) & "logoff") Gruß Timo

Welches OS ist denn auf dem TS? Bei 2000 kann man, soweit ich weiß, keine Passwörter mit übergeben. Das blockt das OS schon ab.

Hm. Um welche Werte geht es dir denn generell? Nur die Laufzeit der PCs bzw. der Nutzeranmeldungen oder auch laufende Prozesse, Prozessorauslastung, Speicher oder ähnliches? Wenn es nur um die Laufzeiten geht, würde ich ein VB-Script als Start-Script vorschlagen, mit dem du die jeweiligen Daten (PC-Name, Zeitpunkt von Start und Runterfahren oder Anmeldung und Abmeldung) in eine Datei schreiben läßt. Wenn du die mit Tabs trennst, kannst du das dann in Excel einlesen. Da es sich aber wahrscheinlich um recht viele PCs handeln wird, könnte das Auswerten dann etwas Arbeit werden. :)

Danke für die Antworten. Die 150 User wären bestimmt ein nettes Experiment gewesen, aber da hätte ich mich dann rausgehalten. :) Dann werde ich mal schauen, daß ich die VM-Ware durchbringe.

Es werden schon mehrere Server bleiben. Derzeit sind es ja 15 mit je bis zu 50 bis 60 Kunden und die werden wir nicht alle auf eine Maschine packen. ;) Falls VM-Ware eingesetzt wird, werden wir jeweils etwa 3 oder 4 Server auf eine Maschine packen. Ohne Ausfallsicherheit würde ich das nicht machen. Ist halt eine Entscheidung von oben, die wir von der Technik jetzt irgendwie hinbekommen müssen. Gruß Timo

Hallöchen, ich hab da mal wieder ne Frage (geht eher um Erfahrungswerte :) ) Bei uns kam jetzt eine Diskussion auf, die Serveranzahl zu verringern, indem unsere (bisher 15) Terminalserver auf stärkere Server umgestellt werden und da dann mehr Kunden draufzulassen oder VM-Ware einzusetzen, um die Serveranzahl zu reduzieren. Zur Zeit haben wir TX-150 von Siemens (S1 und S2 mit 2 Xeon-Prozessoren, keine Dual Core) im Einsatz mit je 3GB RAM. Auf den Servern tummeln sich zu mittagszeiten so um die 50 bis 60 User. Geplant ist eine Umstellung auf RX-300 und da sollen dann entweder mehrere Terminalserver unter VM-Ware laufen oder aber ein Terminalserver auf dem dann bis zu 150 Kunden zugelassen werden sollen. Da wir jetzt schon teilweise unerklärliche Hänger (manchmal dauert es mehrere Sekunden, bis der Server auf irgendwas reagiert) und Druckprobleme haben (manchmal, wenn auch selten, kommen Ausdrucke auf den Druckern anderer Kunden raus), hab ich ein wenig Bauchschmerzen mit 150 Usern auf einem TS. Außerdem müßte hier dann auf Windows 2000 Advanced erweitert werden (2003 kommt derzeit wegen dem unkontrollierbaren Lizenzmodell von MS für uns nicht in Frage), weil da die 4GB, die Windows Server verwalten kann, nicht ausreichen. Bei VM-Ware bin ich mir nicht so sicher, weil ich da nicht weiß, wie es sich im Einsatz von Terminalservern verhält (Performance, Zuteilung von Arbeitsspeicher und Prozessorleistung etc.). Ist eines der beiden Systeme oder etwas ähnliches schon bei jemandem hier im Einsatz, der dazu ein paar Erfahrungswerte hat? Gesucht hatte ich schonmal, aber leider nichts brauchbares gefunden. Danke schonmal für alle Antworten. Gruß Timo

Hallöchen, selbes Problem hatten wir bei einem Kunden, der auf unseren Terminalservern arbeitet. Wäre der Treiber nicht vorhanden, käme in der Ereignisanzeige eine Meldung, daß der Treiber nicht bekannt ist und der Drucker nicht eingerichtet wurde (kann man dann entweder durch Installation des Treibers oder Treibermapping beheben). Das war hier allerdings nicht der Fall. Telefonisch war das ganze nicht zu lösen. 2 PCs gleich eingerichtet, gleicher Drucker, Druckertreiber bei uns gemappt: Bei einem geht's, beim anderen nicht. Da mir auch nichts weiter eingefallen ist und ich nichts finden konnte, hab ich mir das vor Ort angeschaut und nach einiger Suche auch den kleinen, aber feinen Unterschied gefunden: Bei dem PC, auf dem es funktionierte, war der Drucker als Netzwerkdrucker (also nicht als TCP/IP-Drucker!) angelegt. Bei dem anderen PC war derselbe Drucker, mit demselben Namen, als TCP/IP-Drucker angelegt (mir ist einfach der Zusatz "an <Printserver>" nicht aufgefallen). Nachdem wir den Drucker hier auch als Netzwerkdrucker eingerichtet hatten, hat es funktioniert. Ausführlichere Tests hier bei mir haben dann ergeben, daß der RDP-Client TCP/IP-Drucker scheinbar ignoriert (egal ob freigegeben oder nicht, ob mit IP-Adresse oder DNS-Namen angelegt). Was ich dann bei weiteren Suchen gefunden habe, war folgendes Dokument, was darüber einigen Aufschluß gibt: http://download.microsoft.com/download/6/a/b/6abeacd8-ee27-417a-ba1c-36cbedbaeb2e/Fragen_und_Antworten_zum_Webcast_09062005.pdf Zum Thema Drucker und RDP-Client steht in etwa drin: Drucker, deren Port nicht mit COM, LPT oder USB beginnt, werden nicht über den RDP-Client angelegt. Lösungsmöglichkeit wäre hier, den vorgeschlagenen Port des TCP/IP-Druckers (wenn es einer ist), beim Anlegen von IP_blabla in USB_IP_blabla umzubenennen. Wenn es ein Multifunktionsdrucker mit eigenem Port (DOT4 z.B.) ist, dann müßte man den Drucker (laut MS) auf Port LPT1 umstellen, wobei man aber die Multifunktionsfunktionen (doofes Wort...) verlieren würde. Eine umfassendere Lösung wäre ein Registry-Eintrag unter HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RDPDR den DWORD-Wert FilterQueueType mit dem Wert FFFFFFFF. Quelle: Printers That Use Ports That Do Not Begin With COM, LPT, or USB Are Not Redirected in a Remote Desktop or Terminal Services Session Ich hoffe, das hilft einigen, die sich mit diesen Problemen rumschlagen müssen. Ich bin froh, daß ich zu dem Thema endlich was gefunden habe :) Edit: Ihr habt nen ganz schön pingeligen Filter (zensiert b.l.o.e.d, aber nicht doof) :) Gruß Timo

Hallöchen, ich hab da mal wieder ein Problemchen und hoffe, irgendjemand weiß eine Lösung dazu: Erstmal ein wenig dazu, wie es aussieht: Wir testen gerade eine SonicWall für die Spam-Filterung und Virenscan eingehender und ausgehender Mails. Funktioniert inzwischen soweit auch ganz ordentlich. Die eingehenden Mails laufen auf unseren Exchange, bis auf ein paar Ausnahmen und hier liegt der Hund begraben: Wenn diese Ausnahmen (Mails an unser Ticketsystem für den Support auf Linux) nicht im AD auf dem Exchange stehen, dann schlägt der DHA-Schutz (Directory Harvest Attacks) der SonicWall zu und parkt die Mails alle im Junk-Ordner. In der SonicWall haben wir es inzwischen aufgegeben eine Möglichkeit zu suchen die Adressen in eine Whitelist einzutragen. Die Möglichkeit, die sich in SonicWall bietet wird stündlich überschrieben, wenn das AD vom Exchange synchronisiert wird (ich sag jetzt nicht, wie ich das finde ;) ) Wir können diese Adressen zwar ins AD auf dem Exchange eintragen und dann gehen Mails von außen auch in unser Ticketsystem rein ohne daß wir sie erst freigeben müssen, aber dann ist es nicht mehr möglich intern Mails an das Ticketsystem zu schreiben, da der Exchange die internen Mails dann dem User zustellt, der die Mail-Adresse zugewiesen bekam. Ich habe schon im Board und in Google gesucht und auch auf dem Exchange vergeblich eine Einstellung gesucht mit der ich das hinbekomme, was ich vorhabe. Dazu jetzt die Frage: Ist es bei Exchange2003 möglich eine Mail-Adresse oder von mir aus auch alle Mails an einen bestimmten Benutzer an eine bestimmte IP umzuleiten? Also etwas ähnliches wie die Transport-Funktion von Postfix. Ich habe es schon über einen Connector versucht, aber da ist es nicht möglich eine SMTP-Adresse anzugeben. Da geht nur eine ganze SMTP-Domäne, was aber dann wieder nicht greift bzw. zu viel des Guten wäre. Ich hoffe ich konnte das Problem halbwegs verständlich rüberbringen und es gibt jemand, der eine Idee dazu hat. Danke und Gruß Timo

Hi Roi, selbes Problem hatte ich gerade auf unserem Terminalserver. Arbeitsplatz und Systemsteuerung ließen sich nicht mehr öffnen. Ein erneutes durchbrechen der Berechtigungen in der Registry (ohne Änderungen) und danach erneutes Einschalten der Vererbung auf HKEY_LOCAL_MACHINE (und anschließender Neustart) hat hier geholfen. Ich nehme an, daß es da etwas in der Zuordnung der Anwendungen (wahrscheinlich bei den Rechten), verworfen hat. Aus welchem Grund auch immer. Ich glaube zwar, daß du das Problem inzwischen gelöst hast (auf die eine oder andere Weise ;) ), aber vielleicht hilft es ja einem anderen mit ähnlichem Problem. Gruß Timo

Hi, Operator hatte mir mal, in einem anderen Thread, ein kleines VB-Script zukommen lassen. Ich hab es ein wenig angepaßt, vielleicht hilft dir das ja. Wenn du es als Logon-Script verwendest, dann werden der Username und der Clientname, von dem die Anmeldung kommt, in eine Datei geschrieben. Grüße Timo

Das Event Log gibt leider nichts aussagekräftiges her. Allerdings weiß ich auch nicht, wie die Terminalserver damals installiert wurden, weil ich da noch nicht in der Firma war. Ich denke, ich werde mir wohl einfach mal die Arbeit machen müssen und alle neu installieren. Noch was, was ich oben vergessen hatte zu erwähnen: Einen neuen Terminalserver aufzusetzen bestand bisher darin, die Spiegelplatte eines bestehenden Servers rauszuziehen, den aus der Domäne zu nehmen, ihn umzubenennen und eine andere IP-Adresse zu verpassen und ihn wieder in die Domäne aufzunehmen. Geht zwar schnell, aber sonderlich begeistert war ich davon nie so wirklich. Ich habe so langsam das Gefühl, daß einige Probleme daher kommen.

Hallöchen, ich hab da ein Problem mit der Terminaldiensteverwaltung. Erst mal was zum Aufbau der Terminalserver: Der Domänencontroller und die Terminalserver (zur Zeit 11) sind Windows 2000 Server mit SP4. Die Verteilung der User erfolgt über ein Load Balancing unter Linux (ipvsadm). Die User haben sehr eingeschränkte Rechte. Im Grunde können sie nur die Programme auf ihrem Desktop ausführen und sich an- und abmelden. Pro Terminalserver sind täglich bis zu 50 (gelegentlich auch bis zu 60) User gleichzeitig angemeldet. Nun zu dem Problem, das gelegentlich auftritt (bei allen Terminalservern mal, aber selten bei mehreren gleichzeitig): Die Überwachung (perfmon / Prozessor, Speicher, Sitzungen), schreibt keine Daten mehr. Das ist in der Regel das erste Indiz, daß etwas nicht stimmt. Wenn man dann versucht in die Terminaldiensteverwaltung zu gehen, zeigt er den Terminalserver mit Fragezeichen an (also als würde er die Informationen laden), aber es tut sich dann nichts weiter. Das Programm läßt sich wieder normal schließen, hängt sich also nicht auf. Erst nach einem Neustart, bei dem dann gelegentlich mal bis zu 150 und mehr angemeldete Sitzungen angezeigt werden (je nachdem, wie früh er vom Netz genommen wird), geht es wieder. Die Sitzungen sind dann Leichen, die wohl nicht korrekt abgemeldet wurden, als die Terminaldiensteverwaltung gegen die Wand gelaufen ist. Hat jemand eine Idee, woran das liegen könnte? Grüße Timo