Daim

Ersetze das "wohl eher" durch ein "!".

Das schon. Hat denn das Benutzerkonto auch in der Ziel-Domäne die entsprechenden Rechte? Nein. Wie soll ich das von hier beurteilen? Die Whitepaper zum ADMT hast du durchgelesen?

Servus, wie groß ist denn die Umgebung? Warum sollte das ein Problem sein? Es können deutsche sowie englische DCs nebeneinander existieren. Dies stellt kein Problem dar. Warum wenn man fragen darf? Natürlich. Das AD ist ohnehin in englisch gehalten... Du musst lediglich darauf achten, falls du Gruppen migrieren solltest, mit der Arbeit von GPOs die SIDs zu verwenden und nicht die Namen. Ohnehin würde ich Gruppen in solch einem Fall nicht migrieren, sondern lediglich die Benutzer- sowie Computerkonten. Yepp. Nein. Du müsstest dann mit ADMT über eine Interims Domäne mit anderem Namen migrieren.

Dann ist etwas schief gelaufen... Dort muss der neue Domänenname stehen. Ist das Benutzerkonto mit dem du das ADMT ausführst, auch in der lokalen Administrator Gruppe des Clients eingetragen?

Servus, falls der Benutzer gelöscht wurde und die Tombstone Lifetime noch nicht abgelaufen ist, findest du den Benutzer im versteckten Container "Deleted Objects" das sich in der Domänenpartition befindet. Natürlich nur wenn es sich um eine AD-Umgebung handelt. Diesen Container findest du z.B. mit einem LDAP-Browser oder LDP.exe. Yusuf`s Directory - Blog - Active Directory Wiederherstellung

Das kannst du z.B. mit einem Skript erledigen: How To Use Visual Basic Script to Clear SidHistory Kontrolliere auf dem Client unter "Systemsteuerung - System" den Reiter Computername. Steht dort unter Domäne die neue oder immer noch alte Domäne?

OK, dann kann die "Überbrückung" bestehen bleiben. Das ist völlig in Ordnung. Das Design bestimmt eben der KCC. Du hast händisch aber nicht selbst festgelegt, welcher DC Bridgeheaad-Server sein soll und lässt diese Wahl das AD treffen? Du kannst durch die Konfiguration der Kosten Einfluss auf die Replikationsverbindungen nehmen. Wie gesagt, es funktioniert auch so wie du es beites durchgeführt hattest. Wichtig ist das DNS und vorallem, dass nach dem verschieben des DCs das DNS bereinigt wird. Beachte dazu meinen zweiten Link im vorherigen Post. In deinem Fall muss ein Konfigurationsfehler (wo auch immer) existieren. Korrekt. Klaro. Wie soll eine Replikation stattfinden wenn das Verbindungsobjekt nicht existiert. Dann aktiviere die Änderungsbenachrichtigung standortübergreifend. Yusuf`s Directory - Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren Du könntest aber auch alle physikalischen Standorte in einem AD-Standort zusammenfassen. Och... probiere es doch aus, dann siehst du es selbst ;) .

Das tut sie auch. Jeder DC hält seine eigenen Verbindungs-Objekte. Wählt der OP Server2 auf der linken Seite aus, würde auf der rechten Seite das Verbinduns-Objekt vom Server1 erscheinen.

