olc

Ähm, doch - ich meine DCGPOFIX. :D :p Hatte nur nicht mehr auf dem Schirm, daß es den Mist unter 2003 auch noch gab. :D So oder so, Probleme damit sind vorprogrammiert (im Wortsinne): The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state THX. ;)

Hi, mit dem DCGPOFIX hast Du vermutlich mehr kaputt gemacht, als es gebracht hat. Das Tool ist aus den Windows 2000 Support Tools, 11 Jahre in der Vergangenheit. Quick and dirty könntest Du eine Testdomäne hochziehen, also einfach in einer Testumgebung einen Windows Server 2003 (R2) Server aufsetzen, dort dann noch falls notwendig Exchangeprep (forest und domain prep) durchführen, die Default Gruppenrichtlinien dort exportieren und in der Produktionsumgebung importieren. Mit einigen kleineren Anpassungen sollte das dann wieder hinkommen, es sei denn, Du hast in den Standardrichtinlien Änderungen vorgenommen. Falls dies der Fall ist, mußt Du Deine hoffentlich vorhandenen Backups bemühen, die Einstellungen zurück zu bekommen. Dabei ist zu beachten, daß Du bei einem SYSTEMSTATE Backup den Container "CN=Policies,CN=System,DC=domain,DC=tld" autorativ plus das SYSVOL autorativ wiederherstellen mußt. Oder, wenn Du es hast, ein GPMC Backup, was meine präferierte Variante wäre. Ansonsten haben es die Kollegen schon mehrfach geschrieben: Bevor Du hier tagelang mit halbgaren Lösungen die Produktionsumgebung gefährdest, schalte schnellstmöglich einen Dienstleister ein, der es behebt. Sonst machst Du es vielleicht nur noch schlimmer. Viele Grüße olc

Hi, just for the record: RSOP.MSC ist ab Vista oder spätestens Windows 7 nicht mehr die beste Wahl, da es nicht mehr alle Einstellungen korrekt anzeigt. Es befindet sich laut MS im "maintenance mode", d.h. Neuerungen usw. werden nicht mehr eingepflegt und somit ggf. auch nicht die Darstellung diverser CSE Veränderungen. Bessere Wahl ist also ein "gpresult /h datei.html". Und wie Nils schon sagte, muß dies mit Administrator Token passieren, sonst werden keine Computereinstellungen angezeigt. Viele Grüße olc

Hi, wie häufig tritt die Fehlermeldung auf? Hast Du irgendwelche Einschränkungen in Bezug auf die Funktionalität? Viele Grüße olc

Hi, In diesem Fall stimmt das nicht ganz. Die ADM Vorlagen decken den Bereich der "Administrativen Vorlagen" ab, nicht jedoch die Sicherheitseinstellungen unterhalb von "Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen". BTW: http://support.microsoft.com/kb/981750/en-us FULL ACK... Viele Grüße olc

Hi, kopiere einmal nicht den HTML Text in die CMD, sondern trag es manuell ein. Dann dürfte der Fehler verschwinden. Ein "certutil -view -restrict" sollte auch Hilfestellung geben. Schau Dir wie angesprochen den Link oben einmal an, dort ist m.E. alles entahlten, was Du an Informationen benötigst. Werden die Zertifikate manuell ausgestellt? Handelt es sich um eine Domänenumgebung? Bei letzterem könntest Du das Autoenrollment nutzen, was die Fragestellung elegant automatisch löst, ohne daß Du dazu etwas scripten müßtest. :) Viele Grüße olc

Hi, certutil -view -restrict -? ;) Was genau meinst Du mit filtern? Du kannst diesen Export ja filtern, mußt halt vorher nur die Header entfernen. Danach halt Excel. ;) Oder meinst Du direkt im Export nach Datum filtern? In letzterem Fall schau einmal hier: Disposition values for certutil Greift in diesem Fall nicht, weil es nicht um die CA Zertifikate geht, sondern die ausgestellten Zertifikate inkl. DB Export. :) Viele Grüße olc

Hi, wenn Du lokal auf dem Laptop an dem Profil etwas änderst, dann werden per Roaming Profiles diese neueren Dateien auf den Server kopiert. Es gewinnt die neue Version, die ja lokal liegt. Oder arbeitest Du "gleichzeitig" auch mit dem Profil innerhalb der Firma und es wird zum Profilserver synchronisiert? Viele Grüße olc

Hi augi, welches darunter liegende Problem versuchst Du damti zu lösen? Roaming Profiles erledigen im Kern genau das, was Du beschreibst. Was genau versuchst Du also zu erreichen? Viele Grüße olc

Gern. :) Denk auch daran, daß der Task Scheduler ebenso eine Rolle spielt: Why is autoenrollment only happening if initiated manually through the MMC? - AD Troubleshooting - Site Home - TechNet Blogs Viele Grüße olc

...na ja, ich hatte ja eine ganze Menge anderer Vorschläge gemacht... ;) Viele Grüße olc

Hi Carnivore, ja, das läuft auch über das Autoenrollment, siehe dazu auch: Viele Grüße olc

