olc

Hi, die anderen Beiträge in diesem Thread hier zu Deinem Problem hast Du gelesen? Viele Grüße olc

N'Abend, Auf keinen Fall versuchen, die Dateien auf dem laufenden System zu überschreiben. ;) Du kannst einfach den Eventviewer normal öffnen, dann Rechtsklick auf die "Ereignisanzeige", danach "Öffnen" oder so ähnlich. Dann gibst Du den Pfad zu den *.evt Dateien des anderen Systems an. Viele Grüße olc

Guten Abend, Gern. :) Es sind schon einige Dienste - schau einmal in die Liste, die ich oben verlinkt habe. Dort siehst Du die standard MS-Dienste. Alle andere, also etwa AV-Scanner, andere Software solltest Du testweise deaktivieren. Steht ebenfalls in einem der oben verlinkten Artikel. ;) "DISABLE" ist der Befehl dafür. Du kopierst Dir die *.evt Dateien aus %SystemRoot%\System32\Config vom Fehlersystem auf Dein laufendes System und bindest die *.evt Dateien auf dem laufenden System in die Ereignisanzeige ein - dann kannst Du schauen, ob darin "interessante" Meldungen geloggt werden, die die Fehlerursache eingrenzen können. Ohne es böse zu meinen - aber hat vielleicht Deine "Optimierung" erst dafür gesorgt, daß das System jetzt nicht mehr läuft...? Viele Grüße olc

Ok, stimmt. Hast Recht - wenn man die Aussage vom Persilmann so liest, ist es eine andere (=nicht ganz korrekte) Aussage. Viele Grüße olc

:D :D :D Dann schau bei den Benutzern auf die Metadaten. ;) Jedoch sind die Client trotzdem relevant, ohne deren Vertrauensstellung kann sich auch kein Benutzer authentifizieren. Von daher würde ich beides anschauen. Aber es funktioniert ja wieder, von daher sind die weiteren Aktionen "nur noch" Ursachenforschung. Viele Grüße olc

Deine Ehrlichkeit in Ehren ;) - aber Du schriebst: Das ist genau der Punkt, den Persilmann nach meiner Auffassung meinte. Oder ich verstehe Euch beide falsch. :D Da Computerkennwörter nicht "ablaufen", würde mir jedoch keine andere Interpretation einfallen. ;) Viele Grüße olc

Hallo, sicherlich nicht so gedacht und nur eine Notlösung: Aber Du kannst das gesamte %SYSTEMROOT%\GroupPolicy Verzeichnis kopieren, das sollte ausreichend sein. Hardware ist dabei egal, aber ich würde es nur auf gleichen Betriebssystemen durchführen. Wie gesagt, ist nur eine "Notlösung" und wahrscheinlich auch nicht von MS supported. Viele Grüße olc

@Persilmann: Genau das hatte Stephan schon oben vermutet. ;) Viele Grüße olc

Hi, schau einmal in den folgenden Artikel, der Beschreibt die möglichen Recovery Console Aktionen: Description of the Windows XP Recovery Console for advanced users Für Dich ist DISABLE interessant - aber deaktiviere nur die Dienste, die nicht von Microsoft stammen. Siehe dazu auch: Microsoft Corporation Eventlogs liegen im Verzeichnis: %SystemRoot%\System32\Config Siehe dazu auch How to Delete Corrupt Event Viewer Log Files Andere RAID Treiber kannst Du per Diskette nachladen, sollte Dein Rechner ein Diskettenlaufwerk haben. Erst ab Vista geht es mit USB-Stick. Bei dem Thema: Ein Inplace Upgrade zum Beispiel auf Vista oder W7 könnte auch Erfolg haben. Aber ich vermute, das ist keine Option bei Dir, korrekt? Ganz ehrlich: Du steckst jetzt wahrscheinlich eine Menge Zeit in die Wiederherstellungsversuche und ich vermute, daß diese nicht von Erfolg gekrönt sein werden. LSASS-Fehler sind heftig. Vielleicht macht es also doch eher Sinn, die Neuinstallation anzugehen - letztendlich bist Du vielleicht schneller. Auch wenn es weh tut. :( Viele Grüße olc

Hi, die Autostarts der Benutzer sind nicht relevant, wenn der Fehler schon vor dem Login stattfindet. Du müßtest also die Starttypen der nicht-MS Dienste verändern. Das kannst Du in der Recovery Konsole erledigen, die die CD mitbringen sollte. Dort schaust Du nach nicht standardmäßig installierten Diensten und deaktivierst diese testweise einmal - notiere Dir am besten, welche Dienste mit welchen Starttypen Du bearbeitet hast. Wie sieht es mit den Eventlogs aus? Die kannst Du recht problemlos remote laden. Aber ich würde es in jedem Fall noch einmal mit einer Reparaturinstallation versuchen. Die LSASS-Fehler sind schwerwiegende Fehler, die meiner Erfahrung nach meist nicht mit ein, zwei Handgriffen behoben werden können. Viele Grüße olc

Hi, ok, verstehe. Ich dachte Du kommst zumindest eine Weile lang an das betroffene System. Dann wird es schwierig - Du könntest zwar die Registrierung des offline Systems laden und dort die Änderungen manuell durchführen, aber das ist eine Menge Arbeit, weil Autostarts an sehr vielen Stellen im System hängen. Hattest Du auch eine Reparaturinstallation des Systems probiert? Viele Grüße olc

Hi, Die sind nicht relevant in Bezug auf meine Frage ;), sondern Du müßtest Dir die Konten der betroffenen Clients anschauen. Aber Du mußt Dich beeilen, die Kennwörter ändern sich im Normalfall zyklisch (zumindest bei den Windows Systemen). Viele Grüße olc