Bonjour, du wirfst hier die Update-Sequence Number (USN) mit der Versionsnummer durcheinander. Die USN des geänderten Attributs wird auf jedem DC bei einer durchgeführten Änderung hochgezählt. Durch die USN wird kontrolliert, welche Änderungen seit der letzten Replikation durchgeführt wurden. Jeder Domänencontroller merkt sich, von welchem DC welche USNs bereits repliziert wurden. Durch die Versionsnummer (versionID) wird festgestellt, wer im Fall eines Konflikts die neueren beziehungsweise häufiger aktualisierten Daten hält. Wenn nun die Replikation stattfindet, fordert der DC die geänderten Attribute an, die seit der letzten Replikation verändert wurden. Dieses ist dank der USN möglich. Danach werden durch die Versionsnummer die aktuelleren Daten ermittelt. Falls die Versionsnummer gleich lautet, wird der Zeitstempel überprüft. Wenn in seltenen Fällen der Zeitstempel gleich lautet, entscheidet die niedrigere GUID des DCs bei der Replikation. Siehe: Yusuf`s Directory - Blog - Active Directory-Replikationskonflikt

Bonjour, wie jetzt? Gibt es hier etwa Spezialisten? Wo denn? Wie sieht denn die Netzwerk-Topologie aus? Sternförmig, also Hub-and-Spoke oder vermascht (jeder Standort erreicht direkt jeden anderen Standort)? Das ist nicht notwendig. Die Verbindungsobjekte sollten alle nach einer gewissen Zeit automatisch erstellt werden. Wichtig ist nach dem verschieben das DNS zu bereinigen und ggf. die Site-Links anzupassen. Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben Das Design in "Standorte und Dienste" sollte den physikalischen Standorten entsprechen. Das bedeutet, wenn eine Hub-and Spoke Topologie besteht, dass also StandortA nur mit der Zentrale kommunizieren kann, dann solltest du das auch so im AD abbilden. Erstelle für jeden physikalischen Standort einen Standort im AD (gelbes Icon), samt Subnetz und verknüpfe das Subnetz mit dem entsprechenden Standort. Erstelle dann eine eigene Standorterknüpfung zur Zentrale und definiere die Kosten (standmäßig 100). Wenn du magst kannst Du auch noch andere Standortverknüpfungen definieren, die andere Wege gehen, beeinflußt durch die Kosten. Dann könntest Du noch die Option "Brücken zwischen allen Standortverknüpfungen herstellen" (in den Eigenschaften des IP-Containers) deaktivieren. Dadurch wird verhindert, dass der KCC Verbindungen erstellt, die mehrere Standorte überbrücken. Was zwingend gemacht werden muss, ist anschließend das DNS zu bereinigen. Yusuf`s Directory - Blog - Domänencontroller am Standort Das ist nicht notwendig. Es ist natürlich möglich einen DC in der Zentrale zu installieren und anschließend den DC an einen anderen Standort zu verschieben. Vermutlich liegt der Fehler an einer Konfiguration... Du könntest aber auch den DC vor Ort an seinem Ziel-Standort installieren. Dabei kannst du die "Install from Media" Funktion nutzen. Diese Option verringert das Replikationsaufkommen und stellt schneller den DC bereit. Yusuf`s Directory - Blog - Domänencontroller-Installation von einer Sicherung

Wie gesagt, bei der Migration wird ja das Objekt nicht eins zu eins verschoben. Es wird ein neues Benutzerobjekt in der neuen Domäne erstellt und die SID des alten Benutzerkontos in das Attribut SIDHistory des neuen Benutzerkontos hinzugefügt. Dazu muss in der Quelle der DC mit den FSMO-Rollen zwar nicht erreichbar sein, aber warum denn diesen Umstand? Ein DC hat online und erreichbar zu sein.

Nein, du hast keinen Fehler gemacht. Da meine ADMT Migration ein paar Tage her ist, kann ich nicht mehr genau sagen in welcher Konstellation die Aufforderung kam. Fakt ist, wenn sich der Benutzer an seinem Rechner in der neuen Domäne anmelden kann, ist alles in Butter. Das geht nicht. Der globale Katalog kann ausschließlich auf einem Domänencontroller und nicht auf einem Mitgliedsserver aktiviert werden. Während der ADMT Migration müssen die involvierten DCs, beider Domänen erreichbar sein. Quell- sowie Ziel DCs müssen online und erreichbar sein.

Off-Topic:Das hast du aber schön geschrieben Günther ;) @mr.toby Falls doch noch Fragen offen bleiben, melde dich.

Die Kennwörter, die von ADMT generiert werden, sind ohnehin nur als Startkennwörter gedacht. ADMT stellt die Option "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" ein. Du kannst aber auch die Kennwörter migrieren. Dazu ist allerdings mehr an Arbeit zu tun. Informiere dich im Zusammenhang mit ADMT über den Password Export Server (PES) Service. Die SIDHistory benötigt man im Prinzip in der Migrationsphase. Wenn sich der Benutzer bereits in der neuen Domäne befindet und er auf Ressourcen in der "alten" Domäne zugreifen möchte, dann greift die SIDHistory. Allerdings sollte daran gedacht werden, wenn die Migration abgeschlossen ist, die SIDHistory zu bereinigen, denn bei weiteren Migrationen in der Zukunft, kann die SIDHistory zum Verhängnis werden.

Der Agent ändert die Berechtigungen lokal. Der Benutzer muss lediglich nach der Migration bei der Anmeldung im Feld "Anmelden an" die neue Domäne auswählen und kann sich dann wie gewohnt anmelden und findet sein "altes" Profil wieder.

Die werden dir auch nichts genaueres sagen. Nein, mit Sicherheit nicht! Ich schrieb bereits, die Tools brauchen nach RTM noch eine gewisse Zeit bis diese erscheinen. Nur Geduld... Ich würde bereits jetzt konsolidieren und dann erst auf Windows Server 2008 aktualisieren.

Moin, das war eines der meist gefragten Fragen, wenn nicht sogar DIE am meisten gefragte Frage auf dem Launch, die mir gestellt wurde. Erfahrungsgemäß werden diverse Tools nach ca. 90 Tagen nach dem Launch veröffentlicht. Seitens Microsoft ist davon bisher nichts zu hören, ich persönlich rechne aber sehr stark damit, dass das ADMT für den Windows Server 2008 erscheinen wird. Ich halte es sogar für zwingend, denn ich war verwundert, wieviele Unternehmen noch NT-Netze betreiben. Yepp, so ist es. Da hilft nur warten.

Servus, aus der alten Domäne wird nichts mitgenommen. Lediglich die "alte" SID wird im Attribut SIDHistory des neuen Benutzerobjekts, in der neuen Domäne hinzugefügt. Wenn die neue Domäne bereits soweit vorbereitet wurde... Also in einer neuen Domäne bzw. neuer Gesamtstruktur (da in einer Gesamtstruktur ja nur eine Exchange Org existieren kann) dann könnte/sollte dies funktionieren. Ich kann es aber nicht 100%ig beantworten... Das Vergnügen hatte ich bisher auch noch nicht.

Moin, ich habe zwar die Anforderung nicht ganz verstanden, aber sei es zunm erstellen neuer Benutzerkonten oder zum hinzufügen von Telefonnummern zu bestehenden Benutzerkonten... beides erreichst du z.B. mit LDIFDE. Yusuf`s Directory - Blog - LDIFDE - LDAP Data Interchange Format Data Exchange Möchtest du mit Excel arbeiten, dann bist du auf CSVDE angewiesen. Das hat aber den Nachteil, dass du mit CSVDE nicht bestehende Benutzerkonten bearbeiten kannst. faq-o-matic.net » Importdateien für CSVDE.exe einfach generieren faq-o-matic.net » Excel: Admins unbekannter Liebling

