Parallelmigration von NT4 auf 2003 AD

[schroeder750 10]

... ach ja, einen hammwer noch:

 

spricht eigentlich was dagegen, die NT4-Memberserver überhaupt noch in einer reinen AD-Umgebung einzusetzen? Sicherheitsproblem in der AD, Kompatibilität, Störung?

 

Windows 2003 AD geht mal kackfrech davon aus, daß keine älteren Clients (und das wäre ein NT4 Memberserver dann ja) mehr in der Domäne sind und erfordert z.B. eine erhöhte Sicherheit (digitale Signierung) von den Clients.

Das müsste dann wieder abgeschaltet werden...

 

Und nochwas zum native mode:

 

Du MUSST spätestens dann in den native mode gehen, wenn Du mit dem ADMT die User migrieren willst. Der native mode ist immer eine meiner ersten Amtshandlungen bei der Parallelmigration, das macht definitiv keine Probleme, glaubs mir :D

 

Jetzt schreib am Besten erstmal wieder an Deinem Projektplan weiter und arbeite die Sachen hier ein, ich denke, dann werden sich evtl. weitere Fragen ergeben.

 

Ist das O.K. so, wie es gerade läuft ?

Hilft Dir das so gut weiter ?

 

Grüsse

 

schroeder750

[Coyote 10]

Kurze Antwort: habe "movedom" bisher noch nicht getestet... :D

Habe da viel per Hand gemacht / machen lassen, da oft eh aus anderen Gründen die PCs angefasst wurden...

 

d.h. aus meiner Sicht wäre das echt eine alternative, da ich somit alte Rechner, die nicht mehr verwendet werden (verschrottet, aber nicht aus der Domäne genommen) nicht mehr migriere (weniger Müll in der neuen Domäne) und die Notebook-Mitarbeiter, welche selten im Haus sind, somit auch automatisch verschiebe. Was ist deine Erfahrung, gerade was Notebooks betrifft, die in der Migrationsphas evtl. längere Wochen/Monate sich nicht im Haus befinden und du endlich die die Migration abschließen willst (alte NT-Server killen)

 

 

Du wirst von mir KEINE Bestätigung hören, daß man sich eine Testumgebung sparen sollte ... sorry. In der Theorie ist das alles immer klar und wunderbar, in der Praxis spuckt Dir immer irgendwas in die Suppe...

Die neue, parallele Umgebung ist nur anfangs sowas wie eine Testumgebung. Sobald da der erste produktive Server oder Client drin ist, fährst Du da auch nicht mal eben locker alles runter und wieder rauf, weil Du testen willst.

Schnapp Dir einfach einen modernen Rechner (popeliges IDE-Teilchen) mit etwas mehr RAM und geh das da in Ruhe durch. Der Rechner wird ja nachher wieder frei und kann für einen User eingesetzt werden oder sonstiges. Wenn Cheffe da kein Geld für locker macht, obwohl Du ihm die Notwendigkeit fachlich erläutern kannst, dann ist er echt mutig ... :D

Das sollte schon sein...

 

Du hast natürlich Recht, dachte einfach zu optimistisch, dass alles auf Anhieb klappen würde, aber ich werde deinen Rat beherzigen und den Cheff das auch so reindrücken.

 

... dann saug einen NT4 BDC aus der produktiven Umgebung als VM-Maschine ab und mach damit die "virtuelle Testumgebung" auf (Abnabeln von der Echtumgebung, Hochstufen zum PDC usw...). Anschließend bringst Du hier einen weiteren BDC rein, der so heißt wie der jetzige PDC. Den kannst Du hochstufen zum PDC und dann den Exchange 5.5 draufnageln. Schon passt das wieder, auch mit den Datenbanken :D

 

Sehe ich das Vorhaben so richtig:

 

Server in der Echtumgebung:

PDC+Exchange (Hostname=mail)

BDC(Hostname=bdc)

 

VM-Umgebung:

neu BDC in der alten NT4-Domäne(Hostname=bdc2) -> trennen vom echten Netz nehmen

hochstufen zum PDC und Fehlermeldung ignorieren

