Daim

Servus, hmm... anhand deiner Signatur, müsstest du dir das Verhalten selber erklären können! Hast du schon einmal etwas von "Round Robin" gehört (was ich hoffe)? Bevor eine Vertrauensstellung vom Local Security Authority (LSA) Prozess erstellt wird, prüft dieser die Eindeutigkeit folgender Auflistung: - Den NetBIOS Namen der Domäne - Den Fully Qualified Domain Name (FQDN) der Domäne - Die Security Identifier (SID) der Domäne Diese drei Punkte müssen eindeutig sein, da ansonsten keine Vertrauensstellung zu Stande kommt. Wobei bei der Einrichtung der Vertrauensstellung primär der NetBIOS-Name der Domänen verwendet wird. Die PDC-Emulatoren der Domänen richten die Vertrauensstellung ein und handeln das Kennwort für den Trust eigenständig untereinander aus. Das Kennwort für die Vertrauensstellung wird dann alle 30 Tage von den PDC-Emulatoren geändert. Die entscheidende Frage in deinem Szenario ist also, haben beide PDC-Emulatoren Verbindung zueinander (was zwingend notwendig ist)? Und abgesehen davon, dein Vorhaben lässt sich mit der "selektiven Authentifizierung" lösen. Wenn beide Domänen sich mindestens im Windows Server 2003 Domänenfunktionsmodus befinden, kann man beim Erstellen der Vertrauensstellung die Option "Selektive Authentifizierung" aktivieren. Danach ruft man im AD auf dem Computerobjekt z.B. Printserver, Fileserver etc. in den Eigenschaften die Registerkarte "Sicherheit" auf und fügt idealerweise eine Gruppe, die Zugriff nur auf den entsprechenden Server erhalten soll, aus der vertrauten Domäne hinzu. Als nächstes vergibt man im Reiter "Sicherheit" das Recht "Allow to Authenticate / Darf authentifizieren". Dadurch können sich die Gruppenmitglieder aus der vertrauten Domäne nur an diesem einen Server anmelden und keine anderen Ressourcen der Domäne nutzen.

Servus, gerade wenn es eine Testumgebung ist, wird doch der GC für das AD in einem Single Domain Forest nicht benötigt, es sei denn, es existieren mehrere Domänen innerhalb einer Gesamtstruktur in der Testumgebung.

Servus, wie ist das genau gemeint? Meinst du das Anmelden lokal an der Tastatur direkt am Server oder die Authentisierung der Clients nach dem Rechnerstart? Nein, dass ist nicht normal. Die FSMO-Rollen haben mit der Benutzerauthentisierung nichts zu tun. Genau so ist es auch! Nein, dass ist nicht korrekt. Wenn der FSMO-Rolleninhaber crasht, musst du die FSMO-Rollen "gewaltsam" auf einem anderen DC übernehmen und den gecrashten DC aus den Metadaten des AD entfernen. Aber auch ohne die Rollen, können die anderen DCs die Benutzer authentisieren. Du gibst leider keine Infos bzgl. der Umgebung um die es sich handelt. Ein Kandidat bei Anmeldeproblemen ist stets das DNS. Haben die Clients ausschließlich die DCs als DNS-Server in ihren TCP/IP-Einstellungen eingetragen und nicht noch den Router? Wird die Forward Lookup Zone im DNS AD-integriert gespeichert? Erscheinen Fehler im Eventlog der DCs?

Servus, 1. der Befehl mit dem du die AD-Informationen *lokal* auf dem DC entfernst lautet: DCPROMO /FORCEREMOVAL 2. Nach dem neu installieren stufst du den Server zum --> DC und nicht zum "Mitgliedsserver". 3. Nach einem DCPROMO /FORCEREMOVAL musst du zuerst die Metadaten des AD bereinigen (NTDSUTIL -metadata cleanup). Erst recht, wenn du einem neuen Server dieselbe IP und denselben Computernamen vergeben möchtest. Erst danach solltest du einen "neuen" Server mit den gewünschten Informationen zum DC stufen.

Existieren in dieser Gesamtstruktur noch weitere Domänen oder ist das die Einzige? Und trotzdem: SnapShots auf DCs ist ein striktes NO-GO!

Servus, ich hoffe für dich, dass die Testumgebung zur Zeit und in der Zukunft, nie eine Verbindung zur produktiven Umgebung hat bzw. haben wird! Versuchst du das Verschiebe der beiden Rollen in der grafischen Oberfläche (in welchen MMCs?), direkt von dem zukünftigen Rolleninhaber durchzuführen? Falls nicht, teste das einmal.

