expirius

Sind das die einzigen Nutzer, welche in einer Gruppe sind, die über lokale adminrechte verfügen? Irgendetwas muss diese Nutzer von anderen unterscheiden, gerade wenn sie auch neu angelegt worden sind. Wenn es so ist, das sie die einzigen mit einer Mitgliedschaft mit lokalen adminrechten sind, ist es einfach... die lokalen adminrechte haben andere lokale policies als die rechte des nutzers, und er versucht die lokale policiy zu überschrieben mit der Nutzer und computer policy. die computerpolicy kann hierbei außer acht gelassen werden denke ich jedenfalls... Ich gehe davon aus, das eine Einstellung, die der nutzer bei der Anmeldung zugewiesen bekommt mit einer Einstellung der lokalen sicherheitsrichtlinie kollidiert. Festzustellen ist das auch ganz einfach, eine OU erstellen, und dieser KEINE GPO zuweisen und auch die Vererbung deaktivieren (GPMC) dann meldet sich der nutzer maximal mit der default domain policy an und wenn es dann schnell geht, haben diene Rechner ein Problem mit der Verbindung der Nutzerpolicy und der lokalen sicherheitsrichtlinie Nutzer mit (lokalen) adminrechten. Das würde zumindest das Problem "eingrenzen" und dann muss man feststellen, was genau zu dem Problem führt.

Ich verstehe die Frage nicht ganz.... Also Nutzer mit IP-Phone verknüpfen geht leicht... aber PC? Weil Nutzer wäre im Callmanager einzurichten... der kann sich dann an einem Telefon "anmelden" und seine Telefonnummer wird auf dieses Telefon "geroutet" und im Outlook adressbuch steht immer die gleich gültige Nummer für den Nutzer....

Also unsere Nutzerprofile sind auch Servergespeichter und mit GPO´s auf 30 MB begrenzt, excludes des zu speichernden Profilordner wäre dein erster Ansatz, das kannst du in den GPO´s festlegen. Wenn du die Begrenzung mit den entsprechenden excludes hineinnimmst, dann kann sich der Nutzer, wenn du es festlegst nicht mehr abmelden, bis sein Profil unter der Grenze von 30 MB liegt. 1: Eigene Dateien aufs Homelaufwerk umleite, die liegen sonst mit im Profil.... 2: Desktop... hier sollten eigentlich nur Verknüpfungen liegen und Daten die ich als Nutzer temporär in dieser Sitzung benutzen muss.... alles andere auf Home bzw. Gruppenlaufwerken... 3: Das mit der Begrenzung hätte von anfang an laufen sollen, da es ein ganz klarer Erfahrungswert ist, je mehr Freiheiten du den Nutzern lässt, desto mehr Freiheiten nehmen sie sich... in diesem Fall heißt das, es gibt kein Profil, das ein Nutzer nicht vollmüllen kann... Wenn du ihm die Möglichkeit lässt, sein Profil auf 1GB und größer anwachsen zu lassen, dann wird der Nutzer diesen Speicherplatz auch nutzen ^^

Naja die Nutzer authentifizieren sich ja mit ihren alten Accounts an der alten Domäne. also ist es net zu unsicher... und dieses Script soll nichts unsicherer machen, da es beim script genau gleich laufen würde, der nutzer gibt sein altes PW ein und authentifiziert sich damit, dann gibt er sein neues ein und es wird geändert, das kann er auch über die strg+alt+entf Variante machen. Die Vorgesetzten geben es so vor, das es keine Vertrauensstellung gibt... Die anderen Varianten habe ich so ziemlich alle durch.... Also gibt es nur noch "turnschuhadmin" oder dieses Script...

Also wenn es Windows XP ist.... gib ihm am Telefon das lokale adminpasswort... nein kein aufschrei ^^ (später natürlich ändern!) Dann soll er die XP Firewall oder die installierte desktopfirewall) abschalten, damit der Rechner wieder pingbar ist und du anschließen auch auf die Remotedesktopkonsole kannst... dann rejoinen lokales admin pw ändern und gut is.... Wenn noch eine andere Firwall dazwischen ist, entsprechend die Kommunikation zulassen.... Das ist zumindest die einfachste Möglichkeit, bei der der Schreibtisch nicht verlassen werden muss ;)