neuen BDC in der VM-NT4-Domäne(Hostname=mail) -> hochstufen zum PDC -> Exchange 5.5 installieren

So, wie kriege ich die die Kommunikation jetzt mit dem Exchange 5.5 aus der echten Umgebung, ich mein das Netz darf ich nicht mehr verbinden, wegen Namenskonflikt des PDC?

 

 

Windows 2003 AD geht mal kackfrech davon aus, daß keine älteren Clients (und das wäre ein NT4 Memberserver dann ja) mehr in der Domäne sind und erfordert z.B. eine erhöhte Sicherheit (digitale Signierung) von den Clients.

Das müsste dann wieder abgeschaltet werden...

 

Dann lasse ich das lieber und sag dem Cheff nix, was möglich ist, sonst kommt er noch auf Ideen.

Was "native Mode" angeht, ich glaube ich bin jetzt schon beruhigt, vor allem werde ich das ja mit meinen eigenen Augen in der Testumgebung sehen.

 

so Projektplan erweitert :D

 

was würde ich bloß ohne Euch machen ;)

[schroeder750 10]

Moin Coyote,

 

soooo, hocke zu Hause am Schlepptop, nicht im stressigen Büro, mein Weibchen hat Ausgang, die Kiddies sind im Bett... was kann man in so einer ruhigen Minute besseres machen als im Board in Ruhe ne Antwort zu schreiben ? :)

 

 

Was ist deine Erfahrung, gerade was Notebooks betrifft, die in der Migrationsphas evtl. längere Wochen/Monate sich nicht im Haus befinden und du endlich die die Migration abschließen willst (alte NT-Server killen)

 

Das sind genau die Herausforderungen... eben deswegen ist es bei der Parallelmigration ja so eine feine Sache, daß man die alte NT4-Domäne so lange wie benötigt laufen lassen kann. Man muss halt nur zum Schluss bei den letzten Mohikanern irgendwann mal zu einem Ende kommen...

 

Mal ein paar Gedanken zu später Stunde dazu:

Was läuft so alles auf diesen Laptops ? - Was muss daher beachtet werden, wenn diese längere Zeit nicht greifbar sind, weil unterwegs und die User damit nur zwischendurch mal an die Domäne kommen ?

 

- Outlook / Exchange:

 

Die Postfächer werden zu einem späteren Zeitpunkt vom Exchange 5.5 sanft auf den Exchange 2003 migriert. Da Exchange 5.5 und Exchange 2003 gleichzeitig bestehen werden (zwecks rübermoven der Ressourcen) werden die beiden definitiv verschiedene Namen haben. Die Postfächer werden dann von alt auf neu verschoben. Meldet sich ein User nun laut seinen Outlook-Einstellungen am Exchange alt an, steht dieser Exchange, der ja nun das Postfach nicht mehr hält, mit einem Umleitungsschild da, welches auf den neuen Exchange verweist. Der Outlook-Client schnaggelt das und geht an den neuen Exchange. Praktisch ist dabei, daß er sich gleich den Namen des neuen Exchangeservers einträgt und ab dem nächsten mal nicht mehr den alten benötigt.

 

Ergo: alle Outlooks, die sich nach dem Verschieben des jeweiligen Postfachs einmal am neuen angemeldet haben, müssen nicht manuell umkonfiguriert werden. Das geht automatisch, da brauchst Du aktiv nichts dran zu machen. Da die öffentlichen Ordner schon auf den neuen repliziert wurden (und auch noch weiterhin werden) und die User des neuen Exchangeservers sich an den öffentlichen Ordnern der neuen Struktur laben, gibt es da auch keine Probleme.

 

Probleme gibt es nur, wenn der alte Exchange, von dem alle Postfächer auf den neuen verschoben wurden, nicht lange genug mit dem Umleitungsschild im Netz steht, das es alle Clients mitbekommen haben. Ist der alte Exchange erst einmal abgeschaltet und es existieren noch Outlooks mit Einträgen auf den alten, werden diese erst einmal vor die Wand fahren.

Hier gibt es grob zwei Möglichkeiten:

 

a) manuell umkonfigurieren der Outlooks auf den neuen Exchange oder

