Daim

Servus, ich mach mal Nils in früheren Jahren. :D So soo… und deine Glaskugel verrät dir also, das die Tombstone-Lifetime auf 180 und nicht mit 60 konfiguriert ist? Denn der Titel lautet: "2K3 - Frage zur Thematik DC". Jahaa... ich weiß auch das der Titel nicht immer was zu bedeuten hat. Ich wollt ja nur mal päpstlicher sein als Nils. ;)

Servus, das hier sollte helfen: LDAP://Yusufs.Directory.Blog/ - Clients in die Domäne hinzufügen

Servus outrun, dann führst du eine INTRA Forest Migration durch, korrekt? Sprich, die Migration der User wird innerhalb *eines* Forests (z.B. von Sub-Domäne zu einer anderen Sub-Domäne innerhalb desselben Forests) durchgeführt. Dabei ist das Verhalten von ADMT korrekt und man kann das nicht verändern. Führt man mit ADMT eine INTRA-Forest Migration durch, werden nach der Migration die Quell-Objekte gelöscht. Deshalb muss es gut überlegt sein, wann man auf welchen Knopf im ADMT klickt. Führt man eine INTER Forest Migration durch (eine Migration zwischen zwei Forests), dann werden die Objekte kopiert und die Quell-Objekte bleiben weiterhin erhalten. Das ADMT Verhalten das du erlebst ist also "by Design" und lässt sich nicht verändern. Ansonsten kannst du auch auf kommerzielle Tools ausweichen (kostet halt ein paar Euronen), wobei ich dann blind Quest nehmen würde...

Servus, vor allem sollte man natürlich beim ändern der Subnetze darauf achten, dass man keine overlapping Subnetze erstellt. Wäre design technisch unschön.

Servus, guckst du: LDAP://Yusufs.Directory.Blog/ - Clients in die Domäne hinzufügen

Servus, wenn diese Bedingung nicht erfüllt wäre, würde ADPREP eine klare Fehlermeldung diesbzgl. bringen. ;) @ Luckyluk Was die Meldung anbetrifft: Go ahead! :cool:

Servus, ja, gibt es. Die Antwort lautet --> Migration, z.B. mit ADMT! LDAP://Yusufs.Directory.Blog/ - Einen Domänensplitt durchführen

Servus, LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen Noch Fragen? Dann fragen. ;)

Torsten, jetzt machst du mich aber ferdisch... Warum sollte das Computerkonto denn *automatisch* wieder im AD auftauchen und vor allem, wie kommst du denn darauf? :shock: Ja... logisch... Wenn du das Computerkonto aus dem AD löschst, ist der Client defakto nicht mehr Mitglied der Domäne. Allerdings "glaubt" der Client dann immer noch, dass er Mitglied der Domäne ist, da er nicht "ordnungsgemäß" aus der Domäne entfernt wurde. Du musst dann den Client in eine Arbeitsgruppe nehmen und dann erneut zur Domäne hinzufügen. Jetzt klar?

Servus, also ihr macht vielleicht Sachen.. ;) Ja, dass funktioniert. Jedoch muss der Benutzer dazu "migriert" werden, z.B. mit ADMT. Das ist kein Bordmittel, aber Freeware. LDAP://Yusufs.Directory.Blog/ - Die verschiedenen ADMT Versionen

Ahaa... das ist dann wirklich: Dumm gelaufen aber in deinem Fall ja kein größeres Problem. :-) Du könntest (und solltest) die Tombstone-Lifetime auf 180 Tage setzen. Dabei wächst die AD-Datenank zwar an, da nun gelöschte Objekte länger in der NTDS.DIT verweilen, was aber auf der heutigen Hardware mit den heutigen HDDs kein Problem darstellen sollte.

DCPROMO /FORCEREMOVAL macht nichts anderes, als die AD-Daten LOKAL auf dem DC zu entfernen. Mit dieser "gewaltsamen" Variante bekommt eben das AD nichts davon mit und die Informationen über den gewaltsam heruntergestuften DC bleiben weiterhin im AD bestehen. Es existiert dann eine "Leiche" im AD, die es selbstverständlich zu entfernen gilt, in dem man die Metadaten des AD bereinigt. Du könntest genauso gut den DC ohne DCPROMO /FORCEREMOVAL auszuführen neu installieren. Aber die Metadaten des AD musst du in jedem Fall bereinigen.