Ich würde es per Script machen, was brauche ich denn, um dem Nutzer seine für ihn wichtigen Laufwerke zu verbinden? Seine Gruppenmitgliedschaften.... die kann ich ohne Probs per LDAP auslesen. Und anhand der Gruppenmitgliedschaften weise ich die entsprechenden Nezlaufwerke zu... Ich sage dem script also, wenn user in Gruppe a mitglied ist, dan weise ihm Netzlaufwerk a als Buchstaben Y: zu, wenn Y: bereits belegt, dann y: -1 (asccii: 90(Z) -1 = 89(Y)) und dann könpft es sich die nächste mitgliedschaft vor. Dieses Tool ist allerdings mächtig und entsprechen schwer in der Erstellung, aber es wäre dynamisch, endlos skalierbar... naja gut Alphabet gibt die Grenze ^^ und es könnte bzw. es kann auch Drucker verbinden bzw. jede andere Ressource, die man haben will. Man legt dann nur noch die Ressourcen, in die gleiche Ebene der OU Gruppen und schon läufts... Allerdings wären da mal wieder einige Nächte am VBscript notwendig... was vermutlich zu einer persöhnlichen Beziehung mit dem Pizzalieferanten führen würde ;) Aber so wäre es möglich.

Guten Morgen BoardUser, also, ich habe folgendes Problem: Meine Firma befindet sich in der Migrationsphase von Domäne a zu Domäne b. Die Clients sind bereits auf Domäne b umgestellt, der Datenzugriff findet aber noch auf fileserver der alten Domäne statt. Vertrauenstellungen existieren keine! (Sicherheit) Die Zugriffe auf die Daten werden mit Netzlaufwerken via script und der Benutzung der "alten" Nutzeraccounts aus Domäne a sichergestellt. Das läuft grundsätzlich auch ohne Probleme, es sei denn.... das Passwort des alten Nutzeraccounts ist abgelaufen.... PLs keine Kommentare von wegen setz das Häckchen "Nutzerpasswort läuft nicht ab".... findet nicht statt ^^ Ich möchte dem Nutzer auf seinem "neuen" homelaufwerk ein script zur Verfügung stellen, welches in etwa folgendes macht: Nutzereingabe: Geben sie den Nutzernamen der alten Domäne ein. Nutzereingabe: Geben sie ihr alte (abgelaufenes) passwort ein. Nutzereingabe: Geben sie ihr neues domänenpasswort ein. Nutzereingabe bestätigen sie durch erneute eingabe ihr neues passwort. in der Dos Konsole kann ich den Befehl net user verwenden mit anderen Worten NET USER /DOMAIN Nutzername "neuespasswort" In der gleichen Domain kein Problem.... Aus einer anderen Domain heraus geht das nicht. Dieses script müßte also das machen, was ich sonst über strg+alt+entf / Kennwort ändern mache. Dort gebe ich als fähiger Nutzer ein "DCHOSTNAME.FQDN\Nutzername" dann das alte passwort eingeben dann das neue und bestätigen.... Geht super... nur gibt es wie wir alle wissen nur sehr wenige fähige Nutzer... Der DCHostname muss eingegeben werden, das er sich sonst an irgendeinem DC der alten Domänen anmeldet, und da diese weltweit verteilt sind, kann es dazu kommen, das er sich einen DC aussucht, der weit weit weg ist und dadurch die Passwortänderung nicht an den DC repliziert hat, wenn der Nutzer versucht seine Netzlaufwerke wieder zu verbinden, in einer kleinen Domäne würde es reichen den FQDN namen der alten domäne voranzustellen. Meine Frage ist also folgende, ist es möglich diese Passwortänderung per script zu lösen? Also das was ein fähiger Nutzer über strg+alt+entf / kennwort ändern DCHostname.xxx.xxx.local\nutzername altes pw neues pw neues pw bestätigen einfach per script zu ändern. Das Problem ist einfach, das diese Situation noch lange anhalten wird und eine Menge Nutzer anrufen.... keine Netzlaufwerke mehr.... pw abgelaufen etc...