Hi BlueMarlin und willkommen an Board, :) findest Du eventuell Einträge im Ereignisprotokoll (System und Applikation), die auf Fehler hinweisen? LSASS-Abstürze werden oft entweder durch Zusatzsoftware oder aber durch Viren / Trojaner etc. verursacht. Von daher würde ich in jedem Fall einmal einen Offline-Scan durchlaufen lassen, etwa mit Knoppicillin o.ä. Deaktiviere einmal alle nicht-Microsoft Autostarts und ggf. nicht-Microsoft Dienste (Du kannst z.B. Autoruns nutzen, wenn Du weißt, was Du tust, oder msconfig32.exe). Tritt das Problem danach immer noch auf? Viele Grüße olc

Hi, das ist insofern ärgerlich, daß wir zu Beginn explizit von FRS gesprochen haben und nicht von DFSR. Hättest Du früher erwähnt, daß die Daten per DFSR repliziert werden, dann hätten wir das Problem sofort lösen können. :wink2: Aber schön, daß Du letztendlich doch die "Lösung" gefunden hast. :) Zur DFSR Überwachung mit Boardmitteln findest Du zum Beispiel hier etwas: Windows Server How-To Guides: Grundlegende DFS-R Überwachung mit Hausmitteln - ServerHowTo.de Viele Grüße olc

Moin, Ich mag da jetzt Erbsenzähler sein, aber das ist nicht korrekt: Es ist ein Unterschied, ob die Einstellungen nicht ankommen oder ob sie - aus welchen Gründen auch immer - nach dem Anwenden wieder entfernt werden. Die Herangehensweise an das Problem ist je nach Fragestellung ein vollkommen anderes. Das ist das der Kern bei Problemen: Wenn man sofort wüßte, woran es liegt, dann wären es keine Probleme, sondern man hätte nur Lösungen. Von daher ist die Aussage meines Erachtens etwas fragwürdig. Genau, ich habe mehrere Vorschäge zur Herangehensweise gemacht - so Recht verstehe ich also nicht, worüber wir hier gerade sprechen bzw. warum Deine Antwort zumindest bei mir als "Gegenmeinung" rüber kommt. So wie ich das sehe, sind wir einer Meinung, es würde also keiner weiteren Zeilen bedürfen. Aber vielleicht verstehe ich das auch falsch. Wozu ich oben auch explizit auch zugestimmt habe. Aber eine Glaskugel haben wir hier alle leider nicht - daher sollte man auch andere Problemquellen nicht ausschließen. Falls Du doch eine hast, dann bitte eine kurze PN an mich. Ich komme da sicher gern drauf zurück. Korrekt, daher meine Hinweise auf die möglichen nächsten Aktionsschritte. Viele Grüße olc

Hi Norbert, nein, das muß nicht sein. Wie in meinem letzten Beitrag oben angemerkt, können Sie auch unter Umständen nach dem Anwenden wieder von einem "beliebigen" Prozess gelöscht werden. Daher der Vorschlag des ProcMon Traces - damit könnte man das zumindest ausschließen. Grundsätzlich gebe ich Dir aber Recht - am ehesten ist anzunehmen, daß die Schlüssel überhaupt nicht geschrieben werden. Vielleicht bringt also schon der oben erwähnte GPMC Group Policy Results Export etwas Licht ins Dunkel. Viele Grüße olc

Hi, auf dem DC scheinen also keine anderen Anfragen als LDAP, DNS und ICMP anzukommen. Das ist merkwürdig. Zwei Punkte: Schaue einmal in die Datei "netsetup.log", was dort zum Zeitpunkt des fehlschlagenden Domänenbeitritts auf dem Client geloggt wird. Zieh den Netzwerktrace noch einmal vom Client aus: Erst den Client neu starten, dann direkt den Trace starten, danach dann den Beitritt versuchen. Es sollte mehr Traffic zum DC gehen, als der, den Du im letzten Trace hattest. Viele Grüße olc

Hi, verwende lieber "icacls.exe", denn "cacls.exe" hatte einige "häßliche" Fehler, die im Extremfall die NTFS-Strukturen bei Änderungen zerstören konnten. Aber einmal ganz anders gefragt: Was genau möchtest Du eigentlich erreichen? Im Normalfall ist eine Änderung der Benutzerverzeichnis-ACLs nicht notwendig. Was genau ist also Dein Ziel? Viele Grüße olc