b) Setzen eines DNS-Alias, der beim Namen des alten Exchange auf die IP des neuen verweist. Die Verbindung funktioniert dann, der Eintrag im Outlook wird aber nicht geändert. D.h. wenn dann irgendwann der Alias wieder aus dem DNS genommen wird, fahren die Dinger wieder vor die Wand... man muss dann also letztendlich irgendwann doch händisch an diese Clients dran. Die Geschichte mit dem Alias ist eine Krücke, die einem während der Migration den Rücken freihalten kann, die aber auf Dauer nicht unbedingt weiterlaufen sollte... Gut geplant ist das kein Problem. Setze ich auch des Öfteren mal ein...

 

... weiter im nächsten Thread...

[schroeder750 10]

- Profile:

 

- Entweder der User meldet sich noch in der alten Domäne an und bekommt die Profile über diese Domäne und den NT4-Server, der hier läuft, oder er meldet sich eben in der neuen Domäne an und bekommt seine Profie von hier.

Wobei natürlich der Anmeldeserver aus der einen Domäne (neu oder alt) problemlos auf den Profilserver der anderen Domäne verweisen kann ... auch diese Spielart ist möglich...

 

Beispiel:

Die User melden sich in der alten Domäne an, ziehen die Profile vom Server "NT4Profiles".

Du sorgst dafür, daß die Rechner ziemlich zügig in die neue Domäne kommen, die User sich in der neuen Domäne anmelden. Was hindert Dich daran, auch aus der neuen Domäne heraus auf den alten Profilserver zu verweisen ? Die Berechtigungen ? Nö... die User wurden incl. SID-History migriert. Müller neu ist von den Berechtigunen her gleich Müller alt ...

 

O.K. irgendwann sind alle Benutzer in der neuen Domäne.

Dann machst Du eine Abendaktion, in der Du den Profilserver entweder

a) in der neuen Domäne neu auf W2K3 aufbaust und den gleichen Namen beibehältst oder b) einen neuen Profilserver mit anderem Namen (W2k3profiles) aufsetzt und die Profile rüberkopierst.

 

Im Fall b) müssen dann natürlich die Pfade für die Profile bei der Anmeldung auf den neuen Server "W2k3profiles" umgebogen werden.

 

Im Fall a) musst Du eventuell die Profile woanders zwischenparken und mit xcopy inclusive der Berechtigungen hin- und herkopieren. Auch machbar...

 

 

- Fileserverdaten / Freigaben:

 

Wenn Du bei der Migration der Fileserver darauf achtest, daß die neuen Server die gleichen Namen haben wie die alten, gibt es da keine Probleme. Evtl. Daten wieder irgendwo zwischenparken und mit xcopy incl. Berechtigungen kopieren...

 

Sollten die neuen Server neue Namen bekommen, müssen halt wieder entsprechend die Anmeldescripte angepasst werden, so daß die Clients halt wieder ihre richtigen Freigaben bekommen. Kritisch ist das hier bei hardgemappten Laufwerken, also die, die manuell verbunden wurden mit dem Häkchen "Verbindung beim nächsten Start wieder herstellen" ...

 

Generell gilt, wie schon einmal erwähnt aus meinen Erfahrungen heraus, daß man die Clients so früh wie möglich in die neue Domäne bringen sollte und dann auch darauf achtet, daß sich die User in der neuen Domäne anmelden. Das bringt bei der Outlook/Exchange-Verbindung die geringste innere Reibung mit sich. User in der alten Domäne anmelden und auf die Postfächer auf dem neuen Exchange zugreifen ist nicht so der Hit. Das gibt schonmal Probleme wegen der komplexeren Berechtigungsstrukturen beim neuen Exchange.

 

Sollte Dir noch was einfallen zu den Ressourcen, auf die Clients so zugreifen, sprich mich drauf an. Das waren jetzt mal ein paar Beispiele, um Dir zu zeigen, daß bei vernünftiger Planung alles kein Hexenwerk ist...

 

Puha, weiter im nächsten Thread... mal sehen, wann ich das Board vollgeschrieben habe... :D

