Jump to content

LLZwerg

Members
  • Gesamte Inhalte

    35
  • Registriert seit

  • Letzter Besuch

Über LLZwerg

  • Geburtstag 04.07.1975

Profile Fields

  • Member Title
    Newbie

Fortschritt von LLZwerg

Enthusiast

Enthusiast (6/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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. :)
  14. 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
  15. 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.
×
×
  • Neu erstellen...