Servus, genau so ist es! Die Replikationspartner möchten mit diesem DC nicht mehr reden (replizieren). Der DC der jedoch heruntergestuft werden soll, muss sich aber während des herunterstufen ordnungsgemäß von seinen Replikationspartnern verabschieden (der DC muss ja aus den Metadaten des AD entfernt werden). Wenn diese nunmal jegliche Kommunikation mit dem "scheinbar" veralteten DC verweigern, muss man den DC mit Gewalt (DCPROMO /FORCEREMOVAL) herunterstufen und anschließend die Metadaten bereinigen. Warum jedoch die Fehlermeldung nach so kurzer Zeit erscheint, ist die andere Frage (die mich persönlich brennend interessiert). Vom Aufwand her würde sich die Suche danach nicht rechnen, daher ist das re-promoten die schnellste Variante. @m1k2k Mit "Metadaten" sind die Daten im AD bzw. das AD selbst gemeint und Lingering Objects sind veraltete/herumlungernde Objekte. Diese entstehen auf einem DC immer dann, wenn dieser sich länger als die Tombstone-Lifetime nicht mehr mit seinen Replikationspartnern repliziert hat. Aus: LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)

Servus, jetzt bin ich wohl gefragt. ;) Du sagst es selbst: Du hast die strikte Replikationskonsistenz vor 6 Monaten auf den DAMALS bestehenden DCs - wie auch immer - aktiviert. Wenn du einen "älteren" DC einmal kontrollierst wirst du feststellen, dass die Einstellung auf diesem DC aktiviert ist. Das hassu aba fein jemacht. :cool: Yepp, dass ist in deinem Fall "by Design"! Wie ich es in meinem Artikel auf den du verweist geschrieben habe, ist standardmäßig die strikte Replikationskonsistenz bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn eine Gesamtstruktur ab Windows Server 2003 erstellt wurde aktiviert. Eine Gesamtstruktur die mit Windows Server 2003 oder höher installiert wurde, verfügt über eine spezielle operative GUID, der nicht in einer Gesamtstruktur mit Windows 2000 Wurzeln existiert. Wenn ein Server zum DC hochgestuft wird, überprüft dieser ob die folgende GUID existiert: CN=94fdebc6-8eeb-4640-80de-ec52b9ca17fa,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=<forestdomain> Das bedeutet, damit ab sofort alle künftigen DCs innerhalb der Gesamtstruktur (die von Windows 2000 aktualisiert wurde) automatisch die strikte Replikationskonsistenz aktiviert haben, muss man manuell den operativen GUID in der Konfigurationspartition setzen. Wie man das durchführt, ist hier erklärt: Event ID 1388 or 1988: A lingering object is detected: Active Directory Yepp. ...ist alles korrekt erläutert! Wenn du auf allen DCs innerhalb der Gesamtstruktur die strikte Replikationskonsistent aktivieren möchtest, kannst du das ab Windows Server 2003 SP1 mit folgendem REPADMIN-Befehl erledigen: Repadmin /regkey * +strict P.S. Dazu sollte ich mal was auf meinem Blog schreiben. =)

Servus, kontrolliere unbedingt das DNS und bereinige es ggf. Denn wenn der DC der nun an einen anderen AD-Standort verschoben wurde noch mit seinen Daten am "alten" AD-Standort im DNS eingetragen ist, könnte es zu verzögerten Anmeldeverhalten bei den Clients am alten AD-Standort kommen. Beachte: LDAP://Yusufs.Directory.Blog/ - Einen Domänencontroller an einen anderen Standort verschieben

Servus, keine, wenn man es "richtig" macht. ;) Och, ganz gut. :cool: Ohne genauere Angaben verweise ich erstmal hierhin: LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Servus, du könntest zwar auch an der Priorität bzw. Gewichtung in den DNS-Einträgen des DCs drehen, aber wie ist das folgende Zitat zu verstehen? Gerade deshalb "sollte" es zu keinen Problemen in einer Domäne mit mehreren DCs kommen...

Haben wir das? Jaaaa bin schon wech, hab seit neuestem eh keine Zeit. :cool:

Ich hatte nichts anderes erwartet. :p :cool:

Servus, das hängt davon ab, mit welchen Benutzernamen du dich anmeldest. Entweder sAMAccountName oder userPrincipalName. Siehe oben. Das Attribut "name" ist der Name der dir in der Übersicht der MMC "AD-Benutzer und Computer" angezeigt wird. Siehe dazu: LDAP://Yusufs.Directory.Blog/ - Die Active Directory-Attribute hinter den Feldnamen Dann musst du den Hersteller kontaktieren. So ist es. Das scheint die Anwendung so zu wollen. Aber kontaktiere mal den Hersteller, evtl. liegt das auch an einer Einstellung der Applikation.

