schroeder750

@gysinma1: wow wow wow, sorry, sooo sollte das nu echt nicht rüberkommen. Ich hatte das nur nochmal als ein paar Fakten zusammenfassen wollen bevor ich was dazu sage, weil die Antworten doch recht zahlreich waren und in einige Richtungen gingen. Sei bitte versichert, daß ich NICHT aus der Besserwisserecke komme, O.K. ? ;-)) Sollte echt nicht so verstanden sein ... wenn es so rüberkam, dann sorry für die missverständliche Formulierung ! Zum native mode vor der Exchange-Migration: Hintergrund des Gedankens war einfach folgender: Die Verteilerlisten aus dem Exchange 5.5 werden ja im AD zu Gruppen. Spätestens dann, wenn im Exchange 5.5 Verteilerlisten tiefer verschachtelt sind müssen also universelle Gruppen her. Und die sind halt nur im native mode richtig möglich. Hatte da schon Migrationen, wo nicht darauf geachtet wurde und was dabei rauskam als die (verschachtelten) Verteilerlisten migriert wurden, war nicht sonderlich schön... Ich migriere die Exchange-Ressourcen daher nicht mehr, wenn die Domäne nicht im native mode ist. Wenn kaum mit oder nur mit flachen Verteilerlistenstrukturen gearbeitet wird, kann man die Migration evtl. auch im mixed mode angehen... Wie es genau gemacht wird, ist dann jedem überlassen, aber ich finde es hier zumindest erwähnenswert, bevor jemand deswegen bei der Migration auf die Nase fällt. Grüsse schroeder750

... das Problem ist mir auch nicht unbekannt. Is auch richtig, daß man beim mitgelieferten Tool "Leistungsoptimierung" den Speicherbedarf für die Store.exe beschränken kann. Dieser Fehler wurde aber angeblich im Service Pack 4 für den Exchangeserver behoben. ...angeblich ... steht so in den Textdateien zum SP4 drin. Ich fahre bei den Kunden, die diese Lösung aus dem Völkerkundemuseeum noch einsetzen und das Problem hatten, sehr gut damit, das SP4 zu installieren und via Leistungsoptimierung den Wert zu begrenzen... Grüsse schroeder750

Hy Leute, da kann ich HubertN nur zustimmen. Ich würde mir eher die rechte Hand abschneiden, als einen seit werweißwievielen Jahren vor sich hindümpelnden PDC zum DC upzudaten... Besser is das, einen neuen Server (normale Workstation) als BDC ins Netz zu bringen, zum PDC hochzustufen und upzudaten. Das Ding sollte aber dann auch nicht allzu lange existieren... Anschließend direkt einen neuen Server sauber mit W2K oder W2K3 aufsetzen, den als zweiten DC ins AD bringen, die fsmo-Rollen UND den Global Catalog Server (nicht zu vergessen ...) auf den neuen verschieben und den upgedateten DC via dcpromo wieder aus dem AD verschwinden zu lassen. Wenn es schon ein InPlace Upgrade der Domäne sein muss, dann bitte nicht mit irgendwelchen upgedateten Kisten starten ... Zum LDAP-Port: Exchange 5.5 kommuniziert über den Port 389, richtig. Die W2K / W2K3 DCs kommunizieren untereinander auch über den LDAP-Port 389. Auch richtig. Wenn der Exchange 5.5 nun aber auf einem DC liegt, hämmern natürlich zwei "Anwendungen" auf dem gleichen Port rum... schlecht !! Also: Wenn der Exchange 5.5 auf einem DC laufen soll, muss der Port geändert werden, auf einem Memberserver ist das egal. Da der Exchange 5.5 hier auf einem W2K Memberserver läuft, muss also nichts gemacht werden. Vor der Migration auf Exchange 2000/2003 muss das Schema erweistert werden, richtig. Ausserdem sollte vor der Migration auf den Exchange 2000/2003 die Domäne in den native mode geschaltet werden, was heißt, daß die NT4 BDCs vorher RAUS müssen... Komm bitte bloss nicht auf die Idee, den jetzigen Exchangeserver einfach upzudaten... Auf jeden Fall einen neuen Exchange(2K/2K3)server in die bestehende Organisation aufsetzen und natürlich mit dem ADC arbeiten, so wie es schon gesagt wurde... Grüsse schroeder750

