olc

Hi, ein neuer Thread zu dem Thema entbindet Dich nicht davon, Deine Fragen bzw. Deine Umgebung etwas genauer und verständlicher zu beschreiben, denn sonst hättest Du hier vielleicht schon eine Antwort auf diese Frage bekommen :wink2: : https://www.mcseboard.de/windows-forum-ms-backoffice-31/dfs-ntfs-berechtigungen-spinnen-142280.html Viele Grüße olc

Ok, ist nicht Youtube, geht aber in die gleiche Richtung. :D The Leader of China - Gutti2003 - MyVideo Gruß olc

Hi, alternativ zum Umbenennen einer Domäne könntest Du auch eine zwei Phasen Migration durchführen: Erst eine Domäne in eine temporäre Domäne migrieren, dann die Vertrauensstellung der alten Domäne zur temporären Domäne kappen, um danach mittels neuem Trust zwischen der temporären Domäne und der Zieldomäne die Objekte in die Zieldomäne zu migrieren. Ggf. kann hier die SID History problematisch sein, müßte man noch einmal im Detail betrachten. Ob es den Aufwand wert ist, mußt Du selbst entscheiden. ;) Viele Grüße olc

Hi Flipshot, einmal losgelöst von den Problemen, die Du mit FRS hattest, ist die ROBOCOPY Variante sicher nicht die eleganteste Lösung. Unter Umständen macht hier ein anderes Konzept Sinn, bei dem Du nicht mittels Scripts, sondern einer professionellen Lösung die Daten replizierst. Zu ROBOCOPY: Standardmäßig werden nur neue oder geänderte Dateien kopiert, das ist einer der Vorteile von ROBOCOPY. Verwendest Du dann noch den Schalter "/MIR" für Mirror, werden die Daten immer 1:1 von der Quelle auf das Ziel gespiegelt, also auch gelöschte Dateien entfernt. ROBOCOPY ist jedoch nicht bidirektional - es werden Daten immer nur von A nach B kopiert, niemals in beide Richtungen gleichzeitig. Viele Grüße olc

Hi Christian, vielen Dank für Deine Rückmeldung. Schön, daß es geklappt hat. :) Viele Grüße olc

Hi, diese Variablen würde ich eher nicht anpassen - denn sie ändern nicht nur den Standard-Pfad der CMD, sondern auch die angegebenen Pfade in Bezug auf das Profil / die Pathes. ;) Schau einmal unter Command Processor\AutoRun: Core Services --> den Schlüssel "AutoRun" kannst Du auch unterhalb von "HKCU\SOFTWARE\Microsoft\Command Processor" anlegen und etwa den Wert "cd C:\" zuweisen. Vielleicht gibt der folgende Link ja ein paar Anregungen: Add Command Prompt Here Shortcut to Windows Explorer Viele Grüße olc

Hi, Ok, die Einstellungen kommen also zumindest laut RSOP direkt von der Default Domain Policy. Ok, das ist doch einmal ein Ansatz. Ich würde also (wie teilweise oben schon erwähnt) zwei Dinge probieren: 1. Eine neue Policy anlegen (etwa auch Domain Controller OU Ebene) und dort eine Sicherheitseinstellung vornehmen, etwa eine von Dir genannte Überwachungsrichtlinie - keine anderen Einstellungen. Dann solltest Du in der GPMC die Priorität dieser GPO auf 1 stellen, also höchste Priorität. Greift diese Einstellung nach einem GPUPDATE /FORCE auf den DCs? Ggf. laß den Einstellungen ein wenig Zeit for dem GPUPDATE und RSOP, damit diese ggf. repliziert werden können. 2. Greifen diese Einstellungen nicht würde ich persönlich wie angesprochen die lokale Sicherheitsdatenbank + Logs löschen, die scecli.dll neu registrieren und die DCs nacheinander neu starten. Ggf. solltest Du vorher prüfen, ob in der lokalen Sicherheitsrichtlinie Einstellungen vorgenommen wurden, da diese beim Löschen der *.sdb + *.edb Dateien verloren gehen. Die anderen Einstellungen sollten durch die GPOs wieder angewendet werden. Es macht vielleicht Sinn einen DC nach dem anderen zu machen um zu prüfen, ob nach den Aktionen überhaupt noch Sicherheitseinstellungen geschrieben werden. Wenn gar keine Einstellungen mehr ankommen, dann solltest Du die anderen DCs vielleicht nicht anfassen. Abwegungsfrage. ;) Viele Grüße olc

