Win2K3 DC ersetzen & ADS Benutzer zusammensammeln

[Volker Racho 10]

Unser Unternehmen heisst mit im Netz 'http://www.unternehmen-ort.de', weil der 'unternehmen'-Teil des Names zu generisch ist und durch einen Ort näher definiert wird, also z.B. statt 'kirche.de' besser mit 'kirche-ort.de' bezeichnet wird. Trotz des übergeordneten Namens ('kirche') haben die Unternehmen dieses Namens von Ort zu Ort aber gar nichts miteinander zu tun, sondern sind eigenständige, unterschiedliche Unternehmen. Daher die AD-Namenswahl.

 

So, nu aber ...

Dir auch ein schönes, erholsames Wochenende!

MD

[Volker Racho 10]

Hallo Yusuf!

 

Übers Wochenende ist mir - natürlich - noch eine (Verständnis-)Frage eingefallen.

Ich habe gelernt, dass Active Directory nicht ohne DNS funktioniert.

Jetzt habe ich aber auf den (virtuellen) MSL-Testsystemen (DC1 - 1. Domaincontroller der Domäne; DC2 - Weiterer DC der Domäne; WinXP-Client), dass nur der DC1 DNS & AD hat, der DC2 nur AD und den DC1 als DNS-Server eingetragen hat, ebenso der XP-Client den DC1 als DNS-Sever eingetragen hat. In der Testumgebung funktioniert das ja auch gut.

 

 

Meine Zusatzfrage daher:

 

Bezogen auf meine geplante Struktur, jedem Standort (Einrichtung) einen eigenen IP-Bereich zu verpassen und die jetztigen Forrest-Server zu normalen, weiteren DCs der neuen Domäne zu degradieren, der (s)einen IP-Bereich verwalten soll (also: (1.) DC1 - 192.168.0.*; DC2´- 192.168.1.* usw.), ist die Frage, ob jeweils jeder dieser "neuen" DCs auch einen DNS-Server installiert haben muss, der seinen Bereich abdeckt.

 

Damit würde der Anmeldeverkehr an der Domäne doch in dem IP-Wirkungsbereich des jeweiligen (DNS)DCs bleiben, wenn ich allen Clients in diesem IP-Bereich den entsprechenden DC als DNS-Server eintrage (alternativ dazu dann doch noch den (1.) DC1 der Domäne)? Dennoch könnte sich jeder Nutzer irgendwo an irgendeiner Arbeitsstation in der Domäne (an irgendeinem "weiteren DC) anmelden.

 

Ich hoffe, die Frage ist nicht zu wirr gestellt.

 

Gruß,

MD

[Daim 12]

Übers Wochenende ist mir - natürlich - noch eine (Verständnis-)Frage eingefallen.

 

Na sowas aber auch, dann sollten wir die Wochenenden abschaffen :p .

 

Ich habe gelernt, dass Active Directory nicht ohne DNS funktioniert.

 

Richtig gelernt. Aber genau genommen, würde das AD auch ohne DNS funktionieren, man könnte es dann aber sehr schwer ansprechen. Aber ist eine andere Nummer.

Die Devise, dsas das AD ohne DNS nicht läuft, kann man stehen lassen (obwohl es technisch aber möglich ist).

 

 

der DC2 nur AD

 

Das geht natürlich nicht. Als Faustregel gilt, auf jedem DC sollte immer das DNS mit installiert werden und die FLZ sollte eben AD-integriert gespeichert sein.

Ergo, installiere auf dem DC2 noch das DNS und warte die Replikation ab.

 

 

ob jeweils jeder dieser "neuen" DCs auch einen DNS-Server installiert haben muss, der seinen Bereich abdeckt.

 

Wie gesagt, jeder DC sollte ohnehin zwecks Redundanz auch das DNS installiert bekommen.

Da deine Struktur am Ende eine Single-Domänen Forest darstellt, existiert in deinem DNS lediglich eine Forward Lookup Zone die eben auf allen DCs/DNS-Server repliziert wird.

 

 

Damit würde der Anmeldeverkehr an der Domäne doch in dem IP-Wirkungsbereich des jeweiligen (DNS)DCs bleiben, wenn ich allen Clients in diesem IP-Bereich den entsprechenden DC als DNS-Server eintrage (alternativ dazu dann doch noch den (1.) DC1 der Domäne)?

 

Jeder Client versucht sich an einem DC, der in seinem Standort steht anzumelden.

Daher ist es wichtig, im AD "Standorte" zu erstellen und die jeweiligen DC-Icons dann auch an ihre entsprechenden Standorte zu verschieben. Denn dann tragen sich die DCs mit ihren SRV-Records im DNS für den entsprechenden Standort ein. Dadurch findet der Client im DNS - seinen - DC.

 

Yusuf`s Directory - Blog - Domänencontroller am Standort

 

 

Dennoch könnte sich jeder Nutzer irgendwo an irgendeiner Arbeitsstation in der Domäne (an irgendeinem "weiteren DC) anmelden.

 

Selbstverständlich. Der Client macht zuerst einen DNS-Lookup an seinem Standort der so aussieht: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>.

Bekommt er darauf keine Antwort, sendet er dem nächsten Lookup diesmal nicht explizit an seinen Standort, sondern diesmal an die Domäne. Die Abfrage würde folgendermaßen lauten: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>.

 

 

Ich hoffe, die Frage ist nicht zu wirr gestellt.

 

Ich denke, wir sollten doch die Wochenenden abschaffen, dann kommst du nicht so sehr in Verlegenheit, so viel nachdenken zu müssen :D .

[Volker Racho 10]

Na ja, da die Wochenenden ohenhin zunehmend schrumpfen, könnten sie eigentlich wirklich wegfallen. Auffallen würd's mir jedenfalls kaum. Momentan fallen mir noch tausend Eventualitäten ein, die ich noch abchecken will, bevor ich loslege.

 

Okay, dann habe ich die Systematik jetzt richtig verstanden und verinnerlicht. Dein Blog ist wirklich eine Goldgrube. Aber das Problem mit dem Gold ist ja hinlänglich bekannt: Wo genau muss man suchen?

 

 

Besten Dank!

MD aka Holger

[Volker Racho 10]

So,

nach längerem Überlegen ist mir doch noch ein Haken - oder vielmehr eine Herausforderung eingefallen. Vielleicht gähnt darüber auch der ein oder andere ... Jedenfalls wäre es nett, wenn mir dabei jemand - schon wieder - weiterhelfen könnte:

 

Ich möchte ja die Benutzer mittels des ADMT 3.0 von einer alten Domäne (hier: kirche-ort) in eine neue (hier: intranetkirche-ort.de) überwechseln (s. Bild). Der neue Server ist aufgesetzt und standby. Jetzt ist es aber so, dass beide ganz unterschiedliche IPs haben (-> an DNS gekoppelt -> an AD gekoppelt). Der alte hat - in gruer Vorzeit mal festgelegt - die IP 172.16.1.3 der neue soll die 192.168.0.3 haben. Jetzt ist es aber so, dass diese beiden Server sich dann aber nicht "sehen", bzw. auch keine Daten austauschen können. Wie bewerkstellige ich damit denn jetzt meine Benutzer/Computerkontenmigration?

 

 

Folgende Möglichkeiten fallen mir ein, aber welche ist die richtige?

 

01. Einen Router zwischen die beiden Server klemmen?

 

02. Den neuen Server mit zwei Netzwerkkarten ausstatten und eine für das 172er-Netz, die andere für das 192er-Netz einrichten udn Routing aktivieren?

 

03. AD ohne DNS aufsetzen, dem neuen Server kurzzeitig eine 172er IP geben und DNS nach der Migration im Nachhinein konfigurieren?

 

04. Den alten Server vom Netz nehmen, die DNS und IP-Einstellungen nach 192er-IP ändern und dann die Nutzer migrieren?

 

Oder, wie machend as die Profis?

 

 

Zusatzfrage:

 

Nach der Umstellung auf die neue Domäne und die neuen IP-Bereiche, können sich die Clients ja erst wieder an der Domäne anmelden, wenn sie ein neues Vertrauenskonto in der Domaine haben. Dazu habe ich es bisher so gemacht, dass die Rechner aus der Domaine raus (-> Arbeitsgruppe) und dann wieder (in die neue) hinein genommen werden, damit das neue Vertrauenskonto erstellt wird.

Nun sind es aber ca. 40 Rechner mit denen ich das durchziehen müsste, zudem müsste ich die Benutzerprofile ja auch nach Anmeldungd an der neuen Domaine wieder einrichten oder zumindest wieder einspielen.

 

Geht das irgendwie anders schneller? Vielleicht über eine Sammeleinrichtung anhand der ausgelesenen SIDs der Clientrechner o.ä.?

 

 

Danke für Eure Hilfe vorab!

MD

[Daim 12]

Servus,

 

Der alte hat - in gruer Vorzeit mal festgelegt - die IP 172.16.1.3 der neue soll die 192.168.0.3 haben.

 

gib doch dem neuen Server vorübergehend, während der Migration eine IP-Adresse aus dem Bereich 172.16.x. Wenn die Migration angeschlossen ist, kannst du die IP-Adresse dann ja ändern.

 

 

03. AD ohne DNS aufsetzen, dem neuen Server kurzzeitig eine 172er IP geben und DNS nach der Migration im Nachhinein konfigurieren?

 

Wie willst du auf dem neuen Server das AD installieren ohne DNS?

Das DNS ist für das AD elementar.

 

 

04. Den alten Server vom Netz nehmen, die DNS und IP-Einstellungen nach 192er-IP ändern und dann die Nutzer migrieren?

 

Das kannst du auch machen.

 

 

Geht das irgendwie anders schneller?

 

Eieieiii.... dann hast du aber das Prinzip von ADMT noch nicht verstanden.

Genau das ist doch der Vorteil von ADMT. Du migrierst im ersten Schritt das Benutzer- und im zweiten das Computerkonto. Somit bleiben dir also alle Profile erhalten.

Der Benutzer schaltet dann seinen Client aus der alten Domäne aus, baut ihn in der neuen Domäne auf, fährt den Client hoch und meldet sich mit seinen Benutzerdaten an.

Alles sieht für den Benutzer dann so aus, wie vorher.

 

Bei der Migration mit ADMT legt das Tool einen neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos aus der alten Domäne, an das neue Benutzerkonto der neuen Domäne als SIDHistory hinzu.

 

Das Benutzer- sowie Computerkonto wird in der neuen Domäne während der Migration mit ADMT automatisch erstellt.

[Volker Racho 10]

Hallo Daim!

 

Wie immer gute und sehr hilfreiche Antworten von Dir.

Den ersten Teil habe ich verstanden. Du weißt alles , oder?

 

AD ohne DNS geht nicht wirklich, richtig, aber man kann bei der Installation ja sagen "Ich kümmere mich später drum" und macht dann erstmal weiter. Aber das ist ja hinfällig. Dass DNS und AD immer nur zusammen funktionieren, ist verstanden. MS sagt ja, dass 90% aller AD-Probelme eigentlich DNS-Probleme sind.

 

 

Achso,

ich hatte es so verstanden, dass ADMT mir nur die Nutzer migriert, aber nicht wirklich die Client(rechner), die sich dann ja - zurückgelassen - in der dann evtl. nicht mehr exitenten Domäne befinden an der sie sich dann stetig versuchen erfolglos anzumelden.

 

Also bleiben mir auch auf beiden Servern, in beiden Domänen die Nutzer erhalten?

Quasi kann also dann ein Benutzer Mitglied in zwei Domänen sein, auf der alten mit seiner ursprünglichen ID und auf dem neuen mit seiner alten und neu generierten ID? Nehme ich dann die alte Domäne (resp. DC) ausser Betrieb, ist das dem Client egal, weil er sich dann einfach an der (übrig gebliebenen) neuen Domain anmeldet? Habe ich das richtig verstanden?

 

Das ist ein Thread in dem ich wiedre viel gelernt habe.

 

 

Beste Grüße & Dank,

MD

[Daim 12]

Wie immer gute und sehr hilfreiche Antworten von Dir.

Den ersten Teil habe ich verstanden. Du weißt alles , oder?

 

Nee... ich weiß natürlich auch nicht alles. Vielleicht ein bisserl mehr als andere ;) .

 

 

AD ohne DNS geht nicht wirklich, richtig, aber man kann bei der Installation ja sagen "Ich kümmere mich später drum" und macht dann erstmal weiter.

 

Dieses "...und macht erstmal weiter" bedeutet aber in deinem konkreten Fall, dass du anfängst mit ADMT zu migrieren. Genau dabei wirst du aber dann Probleme bekommen.

 

 

MS sagt ja, dass 90% aller AD-Probelme eigentlich DNS-Probleme sind.

 

...wenn nicht, sogar noch höher.

 

 

ich hatte es so verstanden, dass ADMT mir nur die Nutzer migriert, aber nicht wirklich die Client(rechner), die sich dann ja - zurückgelassen - in der dann evtl. nicht mehr exitenten Domäne befinden an der sie sich dann stetig versuchen erfolglos anzumelden.

 

Dann wäre das Tool ja nutzlos. Denn das Benutzer-Profil, das meistens lokal auf dem Client liegt, hängt natürlich auch vom Computerkonto ab. Wenn nur die Benutzerkonten migriert werden könnten, dann könnte man x-beliebige andere Tools dazu verwenden, wie z.B. CSVDE, LDIFDE etc. Damit habe ich auch recht schnell neue Benutzer erstellt.

 

Nenee... das ADMT macht schon mehr. Genau das richtige Werkzeug, für eine Migration.

 

 

Also bleiben mir auch auf beiden Servern, in beiden Domänen die Nutzer erhalten?

 

Teste das mit einem Test-User an einem Test-PC aus. Ich "meine" der Benutzer wird aus der Quelle entfernt, bin mir aber gerade nicht sicher.

 

 

Quasi kann also dann ein Benutzer Mitglied in zwei Domänen sein, auf der alten mit seiner ursprünglichen ID und auf dem neuen mit seiner alten und neu generierten ID?

 

Wie gesagt, wenn ich recht der Annahme gehe, dann wird der Benutzer aus der Quelle entfernt.

In der Ziel-Domäne wird ein neues Benutzer-Objekt mit einer neuen SID erstellt und in das Attribut SID-HISTORY des neuen Benutzer-Objekts, wrd die "alte" SID (vom Benutzer-Objekt aus der Quell-Domäne) hinzugefügt. Wenn nun der Benutzer auf eine Ressource in der Quell-Domäne zugreifen wollte, zückt das neue Benutzerkonto sie "alte" SID aus der SIDHistory und erhält somit Zugriff.

 

Im übrigen ist diese SID-History Variante nur für den Übergang, genauer, während einer Migration gedacht und nicht für die Ewigkeit.

 

 

Nehme ich dann die alte Domäne (resp. DC) ausser Betrieb, ist das dem Client egal, weil er sich dann einfach an der (übrig gebliebenen) neuen Domain anmeldet? Habe ich das richtig verstanden?

 

Klar, wenn das Benutzerkonto samt Computerkonto in die neue Domäne migriert wurde,

spielt für diesen Benutzer, die alte Domäne bezgl. der Authentifizierung (Domänenanmeldung) keine Rolle mehr. Während der Migration, die ja auch in größeren Umgebungen Monate dauern kann, befindet sich nun der Benutzer in der neuen Domäne und muss aber noch auf die Freigaben in der alten Domäne zugreifen. Das erschlägt man eben durch die SID-History.

 

 

Das ist ein Thread in dem ich wiedre viel gelernt habe.

 

Jawollja, jeden Tag immer etwas mehr ;) .

[Volker Racho 10]

Hallo!

 

Jetzt wird es langsam konkret und ich teste mal und - natürlich - gibt es schon Probleme mit dem Testnutzer.

 

01. Es besteht über einen Switch eine psysikalische LAN-Verbindung zwischen den beiden Servern (*.9 und *.10) bzw. Domänen ('domäne' und 'intranet.domäne-ort.de')

 

02. Die gegenseitige Vertrauensstellung ist bei beiden Servern eingerichtet.

 

03. Funktinierende Namensauflösung. Mit nslookup zeigen beide die richtigen Namen an. Ich kann mir gegenseitig die DNS-Server ins DNS-MMC holen. Die Ereignisanzeige zeigt keine Fehler an.

 

04. Die Admins beider Rechner/Domänen heißen gleich, haben das gleiche Kennwort und sind Domainadmins.

 

05. Wechsel des "alten Server" in den einheitlichen 2003er-Modus wird immer angzeigt "Es konnte nicht gewechselt werden, da der Verzeichnisdienst ausgelastet ist."

 

 

Im ADMT 3.0 (auf dem Quellserver) wird mir folglich auch die Quelledomäne und der dazugehörige DC angezeigt, auch die Zieldomäne ist schon richtig, aber nicht der DC ('beliebiger').

 

 

Was mache ich falsch?

MD

[Daim 12]

01. Es besteht über einen Switch eine psysikalische LAN-Verbindung zwischen den beiden Servern (*.9 und *.10) bzw. Domänen ('domäne' und 'intranet.domäne-ort.de')

 

Ich hoffe doch sehr, dass die eine Domäne nicht einen einfachen Namen, als lediglich "Domäne" hat,

sondern einen echten FQDN mit mindestens einem Punkt dazwischen (z.B. Domäne.TLD).

 

 

05. Wechsel des "alten Server" in den einheitlichen 2003er-Modus wird immer angzeigt "Es konnte nicht gewechselt werden, da der Verzeichnisdienst ausgelastet ist."

 

Warum möchtest du denn die "alte" Domäne in den einheitlichen Modus bringen?

Entscheidend ist doch die Ziel-Domäne für die Migration mit ADMT.

Abgesehen davon, würde ich etwas warten und das heraufstufen erneut versuchen.

 

Du kannst auch versuchen, den Domänen- bzw. Gesamtstrukturfunktionsmodus durch bearbeiten (mit LDP.exe oder ADSIEdit.msc)

des Attributs msDS-Behavior-Version heraufzustufen.

 

Für den Gesamtstrukturfunktionsmodus ist im Attribut "msDS-Behavior-Version", dass sich im folgenden Pfad befindet

<CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> als Wert 2 einzutragen.

 

Für den Domänenfunktionsmodus ist im Attribut "msDS-Behavior-Version", dass sich im folgenden Pfad befindet

<DC=DeineDomäne,DC=Root-Domäne,DC=TLD> als Wert 2 einzutragen.

[Volker Racho 10]

Hallo Daim!

 

Doch, die "Altlast"-Domäne heißt schlicht 'NETZWERK'. Jetzt soll es ein neuer FQDN werden -> intranet.kirche-ort.de.

 

Lt. dem faq-o-matic.net steht der Wechsel in eine einheitlichen Modus das dort als Vorraussetzung, damit ADMT überhaupt arbeiten kann. Bei der Zieldomäne hat das Heraufstufen anstandslos geklappt, nur bei der Quelldomäne klappt's nicht. Auch nach 3 Stunden nicht.

 

Für den Gesamtstrukturfunktionsmodus ist im Attribut "msDS-Behavior-Version", dass sich im folgenden Pfad befindet

<CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> als Wert 2 einzutragen.

 

Wenn ich dort "2" eintrage und bestätige, bekomme ich die Fehlermeldeung: "Der FSMO-Funktionsbesitz konnte nicht überprüft werden da die zugehörige verzeichnispartition nicht mit mind. einem Replikationspartner repliziert wurde." (?)

 

Für den Domänenfunktionsmodus ist im Attribut "msDS-Behavior-Version", dass sich im folgenden Pfad befindet

<DC=DeineDomäne,DC=Root-Domäne,DC=TLD> als Wert 2 einzutragen.

 

Diese Einstellung findet sich beim Quellserver nicht.

 

Warum ist das bloß immer alles so komplex...?

[Daim 12]

Doch, die "Altlast"-Domäne heißt schlicht 'NETZWERK'. Jetzt soll es ein neuer FQDN werden -> intranet.kirche-ort.de.

 

Aha, dass hatten wir ja schon. Stichwort: Single-Label DNS-Domänenname.

 

 

Lt. dem faq-o-matic.net steht der Wechsel in eine einheitlichen Modus das dort als Vorraussetzung, damit ADMT überhaupt arbeiten kann.

 

Das wüßte ich aber, denn den Artikel habe ja ich geschrieben.

Es muss sich lediglich die ZIEL-Domäne im einheitlichen Modus befinden.

 

 

Wenn ich dort "2" eintrage und bestätige, bekomme ich die Fehlermeldeung: "Der FSMO-Funktionsbesitz konnte nicht überprüft werden da die zugehörige verzeichnispartition nicht mit mind. einem Replikationspartner repliziert wurde." (?)

 

Hattest du ADPREP ausgeführt? Falls ja, dann warte einen Tag.

Es könnte aber auch ein Problem mit dem DNS bestehen bzw. es besteht ein Replikationsproblem.

 

Siehe:

Erforderliche Erstsynchronisierung für Windows 2000 Server- und Windows Server 2003-Domänencontroller, die Inhaber von Betriebsmasterfunktionen sind

 

Überprüfe das Eventlog und führe DCDIAG sowie NetDIAG durch und kontrolliere was alles als FAILED angezeigt wird.

 

 

Diese Einstellung findet sich beim Quellserver nicht.

 

Doch, tut es. Dann schaust du an der falschen Stelle ;) .

 

 

Warum ist das bloß immer alles so komplex...?

 

Weil es dann ja jeder könnte ;) .

[Volker Racho 10]

Hallo Daim!

 

Stimmt natürlich. Die Ziel-Domäne ist astrein Win2K3. Kunststück ist auch ermal nur ein Server.

 

Nein, Adprep hatte ich nicht ausgeführt.

 

DCDiag und NetDiag geben auf beiden Servern keine Fehler aus. Alles ist 'passed', 'succesful' oder 'skipped' (z.B. IP Security).

Die Ereignisprotokolle zeigen keine Fehler oder Warnungen.

Beide Server sind pingbar und man sieht sie in der Netzwerkumgebung. Ich kann mir jeweils beide Server ins DNS-MMC/AD-MMC holen und abfragen.

nslookup zeigt die richtige Bezeichnungen für die Server an.

 

Weiterhin zeigt das ADMT-Tool mir aber bei der Auswahl des zweiten DC nur <beliebiger Domaincontroller> an und sagt, die Domäne könne nicht gefunden werden (Fehlercode 1355, Domäne: INTRANET)

INTRANET taucht hier als gewählter NETBios-Name auf. Bei der AD-Einrichtung wurde aber intranet.kirche-ort.de anegegeben. Die DNS-Einträge sind dementsprechend (intranet.kirche...). Liegt darin evtl. der Fehler?

 

Abschliessend habe ich nochmal adprep/domainprep durchgeführt. Aber es war schon alles aktualisiert. Ebenso /forestprep.

 

??....

 

 

P.S.: HAst Du so ne Art Amazon-Wunschliste?

[Daim 12]

Weiterhin zeigt das ADMT-Tool mir aber bei der Auswahl des zweiten DC nur <beliebiger Domaincontroller> an und sagt, die Domäne könne nicht gefunden werden (Fehlercode 1355, Domäne: INTRANET)

 

Eieieiiii... das ADMT ziert sich aber ganz schön, es kann aber nicht mehr viel sein ;) .

Wenn ich es richtig in Erinnerung habe, hast du das ADMT in der Quell-Domäne installiert?

Falls ja, installiere doch mal das ADMT in der Ziel-Domäne und füge den Domänen-Admin aus der Ziel-Domäne, auf einem Test-Rechner in die lokale Gruppe der Administratoren.

Anschließend versuche eine Test-Migration und kontrolliere ob es funktioniert.

 

Gehe aber zusätzlich nochmals das Whitepaper zu ADMT durch, was du sicherlich schon gemacht hast, aber ein zweitesmal schadet nicht ;).

 

Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

 

 

INTRANET taucht hier als gewählter NETBios-Name auf. Bei der AD-Einrichtung wurde aber intranet.kirche-ort.de anegegeben.

 

Der Name "intranet.kirche-ort.de" ist der DNS-Name der Domäne, aber nicht der NetBIOS-Name der Domäne. Denn der NetBIOS-Name einer Domäne kann lediglich 15 Zeichen lang sein. Der DNS-Name meiner eigeneen Domäne lautet "intra.dikmenoglu.de", der NetBIOS-Name lautet aber "Dikmenoglu".

 

Das kann aber auch lediglich ein Anzeigefehler sein, wie er z.B. bei einer AD-Suche ebenfalls erscheint. Es wird dann als Domäne lediglich das erste Oktett vom DNS-Namen der Domäne angezeigt.

 

 

Die DNS-Einträge sind dementsprechend (intranet.kirche...). Liegt darin evtl. der Fehler?

 

Mit Sicherheit nicht.

 

 

Abschliessend habe ich nochmal adprep/domainprep durchgeführt. Aber es war schon alles aktualisiert. Ebenso /forestprep.

 

Das war auch unnötig. Mir fehlte nur der Überblick was du bisher getan hattest bzw. von wo/was nach wo/was migriert wird.

 

 

P.S.: HAst Du so ne Art Amazon-Wunschliste?

 

Klar habe ich die, wer hat die nicht.

Aber ich führe meine Wunschliste immer selbst aus. Danke der Nachfrage.

Lass uns eine Cola bei einem Treffen (evtl. auf dem 2008er Launch?) trinken und gut ist ;) .

[Volker Racho 10]

So,

umgekehrt habe ich hetzt genau das gegenteilig logische Problem: Der Server der Zieldomäne und der entsprechende DC ist erreichbar, ebenso die Quelldomäne, aber nicht der dazugehörige DC. Die Fehlermeldung hier ist aber eine andere, wenn ich <beliebiger DC> stehen lasse: "ADMT konnte keine Verbindung zum DC \\server.domäne in der Domäne NETZWERK herstellen . Der Netzwerkpfad wurde nicht gefunden (0x80070035)."

 

Ich sehe mich schon die Rechner wieder einzeln einbinden ...

 

Der Blogeintrag liegt hier und wird zig Male am Tag angesehen. Bringt aber leider nix, da ich nicht über die Zündstufe 1 hinauskomme.

 

Gibt es irgendwelche Dienste, die zwingend gestartet werden müssen? Der Ziel-Server ist ein x64-er System mit Win2K3 x64 Std; der Quellserver ein normale Win2K3 auf einer x32er Maschine. Die beiden sehen sich, können gemeinsam in die MMCs gebracht werden, tauschen munter Daten aus, aber Benutzer migrieren lassen wollen sie mich nicht. Grrr.

 

Hast Du noch Ideen?

 

Gruß,

MD

 

Bzgl. Amazon-Liste: Da steht bei Dir ja auch recht wenig drauf. Ich selber mache die Betreuung für einige Internetforen und -seiten und da freut mich auch immer, wenn jemand mal "Danke" sagt. Ausserdem ist es ja auch nicht selbstverständlich, dass ein Experte einem mehrkostenfrei sein Wissen als Serviceleistung anbietet.