Hi, auf keinen Fall nur sendende Verbindungen konfigurieren, siehe den Link oben. Immer sendende und empfangende Verbindungen konfigurieren, so wie Du es oben beschrieben hast. Ansonsten gibt es Probleme, im schlimmsten Fall je nach Konstellation auch Datenverlust. Und ja, nach Deiner Beschreibung sollte es so funktionieren. Sofern Du die "Rückverbindung" noch korrekt konfigurierst. Viele Grüße olc

...es gibt ja keinen Junction point auf SYSVOL / SYSVOL. Nur einen von ...\SYSVOL\SYSVOL\domain.tld nach ...\SYSVOL\domain, was auch korrekt so ist. Damit sollte die Frage also auch erledigt sein. Viele Grüße olc

Hi zusammen, Ich baue mein Know How nur selten in einer Produktivumgebung auf. :D :p Du schreibst zu Beginn, daß Du den DC2 neu aufsetzen mußtest. Hast Du ihn sauber aus der AD Umgebung entfernt, also etwa mittels DCPROMO oder falls damit nicht möglich mittels Metadata Cleanup? Bevor Du hier Tage investierst und Probleme in der Produktionsumgebung riskierst, würde ich persönlich den pragmatischen Ansatz wählen: Demote DC2, prüfe mittels Metadata Cleanup, ob der DC auch wirklich sauber entfernt wurde, danach erneutes DCPROMO von DC2. Wenn es dann immer noch nicht läuft, kann man weiter schauen. :) Viele Grüße olc

Hi, ganz pragmatisch: Spricht irgend etwas gegen ein erneutes DCPROMO des neuen DCs? Virenscanner ist mit im Boot? Wenn ja, welcher? Welche Ausschlußverzeichnisse, mit Firewall? Viele Grüße olc

...wenn Du es richtig gemacht hast, dann nicht. ;) Viele Grüße olc

Hi, Das ist so nicht ganz korrekt - denn nach der Beschreibung oben ist es ja gerade *keine* one way connection. Es wurden schließlich Hin- & Rückverbindungen konfiguriert. Also, noch einmal: Abwarten und Tee trinken. Mittlerweile sollte es doch durch sein mit den Verbindungsobjekten. ;) Viele Grüße olc

Hi, die DFSR Konfigurationsdaten müssen nach Deiner Änderung erst von den DCs repliziert werden. Danach benötigen die DFSR Dienste noch bis max. 1 Stunde, bis sie die Daten aus der AD lesen. Vielleicht warst Du also einfach zu schnell mit dem Test. Viele Grüße olc

Hi, wenn Du den Task um 00:01 Uhr startest, hast Du immer genau die letzten 24 Stunden... Wenn nichts verändert wurde, würde nichts kopiert werden. Ansonsten nimm die PowerShell: Hey, Scripting Guy! How Do I Back Up Files That Have Been Modified in the Last Day? - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs Viele Grüße olc

Hi, wie oben geschrieben, solltest Du den Blog nicht nur lesen, sondern auch verstehen. ;) DFSR (oder meiner Meinung nach auch alle anderen "Lösungen"), können das nicht so einfach realisieren. Du kannst mit hoher Wahrscheinlichkeit keine 100%ige Verfügbarkeit der WAN-Leitung sicherstellen, außerdem spielen Latenzen auf der Leitung eine Rolle, die Auslastung, wie die Replikationsstruktur aussieht usw. Nochmal der Hinweis, daß Du mit dem Ansatz als solchem eher auf dem Holzweg bist und die Hinweise von oben beachten. Versuch es nicht nach dem Prinzip "Es kann nicht sein, was nicht sein darf" mit der Brechstange durchzudrücken... Viele Grüße olc

Hi, versuch einmal einen anderen Ansatz: ROBOCOPY /? Viele Grüße olc

Hi, wenn Du eine "Full-Mesh" Topologie gewählt hast, dann wird "irgend ein" initialer Replikationspartner gewählt. Liegt ja in der Natur der Sache. ;) Wenn Du das nicht möchtest, dann fügst Du beim Aktivieren des Servers keine Connection ein, sondern erstellst die Verbindung erst nach dem Beitritt des Servers in die Replikationgruppe hinzu. Dabei kannst Du dann wählen, welcher Partner für die Replikation gewählt werden soll. Alterativ schau einmal in der Suchmaschine Deiner Wahl nach dem Begriff "DFSR pre-staging" bzw. " DFSR pre-seeding". Viele Grüße olc

Hi Sisterchen, "leere" searchFlags bringen Dir nicht viel, Du benötigst die derzeit mit einem FAS versehen Attribute. Nur "leere" searchFlags würden auch GC Attribute usw. auslassen. Der Filter für den FAS lautet wie folgt: Hintergrund sind die im oben geposteten Artikel genannten Bits: Wie gesagt, ich halte (trotz Deiner Erläuterung) daran fest, daß das Vorgehen insgesamt nicht sinnvoll ist. "Wasch mir den Buckel aber mach mich nicht naß!" funktioniert nun einmal nicht. ;) Viele Grüße olc

Hi Sisterchen, ok, wenn es Dir um die Ports geht, dann helfen Dir die ersten Treffer direkt weiter ;) : trust firewall port requirements - Google-Suche Viele Grüße, olc