olc

Hi, wie gesagt - sei mit dem Löschen _aller_ Einträge vorsichtig, das kann Probleme geben... Na ja, wie man es nimmt. Ein Spitzbube würde jetzt sagen, daß Ihr beim Design hättet besser planen sollen. :p Es kann Probleme mit den Tombstones geben, wenn man die Zonen auf DNS Server anderer Hersteller überträgt (etwa BIND o.ä.). Daher hat MS das sicherlich bewußt nicht standardmäßig aktiviert. Schau einmal in den folgenden Blog Eintrag, dieser Beschreibst das ganze meines Erachtens recht gut: DNS CONCEPTS Viele Grüße olc

Hi BaSe, der Scavenging wird meines Wissens nur angestoßen, wenn beim Erstellen des DNS-Eintrags das Scavenging schon aktiviert war (Server als auch Zone). Nur dann wird das entsprechende Tombstone Attribut auf dem Objekt geschrieben. DU müßtest also überlegen, ob es für Dich sinnvoll ist, die DNS Einträge manuell zu löschen - bei neuen Einträgen greift dann das Tombstone Attribut. Ich würde jedoch Abstand davon nehmen, einfach "alle Einträge" zu löschen - das kann schwerwiegende Konsequenzen für den Produktionsbetrieb nach sich ziehen. Bezüglich der Reverse DNS Zone: Das sollte so hinkommen, ich bin mir jedoch nicht 100% sicher. (In einer Testumgebung) Probieren geht über studieren. ;) Viele Grüße olc

Hi, zu Deiner Frage kann ich im Moment nicht viel beitragen - aber trotzdem eine Frage / Anmerkung: Welche Betriebssysteme nutzt Ihr in Eurer Umgebung? Sollte es XP und Vista sein, kannst Du Dein Vorhaben problemlos mit den Group Policy Preferences lösen. Ist vielleicht "eleganter" und wartbarer als Startscripts etc. Download details: Group Policy Preferences Overview Viele Grüße olc

Hi Karl, nein - wie Daim schon sagte, lassen sich die Einträge (bisher) nicht entfernen. Vielleicht diesbezüglich noch der Hinweis, daß die Einträge selbst kein Schutz vor doppelten GUIDs sind - aber vielleicht habe ich die Antwort auch nur falsch verstanden. Die GUIDs finden sich in den Metadaten jedes Naming Contexts / jeder AD-Partition, ggf. ab 2003 auf den Objekten und Attributen selbst. Sie stehen in den USN tables, wodurch prüfbar ist, wann ein DC zuletzt welche Daten repliziert hat (bzw. welche USN-Version auf einer Partition / einem Objekt / einem Attribut für diesen DC existiert und welche Daten dieser Ziel-DC damit bei einer Änderung anfordern muß). Die Metadaten lassen sich Stand heute nicht "säubern". Es ist also ein "Schönheitsfehler", den Du meines Wissens nicht beheben kannst - egal ob normaler DC oder GC. Viele Grüße olc

Hi Magda, ist das folgende PowerShell Script (ganz unten) vielleicht eine Option? https://www.mcseboard.de/windows-forum-allgemein-28/suche-tool-um-dateien-suchen-ersetzen-140133.html Viele Grüße olc

Hi, ok - also der 1517er Fehler ist in diesem Zusammenhang wahrscheinlich auch relevant. Aktiviere einmal wie oben angesprochen das erweiterte UserEnv Logging (Wert 3002) und schau einmal in das Log, ob Du weitere Hinweise findest. Zum Fehler Event ID 1517 solltest Du einmal UPHClean auf einem betroffenen Client installieren und es im Logging Modus inkl. Callstack laufen lassen. Dann solltest Du im Anwendungs-Eventlog Hinweise bekommen, welcher Prozess dort hinein greift. Unter Umständen löst das beide Probleme. Viele Grüße olc

Hi Piranha, klasse, vielen Dank für Deine Rückmeldung. :) Viele Grüße olc