Hi, ich habe es gerade einmal getestet: Ich kann die Datei problemlos herunterladen als auch speichern, öffnen und ggf. drucken. Windows Vista SP1, Firefox 3.0. Viele Grüße olc

Hi Langer, ja, das funktioniert. Du hast etwa bei NET USE den Parameter "/USER": NET USE X: \\server\share /USER:MASCHINE\User Kennwort Aber wie oben schon kurz angesprochen ist das natürlich meist keine saubere Lösung: Wenn alle Benutzer den gleichen Ziel-Account nutzen, kann man eventuelle Schadenverursacher nicht eingrenzen. Viele Grüße olc

Hi, vielleicht kannst Du das Problem und die Umgebung ja noch einmal etwas genauer beschrieben. Mit den derzeitigen Angaben kommt man nicht wirklich weiter. ;) Viele Grüße olc

Hi Christian, ich habe gerade kein XP / 2003 System vor mir und kann es daher nicht heraus suchen - aber Du könntest prüfen, ob die Einstellung auf Deinen Systemen greift, wenn Du sie über eine GPO (ggf. lokale Policy) setzt. Falls ja, durchsuchst Du einfach die ADM-Dateien im %systemroot%\inf Verzeichnis nach der Zeichenfolge "Shutdown Event Tracker". Dort findest Du die GPO Einstellungen und damit auch den dazugehörigen Registry Schlüssel. Ggf. müßte der Pfad noch angepaßt werden, damit er nicht auf die "Policies" zeigt, sondern auf den "normalen" Zweig. In diesem Zusammenhang kannst Du vielleicht auch noch einmal prüfen, ob die Einstellung nicht vielleicht über eine Policy gesetzt wird - ggf. überschreibt diese Einstellung Deine manuellen Änderungen. In diesem Fall würde übrigens auch die Einstellung einer lokalen GPO überschrieben werden. Also ggf. vor den anderen Tests prüfen, etwa mittels RSOP.MSC. Viele Grüße olc

Hi, Na ja, nicht wirklich. ;) Wurden in der Zwischenzeit die Password Policies wieder geändert? Im Screenshot oben wurden 50 Tage minimales Kennwortalter angegeben. In dem Export der *.inf Datei steht der Wert auf 56. Hier war zumindest nichts angehangen. Aber die Daten wären auch wahrschienlich nicht die korrekten - wir meinten nicht die Policy selbst, sondern einen RSOP Report, also die Group Policy Results ganz unten in der GPMC, siehe Resultant set of policy overview for GPMC: Group Policy . Du mußt das hier aber auch nicht posten - Du sollst im Grunde nur prüfen, von welcher Policy die Einstellungen geschrieben werden. Dies findest Du rechts neben der entsprechenden Einstellung in diesem besagten GPMC Report. Ja, Du kannst damit etwas kaputt machen. ;) Also bitte nicht manuell anpassen. Die Änderungen hast Du wie oben beschrieben auch in den Sicherheitseinstellungen vorgenommen, also etwa die Anmelderechte (log on locally) geändert o.ä.? Wenn die Änderungen von Test-Sicherheitseinstellungen wirklich greifen, ist das unnötig. Die Datenbank löschen und wieder neu anlegen könnte jedoch ggf. trotzdem Sinn machen. Viele Grüße olc