... Bei der Parallelmigration wird die neue Domäne direkt in den native mode geschaltet, daß ist richtig. - Nach der Installation überprüfen, dümmstenfalls von Hand in den native mode bringen... Somit können die Verteilerlisten also sauber vom Exchange 5.5 rübergeholt werden. Mit dem ADMT, das ist so eine Sache... man muss halt vorher so einiges vorbereiten, bevor man das ADMT startet. Die Berechtigungen des Accounts, unter dem das ADMT läuft, sollten halt in beiden Domänen richtig sein. Daher kommt wohl der "Zugriff verweigert" Fehler... Das ADMT bietet verschiedene Optionen. Die MÜSSEN natürlich nicht alle der Reihe nach abgefackelt werden. Was man auf jeden Fall braucht sind folgende Wizzards: - Usermigration - Gruppenmigration Hierbei ist die Reihenfolge auch nicht ganz unerheblich... Habt Ihr schon einen BDC in der NT4-Domäne, auf dem der Passwort-Export-Server läuft ? Sonst wird das nix mit Passwörtern rüberholen... Ob man die Clients mit dem Wizzard vom ADMT in die neue Domäne hieft oder dies doch lieber händisch macht, bleibt jedem selbst überlassen. Hierbei kommt es natürlich auch auf die BS-Version der Clients an... Bei den Multimediaspielzeugen wie Win 9x ist da wohl eh nicht viel autmatisiert zu holen ... Grüsse schroeder750

... hast mich erwischt, stimmt natürlich... ich bringe die Domäne auch immer vorher in den native mode... hatte das nur geschrieben, um klar zu machen, daß die neue Domäne nicht so abhängig ist, wie die alte bei einer InPlace-Migration. War definitiv so nicht richtig !! Hatte ich nicht genau überlegt... bin auch nur ein Mensch und hatte das nebenbei geschrieben, als ich bei einem Kunden draussen saß... da muss sowas immer fix gehen. Danke !! ;-)) schroeder750

Hy Velius, danke für diese Zusammenfassung, hast Recht, ab einem bestimmten Zeitpunkt ist es absolut sinnvoll mal die grundlegenden Aussagen sprechen zu lassen. Ich verzettel mich da ganz gerne mal bei meinem Geschreibsel ... Zu der Geschichte mit den wesentlich mehr benötigten Hardwareressourcen muss ich jedoch wiedersprechen. Bei einer Parallelmigration reicht es, sich zuerst einmal eine ALDI-Workstation zu schnappen und da den ersten DC draus zu machen (halt immer eine Sicherung des Systemstate ziehen). Ab diesem Zeitpunkt werden entweder A) Server, die auch bei einer InPlace-Migration eh angeschafft worden wären, in die neue Domäne gebracht, anstatt in die alte oder B) Die bestehenden (NT4)-Server Stück für Stück aus der alten Domäne als W2K3-Server neu aufgesetzt in die neue Domäne gebracht. Und die hätte ich auch in der alten Domäne bei einer InPlace-Migration neu installieren müssen. Ich kann aus meiner Erfahrung bestätigen (und das waren wirklich einige Migrationen), daß ich, wenn ich es richtig plane, zwei oder drei neue Kisten benötige, wovon einer oder zwei meistens moderne Workstations waren, die ich temporär einsetze ... So gut wie keine neue Hardware benötige ich natürlich nur, wenn ich eine InPlace-Migration durchziehe und alle Server einfach update... aua aua ... wer das macht, braucht dann irgendwann einen langen Urlaubsschein ... ;-)) ... bloss die Finger weg davon ... Grüsse schroeder750