Hi, perfekt, vielen Dank für die Rückmeldung. :) Viele Grüße olc

N'Abend, Je nach eingesetztem Betriebssystem ist das nicht mehr so relevant - die "DNS devolution" löst das Thema meist recht gut. Dann wird die Einstellung entweder wieder überschrieben oder die Policies sind nicht korrekt am Client angekommen. Ich würde in dem Fall zwei Dinge prüfen: Sind die oben von Norbert genannten Schlüssel vorhanden, kurz / direkt nachdem Du ein GPUPDATE /FORCE durchführst? Überprüfe direkt nach dem GPUPDATE /FORCE einmal die genannten Schlüssel. Laß ein ProcMon Trace im Boot-Logging Modus mitlaufen und filtere danach den Export auf den Policy Zweig: Werden die oben genannten Schlüssel eventuell geschrieben und dann wieder gelöscht? Falls ja, von welchen Prozessen? Du hast im HKEY_LOCAL_MACHINE Registry Zweig geschaut, nicht im HKEY_CURRENT_USER, korrekt? Der von Norbert genannte Pfad ist der Registry Zweig, in dem im Normalfall standardmäßig Administrative Templates Policy Einstellungen landen. Wenn dort nichts drin steht, sind die Einstellungen nicht von der Policy geschrieben worden oder wurden danach wieder gelöscht. Daher also nicht "egal" ;) . Oben sagte der TO, daß ein GPRESULT die Einstellungen anzeigt: Prüfe das ganze bitte noch einmal per GPMC Group Policy Results HTML Report - sind die Werte dort korrekt im RSOP eingetragen? Viele Grüße olc

Guten Abend, Na ein Glück, dann habe ich ja zur Abwechslung auch mal etwas richtiges gesagt. ;) :p Ist sicherlich nicht in jedem Fall uneingeschränkt empfehlenswert, aber so weit es "niemals über GPOs zu steuern" würde ich nicht gehen. Kommt wie immer auf die Umgebung oder die konkrete Anforderung an. Das betrifft nicht nur die DNS-Suffixe, die sind nur ein Teil vom großen Ganzen. Letztendlich auch nachvollziehbar, schließlich sind DHCP-Client Optionen, feste Netzwerkkarteneinstellungen, GPO-Settings etc. unterschiedlich im System verankert. Auch DNS-Suffixe haben im Grunde nur ergänzenden Charakter zu den Kerneinstellungen für Netzwerkkarten. Ärgerlich ist meines Erachtens nur, daß IPCONFIG wie von Dir auch angemerkt nicht alle Einstellungen ausliest. Interessant wäre in dem Zusammenhang, ob die Daten per WMI direkt geliefert werden, das habe ich noch nie getestet. Zum Beispiel über den Namespace "Win32_NetworkAdapterConfiguration". Viele Grüße olc

Hi, mh - spontan habe ich erst einmal keine weitere Idee. Du könntest mittels DFS MMC Logging einmal prüfen, ob etwas brauchbares in den Logdateien zu finden ist. Wie sieht es in den Eventlogs des 2008er Server aus als auch den 2003ern? Sind Fehler zu finden oder Warnungen? Ansonsten könnte man noch einmal die DNS Struktur prüfen, vielleicht gibt es hier Probleme? Viele Grüße olc

Hi, sind die DCs auch synchron? Vielleicht gibt es damit Probleme - schau Dir einmal "repadmin /replsum" an und prüfe, ob die DCs korrekt replizieren. Viele Grüße olc

Hi, ich kann mich da irren, aber unter Umständen liegt das Problem darin, daß die Scripts bis XP / 2003 über "userinit.exe" aufgerufen werden. Damit ist "userinit.exe" für das Script als auch die Kindprozesse darunter (in dem Fall also Notepad) relevant. Wird das Script beendet und der "userinit.exe" Prozess danach geschlossen, zieht es den Kindprozess (Notepad) mit herunter. Es müßte also auch funktionieren, wenn Du nur C:\Windows\Notepad.exe ohne "Start" in die Batch Datei aufnimmst. Aber wie gesagt, ich bin mir da ohne einen kurzen Test nicht sicher. Anders gefragt: Was sind denn Deine Ursprungsprobleme bzw. was möchtest Du mit diesem Test bezwecken? Viele Grüße olc

Hi, über welche Betriebssysteme sprechen wir hier? Sind alle Ports auf der Verbindung in beide Richtungen freigegeben oder wird etwas geblockt? Ist der Wireshark Export tatsächlich alles, was da über die Leitung geht? Ich sehe da ausschließlich DNS und LDAP Traffic (und ICMP), da fehlt also einiges (etwa RPC, Kerberos etc.). Auf welcher Seite hast Du den Trace gezogen? Viele Grüße olc