Dann führe das auch bitte so aus. Die Migration mit ADMT ist eine einfache Variante, die jeder schnell begreift. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Wenn keine andere Maschine zur Verfügung steht... ja, dann würde man es so machen. Oder mit Hilfe einer VM. Bei der Migration mit ADMT wird eine Namensauflösung und eine Vertrauenesstellung benötigt. Falls das Domänen-Admin Kennwort BEIDER Domänen gleich lautet, funktioniert es sogar ohne eine Vertrauensstellung. Aber du solltest einen Trust auf alle Fälle einrichten. Das ADMT richtet ein neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos, aus der alten Domäne an das neuen Benutzerkonto der neuen Domäne als SID-History hinzu. Damit kann das neue Benutzerkonto die alte SID als "Ausweis" vorzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt. Lies im o.g. Link die Whitepaper zu ADMT durch.

Servus, regelmäßig. Wer das SO macht, gehört "geteert und gefedert" (um nicht zu sagen "gesteinigt"). Diese Vorgehensweise ist ein klares "NO GO!" Die ganzen Kennwörter der Benutzer- Computer- sowie Dienstkonten werden mit übernommen. Vorallem ist dieser Weg aus Sicherheitssicht, der gefährlichste, falscheste und vorallem fehlerhafteste. AD-technisch wäre das mehr oder weniger eine "Vergewaltigung"! Der eine Standort MUSS in eine neue Domäne (z.B. mit ADMT) migriert werden. Es führt daran kein Weg vorbei. P.S. Notiz an mich: Nun wird es auch mal Zeit über dieses Thema einen Artikel zu verfassen, da diese Frage zu oft kam.

Aloha, dann funktioniert die AD-Replikation weiterhin, aber DU bist dann für diese Verbindung verantwortlich. Bei etwaigen Problemen versucht der KCC (bei der Inter-Site Replikation ist der ISTG dafür zuständig, ein Prozess das zum KCC gehört) das Problem schnell und bestmöglich zu lösen. Der Mensch reagiert i.d.R. langsamer als der KCC. Es sei denn es werden teure Monitoring-Tools (oder Microsoft-Tools) eingesetzt und der Admin macht nichts weiter, als den lieben langen Tag auf den Monitor zu schauen. Nein, bringt es auch nicht. Die AD-Replikation ist an für sich ein robuster Vorgang. Das sieht man schon daran, dass eine 56KB-Leitung für die AD-Replikation ausreichen würde. Die Replikation würde dann eben länger brauchen.

Servus, nein, dass funktioniert ohne Probleme. Es wäre nur in einem bestimmten Szenario etwas zu beachten. Wenn der erste 64Bit R2-DC zur Domäne hinzugefügt werden sollte, dann müsste für die Schemaerweiterung ein besonderer Augenmerk geworfen werden. Beachte dazu in diesem Artikel den Abschnitt: "Erster Windows Server 2003 R2 64 Bit Domänencontroller in einer Windows Server 2003 32 Bit Domäne" Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Moin, die sehen sehr gut aus ;) . Da die Gruppenrichtlinien im SYSVOL-Verzeichnis des DCs gespeichert sind, werden diese selbstverständlich durch die NTFRS-Replikation auf die anderen DCs repliziert. Genau so sieht es aus. Wirf auch noch einen Blick in diesen Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Dieses Ziel erreichst du dann mit servergespeicherten Profilen. Yusuf`s Directory - Blog - Profile (lokal/servergespeichert) Wir sind ja bei dir ;) .