Zum W2K3-DC: Natürlich übernimmt dieser die Funktion des ehemaligen PDC. Die Rolle des „PDC-Emulators“ ist eine der 5 fsmo-Rollen … Das funktioniert wunderbar, die BDCs sind der festen Überzeugung, sie würden mit einem NT4-PDC kommunizieren… Und jetzt noch was zu diesem „interims-modus“: Ganz ehrlich ? – Ich habe den NIE gebraucht. Wo soll der Sinn sein, NT4-BDCs zuzulassen und W2K-DCs auszusperren ? Was eventuell eine Möglichkeit wäre, ist die, dass im „interims-modus“ universelle Gruppen zugelassen sind, obwohl die Domäne nicht im native mode ist. Dann würde das Ganze halbwegs Sinn machen. Da kann ich Dir aber nix genaues drüber sagen, habe diesen Modus nie benutzt. Mal ganz ehrlich ? --- Warum baust Du Dir nicht auf der grünen Wiese eine Paralleldomäne auf und ziehst mit den normalen Migrationstools wie ADC und ADMT die Ressourcen rüber ? Dann schraubst Du nicht in der produktiven Domäne rum und lässt Leichen und Fehlkonfigurationen (verbogene policies oder ähnliches ) in der alten Domäne zurück. Ich will den Weg, der in Deinem Link beschrieben wird, nicht schlecht machen, nur denke ich, dass man sich vorher schlau machen sollte. Die Jungs, die diesen Link geschrieben haben, werden auch was verkaufen wollen und schreiben nicht ALLES komplett rein… Komm nicht auf die Idee, dass es ein Kochrezept ist, das Du nur abfahren musst … ist es nicht, kann ich Dir bestätigen. Es wird immer viel erzählt, dass eine Parallelmigration ach sooo viel komplizierter ist als eine InPlace-Migration… ist sie meiner Meinung nach nicht unbedingt. Man kann in Ruhe testen, ohne der produktiven Domäne weh zu tun, kann jederzeit neu anfangen, wenn man Mist gebaut hat, da man bis zu einem gewissen Zeitpunkt nur lesend in die NT4-Domäne eingreift und hat noch den Vorteil, dass man sauber bei Null anfangen kann. Denk mal drüber nach, in diesem Fall wäre die spätere produktive Umgebung erst einmal Dein Testumfeld… da geht keine Arbeit verloren… Mist, ist doch wieder so ein Roman geworden… sorry, ist schon immer mein Problem gewesen… Grüsse Schroeder750

Hy wolke2K4, ich kann Dir echt nur den Tip geben, Dir mal die weiteren Threads anzuschauen, in denen ich was gepostet habe. Einfach auf Suche nach Mitgliedern, „schroeder750“ eingeben und die ganzen Threads in Ruhe durchlesen… Ich müsste sonst alles immer wieder doppelt und dreifach schreiben… Hier nur mal kurz ein paar Antworten auf Deine Vorgehensweise: Zitat: „Mir wäre es auch lieber die Geschichte ausführlich zu testen aber das ist leider einfach nicht drin.“ SCHLECHTESTE VORRAUSSETZUNGEN !!! Du SOLLTEST vorher testen !!! Bei einer InPlace-Migration (und genau die beschreibst Du hier) werkelst Du in der PRODUKTIVEN Domäne rum ! Ein falscher Schritt und Deine User können ein paar Tage Urlaub machen… Sorry, wenn ich hier so viel Grossschrift benutze, aber es ist wirklich wichtig ! Ist nur gut gemeint…will Dich vorm Horror bewahren ;-)) Zu 1) Einen „temporären PDC“ kannst Du nicht mal eben in die Domäne integrieren. Du bringst diesen Server unter NT4 als BDC rein und stufst ihn zum PDC hoch, wobei der jetzige PDC automatisch zum BDC herabgestuft wird. Diesen neuen PDC unterziehst Du einem Update auf W2K3, wobei Dir das schon gegen die Wand laufen kann, wenn Du hier vorher unter NT4 nicht schon das DNS richtig konfiguriert hast. Ist das DNS falsch konfiguriert, Du merkst es aber erst während des Updates, war es das schon … dann hängst Du mit dem halb upgedateten PDC in einer Updateschleife drin, kannst keinen sauberen DC draus machen, weil das DNS nicht stimmt, kannst aber auch das DNS nicht mehr sauber konfigurieren, weil Du in diesem Updatevorgang alles ausgeraut hast … habe ich alles schon gehabt. Das was vorher beim NT4 unter den Netzwerkeinstellungen unter DNS eingetragen ist, taucht nämlich nachher beim W2K3 DC unter den Eigenschaften beim Arbeitsplatz als DNS-Suffix auf … das muss vorher alles stimmen…und ohne sauberen DNS-Suffix (fqdn) kein sauberer „dcpromo“ … Zu2) Den Dienst DNS kannst Du nicht erst auf dem zweiten und somit späteren endgültigen DC einrichten, der muss schon vorher auf dem ersten (temporären) DC sauber laufen, sonst kriegst Du kein AD hin … DHCP ist hier erst einmal zweitrangig. Zu3) Entfernen ist richtig, aber auf jeden Fall sauber mit „dcpromo“, sonst gibt es nachher im AD Replikationsleichen, die Dir in der Domäne ewig die Performance versauen… Zu4) Herabstufen der alten BDCs… Tja, normalerweise ist es ja so: ein NT4-Server wird als Memberserver, BDC oder PDC ins Netz gebracht. Die Rollen des PDC und BDC kann man rauf oder runterstufen. Du wirst jedoch nie einen BDC zum Memberserver machen können … Einmal DC, immer DC … jedenfalls normalerweise … Was dieses Tool „UPromote“ kann, weiß ich nicht… wenn man jedoch unbedingt teuere Zusatztools kaufen will … Wenn Du Exchange 5.5 auf einem BDC laufen hast, ist das bei einer InPlace-Migration die schlechteste Vorraussetzung, die Du haben kannst. Wenn Du den Exchange später auf 2K3 migrieren willst, musst Du aus den eventuell tief verschachtelten Verteilerlisten des Exchange 5.5 universelle Gruppen im AD machen. Die kannst Du erst anlegen, wenn die Domäne im native mode ist. In den native mode bringst Du die Domäne erst, wenn Du alle NT4-BDCs draussen hast. Den letzten NT4-BDC kriegst Du erst raus, wenn der Exchange 5.5 weg ist. Den Exchange 5.5 kriegst Du aber erst weg, wenn die Domäne für den Exchange 2k3 im native mode ist. Und spätestens hier beisst sich die Katze in den Schwanz… Dann muss der Exchange 5.5 vorher wieder auf einen Memberserver verlegt werden … Und das Runterstufen eines BDCs, auf dem Exchange 5.5 läuft mit diesem Tool „UPromote“ … Na ja, vielleicht funktionierts, vielleicht auch nicht… ich würde so was vorher Testen, aber die Zeit scheinst Du ja nicht zu haben … ;-)) ... Box wird zu klein, weiter im nächsten Feld ... ;-))