Hi, Wird die Meldung auf dem verbliebenen DC geloggt oder wo? Was genau hast Du denn von dem aufgeführten Artikel Recovering missing FRS objects and FRS attributes in Active Directory ausgeführt? Scheinbar wurde beim Metadata Cleanup der SYSVOL FRS Container nicht um den fehlenden DC "erleichtert" - bist Du alle Schritte des METADATA CLEANUP korrekt durchgegangen? Welcher DC wird in dem Event bemängelt? Ist "CN=SERVER,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=home,DC=local" der alte oder der neue, nun noch existierende DC? Viele Grüße olc

Hi Ralf, in welcher Gruppe ist der Benutzer genau? In der Builtin AD Gruppe "Administratoren" oder in einer eigenens erstellten Gruppe? Steht der Terminal Server in derselben Domäne wie der Client, bei dem es funktioniert? In wie vielen Gruppen ist der Benutzer Mitglied? Zeigt Dir das GPRESULT bzw. ein "whoami" die Gruppenmitgliedschaft auf dem TS nicht an oder greift auf dem TS vielleicht einfach das Policy-Objekt nicht (etwa wegen falscher Verlinkung oder Loopback-Processing)? Viele Grüße olc

Hi Marcel, ITHome möchte Dir damit den guten Hinweis auf Watchguard Firewall / VPN Appliances geben. ;) Deine Frage ist den zur Verfügung stehenden Informationen schwer zu beantworten. Wie würdest Du die Frage "Ich möchte gern mobil sein, welches Auto empfehlt Ihr mir?" antworten? Je nach Anforderungen, preisliche Möglichkeiten etc. können die Empfehlungen unterschiedlich aussehen. Schau Dir doch einfach einmal die Palette von Netgear oder Linksys (kleinere Router), Open Source Lösungen wie IPCop oder größere und damit teurere Lösungen wie Watchguard, Astaro etc. an. Diese findest Du problemlos mit einer Suchmaschine Deiner Wahl. ;) [EDIT] ITHome war schneller... [/EDIT] Viele Grüße olc

Hi, einmal abgesehen davon, daß ich den Vorschlag gut finde, das gesamte Konzept zu überdenken... ;) : Ich habe es gerade mal auf meiner VISTA Kiste getestet - bei mir wird wie besprochen nur in einer elevated cmd das Security Eventlog angezeigt. Jedoch kann ich weder das System- noch das Security Eventlog mit dem Script sichern. Nicht einmal mit SYSTEM-Rechten. Auch das Entfernen der Impersonation half nichts. Die Methode ist jedoch auf jeden Fall korrekt, denn in der PowerShell funktioniert es für alle Logs problemlos: PS C:\> $security = Get-WMIObject -query "Select * from Win32_NTEventLogFile where LogFileName='Security'" PS C:\> $security.backupEventLog("d:\eventlogs\events\security.evtx") Da ich kein VBScript Spezi bin, kann ich mit der Ursache nicht dienen. Ich würde weiterhin auf irgendwelche Rechteprobleme tippen (unter Umständen wird auch die impersonation unter Vista / 2008 anders gehandhabt). Nimm die PowerShell. :D Sorry und Gruß olc

Hi SBK, ich denke, daß die meisten "normalen" Kopierprogramme mit Wildcards in Pfaden Probleme haben - selbst Robocopy kann hier meines Wissens nur Dateien mit Wildcards kopieren, jedoch keine Pfade mit Wildcards verwenden. Die PowerShell sollte das können, vielleicht kannst Du das ja einmal testen. Frage: Warum fügst Du nicht einen Zwischenschritt ein und löschst vor dem Kopieren die alten *.default Profile? Dann würde sich die Frage doch gar nicht stellen oder verstehe ich das Problem falsch? Viele Grüße olc

Hi Thomas, ich bin mir nicht sicher, ob das Eintragen der Abhängigkeit in der Registry ausreichend ist. Schau Dir doch einmal das Kommando sc config DIENST1 depend= DIENST2 für den entsprechenden Dienst an. Damit kannst Du Abhängigkeiten definieren. Versuche hier einmal den Dienst korrekt zu konfigurieren - vielleicht löst das ja schon Dein Problem. Viele Grüße olc