[schroeder750 10]

Sooo, was hammwer noch:

 

Die VM-Testumgebung:

 

neu BDC in der alten NT4-Domäne(Hostname=bdc2) -> trennen vom echten Netz nehmen hochstufen zum PDC und Fehlermeldung ignorieren

 

... jupp, genau. Die Fehlermeldung kannste nur ignorieren, da kannst Du nur mit OK bestätigen, wenn ich mich recht erinnere. ABER: BEVOR Du den virtuellen BDC, der ja in die echte Umgebung installiert wurde, von der NT4-Domäne trennst, fährst Du bitte auf dem echten Exchange 5.5 noch kurz die Dienste runter und kopierst die priv.edb, die pub.edb und die dir.edb noch auf ein Laufwerk der virtuellen Maschine. Die brauchen wir in der Testumgebung... ;) Ebenso kannst Du hier Logonscripte und ähnliches absaugen, eben alles was Du in der Testumgebung testen willst...

 

neuen BDC in der VM-NT4-Domäne(Hostname=mail) -> hochstufen zum PDC -> Exchange 5.5 installieren

 

... jepp, auch richtig, hier darauf achten, daß alles so gleich ist, wie möglich. Also Name und IP eh gleich, bei der Exchange-Installation gleiche Organisation und gleichen Standort eingeben. Das Computerkonto des echten PDC (mail) existiert natürlich auch noch in der SAM der Testumgebung, das musst Du natürlich vorher killen...

Die Exchange 5.5 wurden übrigens früher gerne unter einem speziellen Exchange-Account installiert. Den findest Du heraus, indem Du nachschaust, unter welchem Account beim jetzt produktiven Exchange die Ex-Dienste gestartet werden. Bitte genau unter diesem Account auch den Exchange in der Testumgebung installieren. Das Konto hast Du ja mit rübergesaugt...

Wenn der Exchange 5.5 dann steht, kopierst Du die Datenbanken, die Du ja vorher aus der produktiven Umgebung abgesaugt hast vom ersten BDC (bdc2) der Testumgebung (der ja jetzt wieder BDC ist) auf den neuen virtuellen Exchange (mail).

Und diese Datenbanken werden dann eingepatcht. Wie, dazu kommen wir später... :cool:

 

 

So, wie kriege ich die die Kommunikation jetzt mit dem Exchange 5.5 aus der echten Umgebung, ich mein das Netz darf ich nicht mehr verbinden, wegen Namenskonflikt des PDC?

 

Wer braucht jetzt noch für die Testumgebung ne Kommunikation mit dem echten Exchange ? Wir haben alles da, was wir brauchen ... :p :p

 

... und wieder mal weiter im nächsten Thread... mannomann ich werd hier echt noch zum Schriftsteller ... :o

[schroeder750 10]

Okidoki, jetzt was zum Einpatchen der Exchange-Datenbanken, viel drüber gesabbelt aber nix zu erzählt bisher :D Jetzt geht das los:

 

Was interessiert uns beim Einpatchen ?

 

Der Exchange 5.5 hat drei Datenbanken:

 

- priv.edb: Privater Informationsspeicher (Mails, Kalender usw...)

- pub.edb: öffentlicher Informationsspeicher (is jetz klar, oder ?)

- dir.edb: die kleinste und unscheinbarste, aber eben auch die wichtigste Datenbank des Exchange 5.5. Hier werden unter anderem Berechtigungen gespeichert und vor allem auch, welches Postfach mit welchem NT-Benutzeraccount verheiratet ist.

 

[ Ganz nebenbei: Nimm dir bitte in Gedanken mal die dir.edb, blas sie ein wenig auf, pinsle sie neu an und kleb ein neues Schild drauf: ntds.dit. Dann hast Du in etwa das, was sich später "active directory" nennt. Genau dafür wird später bei der Migration der ADC (Active Directory Connector) benötigt, um die Daten der dir.edb irgendwie ins AD eingeimpft zu bekommen... den Exchangeservern ab Version 2000 fehlt nämlich genau diese dir.edb. Das ist dann das AD. Aber dazu später mehr... ]

 