... und genau deswegen halte ich für unsere Kunden die Schulungen mit EIGENEN Unterlagen. Sich mal eben so ein Buch von Microsoft zu schnappen und innerhalb von einigen Tagen Studium fit für die Migration zu sein, halte ich für nicht gerade wahrscheinlich ... Da ich nicht alles gerne doppelt schreibe sei hier nur kurz der Tip gegeben, in diesem Forum nach "schroeder750" zu suchen, die meisten Beiträge, die ich bisher gepostet habe, beziehen sich auf dieses Thema. Man merkt leider sehr oft, daß die Leute zwar MCSE-mäßig geschult wurden, aber dann in der Praxis recht fix sehen, daß bei der Schulung eben nur die Hälfte gezeigt wurde... gerade beim Thema Parallelmigration ... Ich habe mir das ganze als Systemberater sehr intensiv geben müssen, da ich die Migrationen bei unseren Kunden durchführe. Und das wäre nur mit MS-Schulungen oder ein paar Büchern nie vernünftig gelaufen. Bin selber oft genug auf die Klappe gefallen und möchte hier verhindern, daß es andern auch passiert... Ruckzuck ist was falsch gemacht und die Hälfte der Daten ist im Nirvana ... Grüsse schroeder750

Kein Problem, gerne geschehen ;-)) wenn noch ne Frage auftauchen sollte, meldest Du Dich einfach. Ist aber dann evtl. einfacher, wenn Du kurz dazuschreibst, welche Exchange-Version Du einsetzt... Grüsse schroeder750

Wenn Du den normalen Abwesenheitsassistenten benutzt und der Server trotzdem nix verschickt, dann ist am IMC bzw. SMTP-Connector auch zusätzlich noch eingestellt, daß Abwesenheitsnotizen NICHT erlaubt sind ... Das sind zwei Einstellungen, die direkt nebeneinander stehen: 1) Kein automatisches Antworten ins Internet und 2) Keine Abwesenheitsnotizen durchlassen ... letzteres ist ungefährlicher, ersteres kann absolut tödlich sein ... Grüsse schroeder750

... ach ja, nicht nur bis die Server die weiße Flagge raushängen, sondern leider auch allzu oft, bis die MX-Server irgendwo auf ner Blacklist landen... Kann unschön werden, wenn man die Server dann wieder am Laufen hat und keine Mail bzw. ein Teil der Mails nicht mehr übertragen wird, weil man irgendwo auf ner Blacklist gelandet ist... Kann dann einige Tage telefonieren kosten, bis man den Administratoren der jeweiligen Mailexchanger glaubhaft versichert hat, daß es nie wieder vorkommt ... ;-)) Grüsse schroeder750