Hi, der Fehler wird Dir in Zeile 46 angegeben. Hast Du Dir die Zeile denn einmal angeschaut? set objuser = GetObject("LDAP:// CN="& Nachname &"\, "& Vorname,OU=Benutzer,DC=kaputt,DC=zz") So wie ich das sehe fehlt hinter dem Vornamen ein &". Viele Grüße olc

Hi, das ist genau der Punkt: Du mußt die Site Coverage einschalten - obwohl dies standardmäßig der Fall sein sollte. Dann werden sich jedoch ggf. auch andere DCs dort registrieren - je nach EInstellung. Das kannst Du jedoch über Registry oder GPO steuern. Meines Erachtens übrigens genauso wie "Least Expensive Target Selection" - diese sollte ebenfalls standardmäßig aktiv sein. Aber da kann ich mich auch irren. Trotzdem die Frage: Kann es sein, daß die Einstellungen manuell geändert wurden? Viele Grüße olc

Hi, die Frage ist, was Du genau erreichen möchtest. Sollen alle Benutzer mit gleichen Rechten auf die Freiagabe schreiben dürfen, dann reicht auch ein Benutzer auf dem Zielsystem, mit dem dann die Laufwerke gemappt werden. Ist halt eine Sicherheitsfrage. ADAM / AD LDS bringt Dir in dieser Konstellation wahrscheinlich eher weniger, da Du zumindest mit normalen Windows Freigaben die Benutzer nicht so einfach gegen die ADAM Instanz authentifizieren kannst. Dazu brauchst Du beispielsweise eine LDAP Applikation oder die Authentifizierung muß in die "andere Richtung" laufen, was Du ja nicht möchtest (weil es ja auch keinen Sinn machen würde, von daher korrekt). Ist FTP o.ä. eine Option? Freigaben in einer DMZ anzubieten ist ja grundsätzlich auch nicht so gut, vielleicht gäbe es Alternativen? Viele Grüße olc

Hi, ist zufällig die Option "bridge all site links" deaktiviert, siehe The Storage Team at Microsoft - File Cabinet Blog : New for Windows Server 2003 SP1: the ability to turn off Bridge All Site Links without breaking DFS site costing ? Die DCs sind ebenfalls den korrekten Sites zugeordnet? Viele Grüße olc

Hi, hast Du einmal versucht dem Benutzer testweise die Berechtigung explizit auf die Ressource zu gewähren? Funktioniert der Zugriff dann? Viele Grüße olc

Off-Topic: Ja, da hast Du Recht. Aber zu meiner Entschuldigung sei gesagt, daß ich erst später in den Thread eingestiegen bin und auch diesen Punkt in dem ersten Beitrag von mir aufgenommen hatte. :) Ist manchmal erschreckend, wie viel zwischendrin auf der Strecke bleibt, was hätte die Lösung sein können. ;) Aber in diesem Fall denke ich nicht, daß das der Fall ist. Schließlich greifen die Policies ja "auf den Clients", was "auf den DCs" bedeutet. Viele Grüße olc

Hi, Ok, um zu verifizieren, aus welcher Policy die DCs die auf Ihnen aktive Kennwortrichtlinie bekommen, ziehe bitte trotzdem noch einen GPMC HTML Report und schaue, ob die Settings von der Default Domain Policy kommen oder einer anderen. Bitte für alle drei DCs prüfen. Im SYSVOL scheinen ja die korrekten Policies zu liegen, sonst würden die Benutzer nicht die korrekten Richtlinien bekommen. Vielleicht kannst Du das ja noch einmal in der GptTmpl.inf der Default Domain Policy ( {31B...} prüfen (auf allen drei DCs). Ja, das wissen wir jetzt. Damit ist das Problem zumindest eingegrenzt. Ich würde also vorschlagen sich auf den PDC zu konzentrieren, denn der schreibt die Einträge in den NC Head. Hast Du Dich mit LDP o.ä. beim Auslesen des NC Heads auf den PDC verbunden oder einen anderen DC? Versuch es bitte einmal konkret mit dem PDC. Daß die Datenbank strukturell in Ordnung ist sagt nichts darüber aus, ob sie auch inhaltlich paßt. Ich würde daher wie beschrieben (sollten nicht manuell Einstellungen in der lokalen Gruppenrichtlinie des PDCs eingestellt worden sein) die im Link genannten Dateien zumindest auf dem PDC trotzdem einmal löschen und den PDC einmal neu starten. Du hast oben geschrieben, daß keine Meldungen im Ereignisprotokoll zu finden waren - wenn im Anwendungs-Ereignisprotokoll auch keine Informational Meldungen mit Quelle SCECLI zu finden sind, dann solltest Du wie beschrieben vor dem Neustart auch einmal die "scecli.dll" neu registrieren. [EDIT] Achso - die Frage, ob andere Einstellungen in den Security Settings der Default Domain Policy testweise greifen, wäre auch noch offen. ;) [/EDIT] Viele Grüße olc