Hi, es gibt immer Ausnahmen, aber ich vermute in diesem Fall wird Dir ein Netlogon Logging auf dem DC (wie von Dir angehangen) nicht wirklich weiter helfen, wenn denn eher auf den Clients. :) Hast Du denn ausschließlich den 1054er Fehler oder tauchen weitere Fehler in den Eventlogs auf? SMB-Signing ist korrekt eingestellt, siehe Gruppenrichtlinien - Übersicht, FAQ und Tutorials ? Vielleicht kannst Du ja einmal in das UserEnv Log schauen, welche Error Codes Du bekommst. Viele Grüße olc

Hi Oli, das Entfernen der "Authenticated Users" ist ein "gängiges" Szenario, wenn es um das Erreichen Deines Ziels geht. MS hat das hier auch dokumentiert: Implement ACEs for the Customer Organization Die Frage ist jedoch, ob man nicht trotzdem über Umwege an diese Informationen heran kommt. Das kommt sicherlich auf die "Energie" bzw. das Können eines potentiellen Angreifers an. Aber das Entfernen der Gruppe ist sicherlich ein Anfang. Eine zusätzliche Domäne bringt in diesem konkreten Fall meines Erachtens keine Vorteile, da das Problem ja das selbe bleibt: "Authenticated Users" dürften weiterhin die OU "auslesen" - denn auch Domänenbenutzer / Domänencomputer einer anderen Domäne des selben Forests (als auch im Normalfall bei getrusteten Forests) sind "Authenticated Users". Der Hinweis von Nils ist "charmant", da Du damit zumindest verhindern könntest, daß man direkt die Zuordnung für das Share hinbekommen würde. Aber es ist wie immer - mit wenigen Netzwerkscans oder etwas "social engineering" *B*S*BINGO* bekommst Du die Information wahrscheinlich trotzdem. Viele Grüße olc

Hi, die Erklärung findest Du in dem oben geposteten Link zum Verhalten der Password Policy und dem Domain NC Head: Wenn der PDC diese Daten nicht aktualisiert, läufst Du in das Problem. Aber an diesem Punkt waren wir doch meines Erachtens schon bzw. wir haben das Thema schon angesprochen gehabt. ;) Von daher wäre also zu prüfen, welches Problem der PDC hatte, wenn auch das Löschen der lokalen Sicherheitsdatenbank als auch die Neuregistrierung der entsprechenden DLLs nichts brachte. Unter Umständen war das SYSVOL, auf das der DC zugegriffen hat (muß nicht zwangsweise sein eigenens sein), nicht aktuell? Obwohl - ich glaube auch das hattest Du geprüft oder? Na ja, wie auch immer. Wenn Du dazu spontan nichts mehr finden kannst, dann bleibt es wohl ein "Mysterium". ;) Danke für Deine Rückmeldung und Gruß olc

Hi, hast Du Dir den Link oben angeschaut? Sollte Dein Problem lösen, denke ich. Viele Grüße olc

Hi Piranha, schau einmal hier hinein: Application Log Events Generated When You Start Performance Counter Query Viele Grüße olc

Hi, hast Du denn schon den folgenden KB-Artikel durchgearbeitet? You cannot replicate files from a Windows Server 2003-based domain controller and events are logged in the File Replication Service log Viele Grüße olc

Hi Norbert, ich habe bewußt "eingeschränkten Support" bzw. "nicht vollständigen Support" geschrieben, nicht "keinen Support". Früher hieß es "best effort", heute glaube ich "commercial reasonable effort". Aber wie beschrieben erfahren die GPP meines Wissens (momentan) eben nicht den vollständigen Support. Es ist also wie oben angesprochen vergleichbar mit den Support oder Ressource Kit Tools, die es ebenfalls nicht in das Produkt selbst "geschafft" haben und einige davon erst später integriert wurden. Bis dahin haben diese ebenfalls keinen vollständigen Support erfahren. Leider habe ich gerade auf die Schnelle keinen Link von MS dazu gefunden. Wenn ich jedoch darüber "stolpere", werde ich es nachreichen. Viele Grüße olc