Hmmm.... mal sehen: Normalerweise versucht der Exchange IMMER als erstes die Regeln serverbasiert zu erstellen. Die Regeln werden erst dann clientbasiert erstellt, wenn es aus irgend einem Grunde nicht möglich ist, diese serverbasiert zu erstellen. Z.B. wenn man als Antwort einen Text vorgibt, der in einer Textdatei liegt, die nur auf dem Client liegt oder wenn Mails in einen Ordner umgeleitet werden sollen, der lokal auf dem Client liegt ... Würde sagen, Du gehst nochmal die Regel in Ruhe durch und überlegst bei jedem Schritt genau, ob das, was Du eingibst, auch funktionieren kann, wenn Dein Client offline ist. Dies führt nämlich dann unweigerlich zu einer clientbasierten Regel. Einen Knopf zum Umstellen auf "serverbasiert" gibt es meines Wissens nach NICHT... Übrigens: Was Du da treiben willst, ist "automatisches Antworten ins Internet" und ist normalerweise auf den Exchangeservern deaktiviert wegen der Gefahr, daß der Server als Spamrelay missbraucht wird... Das hat mit der Out-Of-Office-Reply NICHTS zu tun, die wird vom Server her anders gehandhabt... Kontrollieren kannst Du das in den Einstellungen des IMC beim Ex5.5 oder des SMTP-Connectors beim Exchange 2K / 2K3. Stell Dir bitte mal vor, jemand anderes macht das gleiche mit der automatischen Antwort und schickt Dir ne Mail ... Ping Pong bis zum Abwinken, bis die Server die weiße Flagge raushängen ... ;-)) Daher wird die Abwesenheitsnotiz auch nur exakt 1X gesendet ... Gruss schroeder750

Halli hallo, wo die Postfächer genau liegen, ist bei dieser Konstellation absolut egal. Einer der Exchangeserver ist halt immer der "Arm nach draussen", sprich der Bridgeheadserver, der nach aussen kommuniziert. Welcher Exchange das genau ist, ist egal, wenn alle sauber in der Organisation sind. Nach meiner Erfahrung ist es aber besser, zu keinem Zeitpunkt den IMC und den SMTP-Connector gleichzeitig existieren zu lassen. Also am Besten vorher Screenshots von der Konfiguration des IMC machen, diesen dann sauber deinstallieren und erst danach den SMTP-Connector aufbauen und hier die Informationen vom alten IMC eintragen. Bitte darauf achten, daß die Kommunikation nach aussen passt, d.h. entweder die IP-Adressen der Exchange-Server tauschen, oder die Einträge bei der Firewall oder dem AV-Gateway (je nach dem, wer direkt mit dem Exchange kommuniziert) entsprechend auf den neuen Exchange ändern... Grüsse schroeder750

Hy User7070, nach meinen Erfahrungen gibt es eine 50 / 50 – Chance: ich selber habe es bei einem Kunden bei einer InPlace-Migration mal durchgeführt, den Exchange zu migrieren, ohne dass die Domäne im native mode war. Damals wurden aus den Verteilerlisten ominöse Kontakte im AD, mit denen wirklich nicht allzu viel anzufangen war. Bei diesem Kunden war es nicht sehr schlimm, da die Verteilerlisten recht übersichtlich waren, da konnte man es per Hand wieder zurechtbiegen. In größeren Umgebungen wird das natürlich sehr unschön… Einer meiner Schulungsteilnehmer hat es vor ca. einem ¾ Jahr trotz meiner Warnungen während der Schulung wissen wollen und die Domäne im mixed mode gelassen, bevor er den Exchange migriert hat. Danach hat er mich ganz stolz angerufen und mir mitgeteilt, dass er durch die Exchange-Migration nun plötzlich universelle Gruppen im AD hat, obwohl es NICHT im native mode ist… manuell per Hand konnte er natürlich weiterhin keine universellen Gruppen erstellen… Wenn ER mit diesem haarsträubenden Zustand leben kann, ICH könnte es nicht unbedingt … Die alten Verteiler waren nun zwar migriert, aber sauber verschachtelte neue kann man nicht anlegen… möchte mal wissen, was der Kunde seinen Leuten erklärt, wenn mal ein Verteiler gelöscht wurde und er den so nicht wieder herstellen kann … Da ich bei meinen Kunden eine saubere Consulting-Leistung abliefern möchte, mache ich solche „Va Bangue“-Spielchen nicht … Ich tendiere in Umgebungen, in denen ich aus weiß-der-henker-was-für Gründen NICHT in den native mode gehen kann dazu, für den Exchange 2K oder 2K3 eine nette kleine AD-Domäne dranzuploppen und eine MINI-Parallel-Migration durchzuführen. Diese Domäne existiert dann eben nur so lange, wie ich genötigt bin, die alte Domäne im mixed mode zu halten. Danach kann ich den Exchange ja wieder „eingemeinden“ Ciao Schroeder750