Servus, na aber sowas von "Hallo"! Natürlich ist die bedingte Weiterleitung die einfachste Variante und vor allem die Admin freundlichste Variante. ;).

Servus, LDAP://Yusufs.Directory.Blog/ - Computerkonto löschen

Servus, Kennwortrichtlinien die für Domänen-Benutzer gelten sollen, müssen auf Domänenebene, bevorzugt in der Default Domain Policy verlinkt werden. Denn wenn du eine Kennwortrichtlinie auf einer Organisationseinheit verlinkst, betrifft das lediglich die LOKALEN Benutzerkonten auf den Clients. Nach dem die Kennwortrichtlinie konfiguriert wurde, solltest du in den Eigenschaften der Benutzerkonten den Haken "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" setzen. Natürlich erst nach vorheriger Information an die Benutzer. Bei Dienstkonten und deinen Thinclients könntest du (warum überhaupt?) in den Benutzereigenschaften den Haken "Kennwort läuft nie ab" setzen.

Servus, auch bei den Clients wird LastLogon und LastLogonTimeStamp gesetzt. Das Problem von LastLogon ist, dass es nicht zwischen den DCs repliziert wird. Das bedeutet, wenn sich der Client heute an DC1 authentisiert und morgen an DC2, musst du LastLogon von beiden DCs abfragen um das aktuellste Datum zu erhalten. Ab dem Domänenfunktionsmodus "Windows Server 2003" kannst du das "LastLogonTimeStamp" Attribut nutzen, denn dieses wird repliziert (verzögert). LDAP://Yusufs.Directory.Blog/ - Die letzte Benutzeranmeldung herausfinden Wenn du es einfach haben möchtest (was natürlich so sein soll), dann nimmst du LUMAX. Active Directory User Maintenance

Servus, Rechtsklick auf dem Desktop - Neu - Verknüpfung und als Ziel das eingeben: %SystemRoot%\SYSTEM32\rundll32.exe dsquery,OpenQueryWindow

Off-Topic:Och, also da habe ich hier im Board in den vergangenen Jahren schon schlimmeres in den Logs gesehen. Aber ist ja auch kein Wunder, wenn man so lange eine Leiche im AD hat. ;)

Servus, ja, du musst die Metadaten des AD bereinigen und der Lugar2 aus dem AD entfernen. Wie das geht, steht hier: LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Wie allerdings der andere DC der Rolleninhaber sein konnte ohne das der SBS Stress macht, ist verwunderlich. Denn der SBS muss immer der Rolleninhaber und GC sein. Nun musst du eben die Rollen auf dem SBS offline übernehmen. Wie das funktioniert, steht hier ganz unten: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Achte auch darauf, dass in den TCP/IP-Einstellungen des SBS er selbst als bevorzugter DNS-Server drin steht und nicht etwa der Router.

Servus, kann es sein das du glaubst (und das darf doch nur der Pfarrer) ein Problem zu haben, wo keins ist? Es findet keine Full-Mesh Replikation statt, also nicht jeder DC repliziert mit jedem anderen. Wenn es Probleme mit der AD Replikation gibt, meldet dir das auch das Eventlog. Werden denn Fehler, mindestens im Verzeichnisdienstprotokoll protokolliert? Und wo *genau* wird dir angezeigt, dass die Tombstone-Lifetime abgelaufen ist? Was es mit dem Bridgeheadserver auf sich hat, erfährst du hier: LDAP://Yusufs.Directory.Blog/ - Die Auswahl eines Bridgeheadserver

Na klar gibt es die MMC auch unter Windows Server 2008. Installiere die --> AD DS Rolle auf dem Server, dann stehen dir die AD MMCs zur Verfügung. Aber warum von einem Server und nicht von einem Client aus?

Servus, bitte keine Overtakes. Erstelle einen eigenen Thread. http://www.mcseboard.de/rules.php#nr7 Das Attribut LastLogon wird nicht zwischen den DCs repliziert. Verwende das Attribut LastLogonTimeStamp, wenn sich die Domäne mindestens im Domänenfunktionsmodus Windows Server 2003 befindet, denn dieses Attribut wird zwischen den DCs repliziert. Was es mit dem LastLogonTimeStamp auf sich hat, erfährst du in dem Link aus meiner vorherigen Antwort.