Dann haben wir ne Menge Exchange-Dienste. Zwei davon interessieren uns jetzt beim Einpatchen:

 

- MS Exchange Informationsspeicher: wenn der startet, werden priv.edb und pub.edb angezogen.

 

- MS Exchange Verzeichnis: Wenn der startet, wird die dir.edb angezogen.

 

Gut. In Gedanken haben wir den neuen Exchange installiert, der steht jetzt da mit nackten Datenbanken ohne Inhalt. Alle so um die 3 MB groß oder so...

Prima, die beiden oben genannten Dienste beenden, die Datenbanken gegen die aus der Originalumgebung austauschen und Dienste neu starten, oder ? - Nööö, geht nicht. Der Verzeichnisdienst wird nicht starten... (DSE communications error oder so...).

 

Was haben wir denn noch, was uns interessiert ?

 

Log-Dateien. Liegen meistens in den gleichen Verzeichnissen wie die Datenbanken, wenn sie nicht woanders hingelegt wurden.

Die haben wir aus der originalen Umgebung nicht mit rübergenommen, die brauchen wir hier auch nicht. Trotzdem nerven die uns... Wenn wir versuchen, den Verzeichnisdienst zu starten, legt der Exchange neue Logdateien in das Verzeichnis \DSADATA, wo auch die dir.edb liegt. Nich weiter schlimm, aber gleich ziemlich nervig...

 

O.K. was wird passieren ?

Verzeichnisdienst starten, geht nicht, Logdateien werden angelegt.

 

Das er sich nicht starten lässt, liegt an der Tatsache, daß die dir.edb erst noch sauber eingepatcht werden muss, die ist diesem System ja noch fremd.

Patchen heißt: den Befehl "isinteg -patch" auszuführen.

Der funktioniert aber nur, wenn der Verzeichnisdienst gestartet ist. Der lässt sich aber nicht starten, weil ja die dir.edb noch nicht passt... Zusätzlich stören die beim Startversuch erzeugten Logdateien den Patchvorgang, müssen also auch wieder gelöscht werden...

Wie sagt TV Kaiser immer ? "Ein Teufelskreis..." :D

 

... weiter im nächsten Thread...

[schroeder750 10]

Vorgehensweise ist folgende:

 

Anmelden mit dem Exchange Dienstaccount !

 

Bitte zuerst nur die dir.edb gegen die aus der produktiven Umgebung austauschen. priv.edb und pub.edb bleiben erst einmal die nackten, neuen da liegen...

 

Eine DOS-Box vorbereiten, die legst Du Dir in die eine Ecke des Bildschirms. Hier schonmal den Befehl "isinteg -patch" eingeben, jedoch noch nicht bestätigen. (isinteg.exe liegt übrigens im Verzeichnis \exchsrvr\bin, wenn ich mich recht erinnere).

 

Eine weitere DOS-Box vorbereiten, in der Du in das Verzeichnis der dir.edb gehst (\exchsrvr\DSADATA) und den Befehl "del *.log" vorbereitest, aber noch nicht bestätigst.

 

Die Diensteverwaltung öffnen und schonmal den MS-Exchange Verzeichnisdienst anklicken.

 

Jetzt gehts los:

 

- Dienst Verzeichnis anstarten

- Direkt in die DOS-Box wechseln und den patch-Befehl absetzen

- Direkt in die andere DOS-Box wechseln und die Log-dateien löschen.

 

Der Dienst wird ein Weilchen mit starten beschäftigt sein, währenddessen kannst Du in den beiden DOS-Boxen den Befehl immer wieder mit der Pfeil-nach-oben-Taste wiederholen und absetzen. Irgendwann funktioniert der Patchvorgang, während der Dienst "halb angestartet" ist und es kommt eine Erfolgsmeldung im Fenster mit dem Patchvorgang. Währenddessen natürlich immer schön die störenden Logdateien löschen...

 

Hört sich abstrus und ein wenig nach Alchemy an ? STIMMT !!

 