Kleiner Nachtrag noch zu meinem Satz von oben: Daß mir das keiner falsch versteht, ich will hier nicht die MS-Schulungen schlecht machen, es sind nur einfach Erfahrungswerte, die ich von meinen Schulungskunden immer wieder bestätigt bekomme. NT4-Administratoren, die einfach nur eine Domäne migrieren wollen, sind oft völlig erschlagen, wenn erstmal einen Tag lang über weltweite DNS-Strukturen einer Firma mit 50 Standorten und so einfachen Namen wie "Serverxyz.Stadteil.bronx.New-York.southamerica.nwtraders.msft" sinniert wird. Meiner Meinung nach wird da sehr viel Theorie durchgekaut, die die meisten Administratoren eigentlich nur am Rande interessiert. Schade ist, daß diese Leute dann später vor Ihren Servern sitzen, eine Parallelmigration durchziehen wollen und ruckzuck merken, daß sie erst einmal eine Woche Technet-Recherchen durchführen müssen, um die Fehler wegzubekommen, die Ihnen die Migrationstools melden. Dies als kleine Anregung, bitte als positive Kritik zu verstehen ... ;-)) schroeder750

Und jetzt zum Exchange: Exchange 5.5 konnte man mit mehreren Exchange Servern als Organisation über verschiedene Domänen (Standorte) stülpen. Beim Exchange ab 2000 ist das etwas anders, da klebt der Exchange am AD dran, d.h., die Exchange-Organisationsstrukturen sind eng mit der Domänenstruktur verflochten. Man muss bei einer Parallelmigration also über den Trust hinweg den neuen Exchange2K oder 2K3 in die bestehende 5.5 Organisation der NT4-Domäne einbringen, um dann die öffentlichen Ordner zu replizieren und die Postfächer zu moven. Hier kommt dann der ADC ins Spiel. Und um die (evtl. tief verschachtelten) Verteilerlisten als Gruppen ins neue AD zu bekommen, muss dieses spätestens dann im native mode sein… Sooo, dies als kurzen Abriss… wie gesagt, bitte vorher in Ruhe schlau machen. Ich habe einige Microsoft-Schulungen zu diese Thema belegt, war aber jedes Mal recht enttäuscht, da hier leider leider oft lang und breit über die Theorie geredet wird, eine Parallelmigration wurde dort aber live nie durchgezogen. Dies geht auch vielen unserer Kunden so, die schule ich dann in drei Tagen sauber in der Praxis auf Servern unter VMWare. Ist ganz was anderes, wenn man das mal live gesehen hat. Grüsse schroeder750

Hy Wolke24, Hauerha, da solltest Du Dir aber mal nen Kurs oder sowas geben ... bitte nicht falsch verstehen, aber ohne ein nettes Grundwissen solltest Du so eine Migration gar nicht angehen. Mal der Reihe nach, etwas aus dem Nähkästchen: Wenn Du mit ADMT arbeitest, haeißt das automatisch, dass Du eine Parallelmigration planst. Bei einer InPlace-Migration wird ADMT eigentlich nicht benötigt. Wenn Du eine neue Domäne unter W2K3 AD nackt auf der grünen Wiese aufbaust, hat die vorerst mit der alten, produktiven NT4-Domäne nichts zu tun. Es ist absolut egal, in welchem Modus (mixed oder native) sich diese Domäne befindet. Sie wird anschließend über einen Trust mit der NT4-Domäne verbunden und die Gruppen der Domänen (Administratoren und Benutzer) entsprechend über Kreuz berechtigt. Danach geht man daran, die Benutzer und Benutzergruppen aus der alten Domäne in die neue zu übernehmen. Hier kommt dann das ADMT ins Spiel. Da die Benutzer aus der alten Domäne entsprechend die gleichen Berechtigungen auf die Ressourcen in der neuen Domäne haben müssen, ist es unerlässlich, die SIDs der User und der Gruppen mit rüberzunehmen (Stichwort SID-History). Anschliessend kann man dann Server für Server in die neue Domäne integrieren. Wenn Du beispielsweise den Fileserver aus der alten in die neue Domäne rübergenommen hast, ergibt sich folgende Situation: User meldet sich in der NT4-Domäne an, will was vom Fileserver. Der steht aber schon in der neuen Domäne. Dort existiert nach der ADMT-Migration ein User, der genau gleich heißt und die SID vom alten User zusätzlich an seine angehängt hat. Die Anfrage wird also vom NT4-PDC an den W2K3-DC gereicht, die Authentifizierung funktioniert sauber, der User bekommt seine Daten. Hierbei ist die W2K3-Domäne eine eigenständige Struktur, es ist absolut egal, in welchem Modus sie sich befindet, die Authentifizierung zwischen den Domänen findet über den Trust (und das ADMT) statt. Weiter in der nächsten Box, die hier wird mir wieder mal zu klein… ;-))