Na dann sollte man doch auf den Windows XP Rechnern die Ursache suchen (DNS, GPOs, oder die XP Clients durch Windows 7 Clients ersetzen). Ein Trace ist dabei sehr hilfreich oder auch das Userenv logging und kontrolliere das Eventlog der Clients. How to enable user environment debug logging in retail builds of Windows

Servus, bei ~fünf Mitarbeitern, würde ich weder einen beschreibbaren, noch einen RODC vor Ort installieren! Die können sich auch ohne Probleme über die VPN-Verbindung (sofern diese zur Verfügung steht) an einem DC in der Zentrale authentisieren. Das "muss" macht aber mit den bisher genannten Informationen und vor allem bei der Größe der Aussenstelle, überhaupt keinen Sinn.

Salve, kann es sein, dass du dir ein paar Grundlagen zu RODCs aneignen solltest? ;) Genau so ist es. Neben den Benutzerkennwörtern müssen auch die Computerkontokennwörter zum RODC repliziert werden, wenn der RODC eigenständig (wenn keine WAN-Verbindung zu einem beschreibbaren DC existiert) die Benutzer authentisieren soll.

Servus, wenn kein System State Backup von den beschreibbaren DCs existiert, was natürlich der Fall sein sollte, dann ist das korrekt. Denn RODCs können nicht zu beschreibbaren DCs umgewandelt werden. Genau. Wenn keine beschreibbaren DCs und KEIN Backup mehr existiert (und spätestens hier würde ich den Admin mindestens "teeren und federn"), muss die Domäne neu installiert werden. Welches Backupkonzept muss denn nicht "ganz sicher" sein? Jedes Backup muss ordnungsgemäß funktionieren! Sichere auf beiden DCs regelmäßig (mindestens) das System State und kontrolliere ob auch tatsächlich die Sicherung stattgefunden hat.

Naja, die Mindestzeit von 15 Minuten für die InterSite-Replikation wurde ja (auch) deshalb so designed, damit die AD-Replikation Effizient durchgeführt werden kann. Damit eben ein AD-Standort die Änderungen sammelt und dann die Aktualisierungen in einem Intervall repliziert, um die "damals" kostbare Bandbreite (das heute kaum mehr zutrifft) zu schonen. Mal schauen ob ich es noch detaillierter herausfinde.

Servus, ne, also "so" stimmt das nicht. Denn sobald der Wert eines Attributs repliziert wurde, ändert sich die USN und diese speichert der Quell- und Ziel-DC. Also funktioniert das technisch schon garnicht, dass die AD-Replikation wieder von vorne beginnt. Die unterstützte Anzahl der Änderungen die innerhalb eines Schreibvorgangs während der AD-Replikation durchgeführt werden kann beträgt 5.000. Das war schon seit Windows 2000 so und ist auch ab Windows Server 2003 und der LVR-Replikation noch so. Anders ausgedrückt, das AD kann lediglich mit einer bestimmten Anzahl an Werten während eines Schreibvorgangs bzw. eines Replikationszyklus umgehen. Aber die AD-Replikation beginnt niemals von vorne. :) Die Empfehlung, die Änderungsbenachrichtigung über Standortgrenzen hinweg zu geben, ist ganz meine Rede. Aber nur, wenn es die Umgebung zulässt. ;)

Servus, aber dann müsstest du im Eventlog (Dateireplikationsdienst) einige Fehlermeldungen erhalten haben. Finde heraus, auf welchem DC das SYSVOL ordnungsgemäß vorhanden ist. Dann könntest du eine autoritative Wiederherstellung des SYSVOLs durchführen (BURFLAGS D4/D2). Dabei könntest du dich an diesen Artikel halten: LDAP://Yusufs.Directory.Blog/ - Dateireplikationsfehler mit der ID 13568 Aber verschaffe dir erstmal einen Überblick und kontrolliere das Eventlog.

Servus, doch, RSAT muss vorher heruntergeladen und installiert werden. http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en

Servus, nur zur Info: Das AD Schema lässt sich nicht rücksichern, auch autoritativ nicht. Falls du zu dem vorherigen AD Schema-Stand möchtest, musst du ein Forest-Recovery durchführen. Eine Schemaänderung sollte zuerst in einer abgeschotteten Testumgebung getestet werden. Die Schemaänderung selbst sollte man um Fehler zu vermeiden (z.B. Tippfehler), oder wegen der Dokumentation sowie zum nachvollziehen, skripten. Erst wenn die Tests in der Testumgebung erfolgreich waren, sollte man die Änderung in der produktiven Umgebung durchführen.