Servus, beide Domänen befinden sich also innerhalb einer Gesamtstruktur, wobei es sich um eine Root- und Subdomäne handelt und keine zwei verschiedenen Domänenstrukturen (Tree) bestehen. Also ich zähle hier insgesamt --> drei <-- Domänen. Bei der "wurst.de" handelt es sich um die Rootdomäne und bei "hans.wurst.de" sowie "klaus.wurst.de" handelt es sich um zwei Subdomänen, die sich beide unterhalb der Rootdomäne auf der gleichen Ebene befinden. Redest du vom AD oder DNS? Ich vermute AD und das geht nicht. Falls die Rootdomäne nicht mehr existiert, ist die Gesamtstruktur "zerstört"! Wenn dann kein Backup existiert, müsstest du migrieren. Oha... hier ist dringend "Grundlagen pauken" angesagt! Was soll denn bitte schön die Domäne "klaus.wurst.de" von "hans.wurst.de" übernehmen? An deinen Erläuterungen kann man schwer erkennen, dass du scheinbar noch sehr frisch im Geschäft bist. Den "so" wie du das ganze schilderst ist der Grund, warum bisher auch noch keiner geantwortet hatte. Alle haben dann auf mich gewartet, damit ich dir das sage. ;) :p Das lässt du mal schön sein und greifst stattdessen zum Hörer! Hole dir einen Dienstleister der das dann hoffentlich wieder für euch richten kann. Die Antworten hierauf spare ich mir, da du in deinem Post ziemlich viel durcheinander wirfst und das eigentliche Problem ganz woanders liegt.

Es ist "Best Practice", dass sich die FSMO-Rollen stets auf dem DC befinden, der das aktuellste OS ausführt.

Aber sicher doch, dafür sind wir schließlich hier. ;) Si senior! Die Redundanz hat man bereits, sobald zwei DCs in der Domäne existieren. Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Das ist doch gerade der Witz! Wenn zwei DCs existieren und auf beiden das DNS installiert ist, können sich die Clients weiterhin anmelden, wenn ein DC ausfallen sollte. Vorausgesetzt den Clients werden beide DNS-Server mitgeteilt.

Das Stichwort lautet: Standortverknüpfungsrücke (site link bridge). Eine Standortverknüpfungsbrücke dient dazu, eine Verbindung zwischen Standorten herzustellen, die keine direkte Verbindung untereinander besitzen. Wenn du eine Standortverknüpfung einmal zwischen HQ und Seattle, sowie HQ und Amsterdam erstellst, wird durch die Standortverknüpfungsbrücke eine Verbindung zwischen Seattle und Amsterdam erstellt. Wenn das Routing es nicht zulasen würde das Standorte untereinander direkten Kontakt haben (kein durchgeroutetes Netzwerk auch nicht über die Zentrale), wie es eben bei einer klassischen Hub-and-Spoke Topologie der Fall ist, sollte man die Standortverknüpfungsbrücke deaktivieren. Ohnehin ist das arbeiten mit Standortverknüpfungsbrücken erst mit mindestens drei Standorten möglich, wobei zwei Standorte dabei keine direkte Verbindung untereinander aufweisen, was bei dir ja der Fall ist. Eine Standortverknüpfungsbrücke dient quasi als Routing für die zu replizierenden Daten. Ist die Standortverknüpfungsbrücke deaktiviert, gibst du durch die Standortverknüpfung genau vor, welcher Standort mit welchem Standort replizieren soll. Dadurch steuerst du exakt die Replikation der Standorte. Damit wirst du deine Fehlermeldungen los. Die Standortverknüpfungsbrücke kannst du in der MMC "AD-Standorte und -Dienste" deaktivieren. Navigiere dazu zum Container "Inter-Site Transports" und rufe mit einem Rechtsklick, die Eigenschaften des Containers "IP" auf. Dort kannst du dann die Option "Brücke zwischen allen Standortverknüpfungen herstellen" deaktivieren". Falls du DFS-N im Einsatz haben solltest, darfst du die Standortverknüpfungsbrücke *nicht* über den IP Container deaktivieren, sondern musst mit dem Befehl "repadmin /siteoptions W2K3_BRIDGES_REQUIRED" die Standortverknüpfungsbrücke deaktivieren.

Servus, wenn du das Computerkonto zurücksetzt, wirfst du automatisch den Client aus der Domäne. Anschließend musst du den Client erneut zur Domäne hinzufügen (joinen).