Hi Stronzo, um das ganze noch einmal etwas genauer zu beleuchten (da die bisherigen Antworten, insbesondere die letzte, sagen wir einmal recht "knapp" und wenig erklärend waren...): Die Client Side Extensions für die Group Policy Preferences sind derzeit nur in Windows Server 2008 integriert. Sie bilden in XP als auch Vista keine Builtin-Komponente, da sie vergleichbar mit den früheren "Support Tools" oder dem "Ressource Kit" für Windows Server 2003 nicht vollständig von Seiten Microsofts supportet werden. Support bekommen nur Produkte, die laut Microsoft "ausführlich getestet" wurden - und dies ist scheinbar bei diesen GPP CSEs (noch) nicht der Fall. Würden die CSEs mit dem Produkt / Service Packs ausgeliefert werden, müßte bzw. würde MS auch für XP / Vista vollständigen Support leisten. Vermutlich werden die Komponenten wie auch bei anderen Support oder Ressource Kit Tools irgendwann einmal in die (zukünftigen) Produkte integriert - jedoch ist dies im Moment (außer beim 2008er Server) ganz offensichtlich nicht der Fall. :) Viele Grüße olc

Hi Sascha, ich hoffe, ich verstehe die Frage richtig, aber wenn Du ein Problem mit (Domänen-)Policies hast, macht es meist Sinn, sich als Domänenbenutzer am System anzumelden. ;) Ausnahmen bestätigen die Regel - aber in diesem Fall macht eine Domänenanmeldung Sinn, um den Erfolg Deiner Aktionen ggf. gleich prüfen zu können. BTW: Bei einem Domänencontroller besteht dieser Entscheidungsspielraum nicht - dort gibt es im normalen Betriebsmodus keine lokale Anmeldung in dem Sinne wie auf Memberservern. Viele Grüße olc

Hi Al, na das klingt doch gut. :) In jedem Fall solltet Ihr im Auge behalten, ob es nun vielleicht in Folge der Aktionen zu Problemen kommt. So, wie Du die Ausgangssituation beschrieben hast, passiert wahrscheinlich nichts. Aber es macht Sinn, die Aktionen im Hinterkopf zu behalten. ;) Vielen Dank für Deine Rückmeldung und Gruß olc

Hi Sascha, schau einmal hier hinein, unter Umständen ist das ein Ansatz: You cannot open file shares or Group Policy snap-ins when you disable SMB signing for the Workstation or Server service on a domain controller Viele Grüße olc

Hi, Genau das ist der Punkt: Du benötigst eine "elevated cmd", um das Security Eventlog überhaupt zu sehen - das ist nicht unbedingt gleichbedeutend mit normalen "Administrator"-Rechten. Wenn Du einmal die von Carsten angesprochene WMI Abfrage in dem gleichen Sicherheitskontext ausführst, wie Dein Script ausgeführt wird, dann wirst Du wahrscheinlich sehen, daß das Security Eventlog schlichtweg gar nicht angezeigt wird. Daher werden auch die anderen Logs gesichert, das Security Eventlog jedoch nicht - würde zumindest zu meiner Vermutung passen. ;) :D Versuche es einmal direkt am System, indem Du per Rechtsklick auf den "Command Prompt" --> "Run as Administrator" wählst. Dann landest Du in der "elevated cmd" und wirst das Script in dieser CMD aller Wahrscheinlichkeit nach korrekt ausführen können. Davon einmal ab könntest Du noch eine Überprüfung einbauen, ob es sich bei dem Zielsystem um ein Vista / 2008 System handelt. Falls ja, speicherst Du die Eventlogs gleich mit der Dateiendung "EVTX" ab. Viele Grüße olc