Hy User7070, schnell erklärt: Um die Verteilerlisten des Exchange 5.5 ins AD zu übernehmen, muss das AD im native mode sein, damit universelle Gruppen angelegt werden können. Um das AD bei einer InPlace-Migration in den native mode schalten zu können, müssen vorher die NT4 BDCs entfernt werden. Um den BDC, auf dem der Exchange läuft, entfernen zu können, muss der Exchange weg... und da sind wir wieder am Anfang, keine Exchange-Migration ohne native mode ... ;-)) Lösung: der Exchange muß vorher vom BDC auf einen Memberserver verschoben werden, dann raus mit dem BDC, Schalten in den native mode und dann Migration des Exchange ... Beim Verschieben des Exchange müssen halt ein paar Dinge beachtet werden... daher der etwas erhöhte Schwierigkeitsgrad. Grüsse schroeder750

Da ein Exchangeserver vorhanden ist, bei einer InPlace-Migration auf jeden Fall darauf achten, daß das AD vor der Exchange-Migration im native mode ist. Universelle Gruppen werden benötigt, um die ehemaligen Verteilerlisten in Gruppen zu verschachteln. Bei einer Parallelmigration erledigt sich dies ja eh, da man die parallele Domäne direkt in den native mode setzen kann. Spassig wird es bei der InPlace-Migration halt, wenn der Exchange 5.5 auf einem BDC läuft ... sollte das der Fall sein, melde Dich am Besten vorher, O.K. ? Grüsse schroeder750

Ach ja, vorsichtshalber nochmal: den alten Exchange 5.5 nicht einfach runterfahren und dann mit dem System Manager des verbleibenden Exchange aus der Umgebung löschen ... Der bessere Weg ist den alten Exchange 5.5 vor den Augen des neuen zu DEINSTALLIEREN !! Sonst verbleiben da eventuell noch alte Fragmente, die ewig für unnötigen Replikationsverkehr sorgen... Gruss schroeder750