Hi, einmal abgesehen von den RSOP "Problemen" (BTW: Ich meinte den GPMC HTML Report, aber das tut nichts zur Sache): Hast Du die anderen Punkte aus https://www.mcseboard.de/post23-872667.html ebenfalls geprüft? D.h. es ist keine Verweigerung eingerichtet und auch die Sicherheitsberechtigungen auf der Default Domain Policy nicht verändert worden, ja? Viele Grüße olc

Hi, ich habe mir die Geschichte noch einmal ein wenig angeschaut, weil mir das keine Ruhe ließ: In der oben schon einmal angesprochenen WMI-Klasse "Win32_OperatingSystem" gibt es die Methoden "Reboot" und "Shutdown", aber bei Methoden kann man natürlich keinen Status auslesen (es sei denn, man führt diese gerade aus). Daher habe ich ein "shutdown -t 300 -r" einmal mit dem ProcMon mitgeschnitten - es werden dabei natürlich so einige Registry Keys gelesen und geschrieben, so etwa auch der "ReasonCode" für das Herunterfahren bzw. Reboot: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability\shutdown. Wenn man nun nach diesem "ReasonCode auf MSDN sucht, landet man hier: System Shutdown Reason Codes (Windows) . Die beiden Links oben sind dann interessant, denn es gibt offensichtlich die Funktion "InitiateSystemShutdownEx", die auch zurück gibt, ob das System heruntergefahren oder neugestartet wird: InitiateSystemShutdownEx Function (Windows) . Ich denke, damit kannst Du etwas anfangen. Nichtsdestotrotz noch einmal die Bestätigung der letzten Posts: Wenn Du etwas genauer sagen könntest, was Du eigentlich erreichen willst, hilft das vielleicht weiter. Viele Grüße olc

Hi, muß es VBScript sein oder darf es auch die PowerShell sein? PowerShell: PS C:\>get-wmiobject Win32_LogicalDisk -credential DOMAIN\User -computer computername Wenn Du es per VBScript machen möchtest, bleibt die WMI-Klasse dieselbe. ;) [EDIT] VBScript (lokal): vb@rchiv · Tipps & Tricks · Alle logischen Laufwerke per WMI ermitteln [/EDIT] Viele Grüße olc

Hi, in dem verlinkten HowTo findest Du auch eine kurze Beschreibung von SC.EXE. Das ist auch auf dem 2008 Core dabei, wenn ich mich nicht irre. :) Viele Grüße olc

Off-Topic: Schön, Dir auch einmal helfen zu können. :) ...jederzeit gern wieder. ;) Viele Grüße olc

Hi grizzly999, doch, tut er. :) Du mußt dazu jedoch beim Verbinden auf die entsprechende Domäne im Dialog der MMC (beispielsweise AD User & Computer) "Connect to Domain" den Haken bei "Save this domain setting for the current console" auswählen. Dann die MMC mit mehreren AD U&C Snapins abspeichern und fertig. :) Siehe auch Manage a different domain: Active Directory . Viele Grüße olc