Habe aber auf diese Art und Weise wirklich schon einige Kunden-Exchangeserver wieder hergestellt, nachdem die völlig abgeraucht waren und nur noch ein paar Offlinesicherungen der Datenbanken da waren... So kann man übrigens auch einen Exchange 5.5 prima auf komplett neue Hardware hieven, ohne große Show zu machen...

 

Kann beim ersten mal klappen, kann auch 50 Durchläufe benötigen ... alles möglich...

Ich habe mir teilweise schon Batchdateien mit den obigen Befehlen vorbereitet, die dann für mich in wilder Reihenfolge die Logs gelöscht und den Patchvorgang ausgeführt haben, während ich mit einem Kaffee in der Hand immer wieder den Dienst angestartet habe.

Das tut irgendwann. Dümmstenfalls brauchst Du etwas Geduld.

Wenn der Dienst einmal gestartet ist und versehentlich in der Hektik nochmal die Logs gelöscht oder der Patchvorgang gestartet wird, nicht schlimm. Wenn der Dienst gestartet ist, läuft das Ganze...

 

Danach, wenn die dir.edb eingepatcht ist, den Verzeichnisdienst gestartet lassen und den Informationsspeicher beenden. Dann als nächstes die priv.edb austauschen und bei beendetem Informationsspeicher aber bei gestartetem Verzeichnisdienst den Patchvorgang wieder ausführen. Geht diesmal einfacher, die dir.edb ist ja angezogen ...da brauchst Du nicht dauernd noch nen Dienst anstarten...

 

Danach den gleichen Vorgang für die pub.edb.

 

Am Ende hast Du eine Testumgebung, die exakt Deinen produktiven Exchange intus hat und daran kannst Du prima die Migration auf den 2003er üben...

 

Wenn zu diesem abstrusen Thema Fragen sind, leg einfach los. Hört sich schlimm an, ist es aber nicht :D

 

So, jetzt mach ich auch erstmal Feierabend.

 

Grüsse

 

schroeder750

[Christoph35 10]

Hi, Schröder,

 

Du schreibst ja immer schön viel hier in dem Thread :). Da kann ich echt noch lernen...

 

Wie wär´s, wenn Du das ganze mal ins MCSEBoard-HowTo-Projekt einbringst?

 

Die priv.edb und pub.edb können aber je nach Unternehmen natürlich ein wenig groß sein, um die mal eben in eine VM zu kopieren...., bei uns war die zum Zeitpunkt der Umstellung auf E2K3 mit 35 GB ja noch nicht mal sooo groß, aber für ne VM ? ;) . In dem Fall sollte man wohl doch besser mit leeren Mailboxen arbeiten, oder?!

 

Christoph

[Coyote 10]

Wow so viele Infos auf einmal, mercy dir SCHROEDER für die feine Unterstützung, habe leider heute nicht die Zeit alle deine Tipps ins Detail durchzugehen und die den Plan zu integrieren, zu vile los heute bei uns, melde mich am Montag wieder.

 

Schönes Wochenende

[schroeder750 10]

Du schreibst ja immer schön viel hier in dem Thread . Da kann ich echt noch lernen...

Danke danke !! ;) Mal im Ernst, wenn das irgendwie ZU ausführlich und deswegen unübersichtlich wird, bremst Ihr mich, O.K ? Ich schreibe immer so wie mir die Schnauze gewachsen ist ... :D

 

Wie wär´s, wenn Du das ganze mal ins MCSEBoard-HowTo-Projekt einbringst?

 

äääh .. gerne... wie wo was ? Ich muss gestehen, daß ich eben mal ein wenig im Board rumgesucht habe, aber nu nix von einem How-To-Projekt gefunden habe... ich habe da so meine Trampelpfade ... hilfst Du mir ein wenig auf die Sprünge ?

 

 

Zur Größe der priv.edb und der pub.edb:

 

Klar, die echten DBs sind manchmal so "handlich" wie ne Ikea-Schrankwand :D .

Es ist halt prima, wenn man irgendwie die Möglichkeit hat, die echten zu nehmen. Im Echtbetrieb z.B. wird man des Öfteren merken, daß auf dem alten Exchange zum Schluss noch ein "Bodensatz" an Postfächern überbleibt, die Fehler beim Verschieben bringen. Da weiß man dann aus der Testumgebung heraus schon, wo es bei der echten Verschiebung klemmen wird und kann entsprechend gegenarbeiten.

 