Moin moin !! Zur ersten Frage: Genau dafür existiert das Tool "NTDSNoMatchUtility". Das lässt man vorher über den alten Exchange rappeln, dann zeigt es Dir an, welcher (NT4)User mehr als ein Postfach auf sein Benutzerkonto genagelt hat. Als Resultat bekommst Du eine nette *.csv-Datei, in der die User angegeben werden, die mehr als ein Postfach haben. Die Lösungsvorschläge, die dann geliefert werden, sind meiner Meinung nach sehr schwach. Man kann dann eben angeben, welches der Postfächer migriert werden soll. Die anderen verbleiben halt auf dem alten Exchangeserver... Tip von mir: Liste vorher abarbeiten, für die überschüssigen Postfächer extra (NT4Benutzer anlegen und die Postfächer auf die festnageln. NTDsNoMatch so lange laufen lassen, bis keine User mehr angezeigt werden, die mehrere Postfächer haben, dann erst migrieren. Das Tool liegt auf der Exchange 2000 SP3-CD unter "Ntdsattrib" oder so ähnlich... Zur zweiten Frage: Ist ne Standardmeldung vom Exchangeserver, wenn er sterben soll. Da liegen halt noch Systempostfächer speziell für diesen Server. Wenn definitiv alle Postfächer migriert wurden, kann diese Meldung ruhig ignoriert werden. Achte aber drauf, daß die Hauptrollen des Exchangeservers wie Offline Adress Buch, Scedule Free+Busy und Routing Calculation Master sauber auf den neuen übertragen werden. Man vergisst ganz gerne mal, daß ein Exchangeserver noch mehr tut als Postfächer und öffentliche Ordner zu halten... Grüsse schroeder750

Hy there, die Geschichte mit dem neuen Server, Integration als BDC und Hochstufen zum PDC, dann Update auf W2K3 ist natürlich das, was man langläufig als InPlace-Migration bezeichnet. Seit das ADMT in der Version 2.0 draussen ist und die Benutzerpasswörter nicht mehr bei der Migration mittels Paralleldomäne über die Klinge springen, gibt es meiner Meinung nach eigentlich keinen Grund mehr für eine InPlace-Migration. Bei der InPlace-Migration werden eventuelle Leichen, die in der Domäne schlummern natürlich voll mit übernommen. Die meisten unserer Kunden nutzen daher die Möglichkeit, mittels einer Parallelmigration neu anzufangen. Wenn es also keinen triftigen Grund für eine InPlace-Migration gibt, rate ich ganz klar zur Parallelmigration übers ADMT. Ist ein Exchangeserver vorhanden ? Grüsse schroeder750

Hy there, Sonntag abend, habe gerade Zeit und dachte, ich schaue nochmal rein... irgendwie bin ich doch krank, oder ? ;-) Also, @old_di: Wie Du die Einträge rausschmeißt, ist eigentlich egal. Wundert mich jedoch schon, daß Du sie mit dem ldp.exe auf die beschriebene Art und Weise nicht findest... Habe das schon mehrmals so durchgeführt. Tatsache ist, daß wir das Computerkonto und die Eigenschaft des alten Exchange, DASS er Exchange war, rauskriegen müssen. Wenn irgendwelche Unsicherheiten aufkommen geh bitte folgendermaßen vor: - Systemstate aller DCs ziehen - Alle anderen DCs bis auf den, der die fsmo-Rollen hält, RUNTERFAHREN ! Und erstmal unten lassen. (Ist also ein Job für abends) - An dem DC mit den fsmo-Rollen die Änderung am AD (adsiedit oder ldp) vornehmen, den alten Exchange also entfernen - Den neuen Exchange ebenso entfernen. - Einen neuen Exchange mit dem gleichen Namen und der gleichen Organisation wie der abgerauchte wie beschrieben installieren. Hier bitte auf gleichen Service Pack-Stand achten. - Nach der Installation den Informationsspeicherdienst beenden - Wegkopieren / Umbenennen der bei der Installation erzeugten *.ebd und *.stm-Dateien (priv+pub) - Unterjubeln der alten Datenbanken mit den Inhalten, die Du benötigst - Starten der Dienste, bei Problemen nachschauen, ob der "isinteg -patch" noch geht, den gab es beim alten Exchange 5.5 um die DBs einzupatchen. Keine Ahnung, ob der beim neuen Exchange noch existiert. - TESTEN !!! Theoretisch müssten jetzt die Einträge der Userpostfächer im AD zur ersten Datenbank des neuen Servers passen. - Erst nach erfolgreichen Tests die anderen DCs wieder hochfahren. Solltest Du zu irgend einem Zeitpunkt Bockmist bauen, hast Du den Systemstate der DCs. Die Schemapartition lässt sich NICHT autorisierend wieder herstellen, daher das Runterfahren der anderen DCs. Die Jungs haben dann keine neuere USN. Du kannst also nach einem Fehler beim Hantieren am AD jederzeit den ersten DC mit "F8" starten und den systemstate komplett wieder zurückziehen, ohne daß Dir ein anderer DC replikationstechnisch in die Suppe spuckt. Solltest Du zu irgend einem Zeitpunkt einen der DCs zu früh hochfahren und der Mist repliziert sich durch, kannst Du als finalen Rettungsschuss alle DCs gleichzeitig mit "F8" hochfahren und auf allen den jeweiligen Systemstate wieder herstellen. So erreichst Du jederzeit mindestens wieder den Status, den Du jetzt hast. Hey, Ohren steif halten !! Ich bin Montag nicht im Büro, bei uns ist Feiertag... bei Unklarheiten nachfragen, O.K ? An alle Anderen: Ihr habt ja absolut Recht, daß es nicht die feine englische ist, einen Thread doppelt oder dreifach aufzumachen, es ist auch absolut in Ordnung, daß hier jemand regelnd eingreift, aber nach der dritten Mahnung und der dritten Entschuldigung von old_di sehe ich das ganze als genug "gesühnt" an. Will hier echt keinem auf den Schlips treten, ehrlich nicht, aber da ist jemand, dem der A*** auf Grundeis geht, der mit einem zerfetzten Exchangeserver und wahrscheinlich einem Haufen meckernder User hintendran dasteht, der unsere Hilfe braucht, also seid so lieb und kneift mal ein Auge zu, O.K ? Ich Danke Euch ! Liebe Grüsse schroeder750

Hy Matthias, dann müsst Ihr aber gleich langsamer lesen, weil ich nach dem Hefeweizen garantiert langsamer schreiben werde ... ;-)) Gruß schroeder750 P.S: Ich mache jetzt Feierabend ... Dienstag weiter, O.K ?