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