Aber natürlich kann man auch den "nackten" Exchange nehmen und sich einfach ein Rudel Postfächer erstellen, um die Verschieberei zu testen. Ist ne absolute Alternative, wenn man nicht gleich Gigabyteweise in die virtuelle Maschine schaufeln will :D :D :D

 

O.K. Allen ein schönes Wochenende !!!

 

Grüsse

schroeder750

[schroeder750 10]

Moin moin,

 

eine Info habe ich oben bei der Einpatcherei der Datenbanken noch vergessen:

 

Falls Du die originalen Datenbanken nimmst (Christoph hat natürlich völlig recht, je nachdem wie groß die Dinger sind kann das echt unhandlich werden) solltest Du vor dem Einpatchen der Datenbanken noch eines beachten:

 

Die Informationen zum Internet Mail Connector liegen ebenso in der dir.edb vergraben.

Wenn der nackte Exchange 5.5 in der Testumgebung also installiert ist, installiere danach direkt den Internet Mail Connector und anschließend das gleiche Service Pack wie auf dem "echten" Exchange. Wenn Du dann die dir.edb einpatchst, hast Du auch die originale Konfiguration des Internet Mail Connectors.

 

Natürlich hat man in der Testumgebung keinen Connect nach aussen, es ist aber immer ganz gut, in der Testumgebung auch diese Informationen wie in der echten Umgebung zu haben, um dann bei der Testmigration zu sehen, wo denn diese Infos z.B. beim SMTP-Connector des 2003er Exchange untergebracht werden...

 

Bis später !! ;)

 

Schroeder750

[Christoph35 10]

@schroeder bzgl. HowTo:

 

http://www.mcseboard.de/showthread.php?t=35960

 

Gruß

 

Christoph

[schroeder750 10]

@christoph:

 

Danke Dir, werde mir das mal ansehen...

 

Bin, ehrlich gesagt, etwas im Zwiespalt...

hast ja wahrscheinlich mitbekommen, daß ich Systemberater bin und als solcher auch Schulungen halte...

 

Die selbst erstellte Schulungsunterlage (Momentan 243 Seiten incl. Screenshots über InPlace- / Parallelmigration und Exchange-Migration) ist natürlich Hauptbestandteil meiner Schulungen und somit Grundlage dafür, daß ich auch morgen noch u.a. durch Migrationsschulungen die Butter auf meinem Brot verdiene...

Ist ja eigentlich nur ehrlich, wenn ich das hier so sage, oder ? ;)

 

Werde mal drüber nachdenken, O.K ? :wink2:

 

Grüsse

 

schroeder750

[Christoph35 10]

Hi,

 

klar, ist natürlich Deine Entscheidung, ob und wie Du dich an dem Projekt beteiligen willst. Andererseits kann natürlich ohnehin jeder hier Deine Beiträge lesen ;)

 

Christoph

[Coyote 10]

Servus Schroeder und Christoph,

 

So jetzt habe ich das virtuelle Exchange-Cloning in meinem Projektplan aufgenomen.

Das einpatchen ist aber eine eigenartige Vorgehensweise, hauptsache es funktioniert :D Danke für den supper TIPP.

 

Jetzt kommen noch wahrscheinlich folgende Punkte:

- Servergespeicherte Profilmigration

- Clientmigration

- Exchangemigration auf AD-2003

 

bin jetzt auf die Antworten gespannt.

 

Übrigends, habe mit dem Chef gesprochen und er findet die Idee auch gut, dass ich vorerstmal die virtuelle Umgebung aufbauen und zuerstmal das ganze durchtesten soll.

Die echte Migration wird aber wahrscheinlich aus Budgetgründen erst ende des Jahres bzw. nächstes Jahr kommen.

Was evtl. noch interessant werden könnte ist ein Exchange2003-Cluster, kann ich ja in der VM testen. Können wir aber auch nach der Migration besprechen.

 

Danke EUCH, macht weiter so :thumb1: