schroeder750

Hy ganimard, hier erstmal kurz die Info, wo der Eintrag zwecks Reverse-Lookup gemacht werden muss: Exchange 2003 System Manager => Administrative Gruppen=> Erste administrative Gruppe => Server => Servername=> Protokolle => Virtueller Standardserver für SMTP => Rechte maustaste, Eigenschaften => Reiter "Übermittlung" => Rechts unten "Erweitert" => bei "Vollständig qualifizierter Domänenname" den Eintrag eingeben, der vom Provider als Name des Exchangeservers erwartet wird. Dann müsste es eigentlich funktionieren. Habe gerade mit dem Kunden telefoniert, wo wir dieses Problem hatten. Hier wurde der Eintrag gesetzt und es funktionierte danach problemlos. Zur Fehlermeldung des ADC kann ich Dir momentan den Tip geben, daß ich diesen immer nur einseitig einstelle und zwar vom 5.5er in Richtung Ex2K3. In den meisten Fällen ist es so, daß die Kunden die Administration vorerst noch auf der NT4/Ex5.5-Seite vornehmen und es dann von da aus auf dieneue Umgebung repliziert wird. Erst dann, wenn die alte Domäne abstirbt, wird in den meisten Fällen erst endgültig über die W2K3-Umgebung administriert. Ist natürlich irgendwo ein schleichender Prozess, bei dem man keinen klaren Zeitpunkt definieren kann. Übrigens der ausgegraute Reiter beimIMC des Exchange 5.5 kam ja nicht erst, als Du den ADC installiert hast, oder ? Da würde ich mir jetzt mal keinen Kopf drum machen, in der produktiven Umgebung sieht es ja dann wieder anders aus. So, soweit erstmal von mir, momentan etwas wenig Zeit :D Grüsse schroeder750

Gruezi ganimard, soo, hocke gerade zu Hause und hatte ein paar Minuten Zeit mal wieder reinzuschauen. O.K. die Geschichte mit dem Namen des Exchangeservers der von der Gegenstelle, die die Mails entgegennimmt zwecks Reverse-Lookup (und um nix anderes geht es da meistens) erwartet, kommt mir sehr bekannt vor. Das hatte ich vor ein paar Monaten auch bei einem Kunden. Das Problem konnte hier mit einem Eintrag beim SMTP-Connector an der richtigen Stelle gelöst werden. Dieser Eintrag stand beim alten Exchange 5.5 in der Netzwerkumgebung unterm DNS-Alias, wenn ich mich recht erinnere. Ich zermatere mir aber gerade das Hirn wo wir diesen Eintrag beim SMTP-Connector gesetzt haben und weiß es echt nicht mehr... Kann allerdings erst am Montag beim Kunden anrufen und nachfragen. Muss ich Dich also leider erst mal vertrösten, aber es gibt da ne Lösung... Zum Internet Mail Connector beim 5.5er: Komm ich jetzt nicht ganz mit... was heißt, der ist nicht sauber "übernommen" worden ? Du meinst von der produktiven Umgebung in die Testumgebung, richtig ? Wie hast Du das genau gemacht ? Die Einpatchgeschichten, wie ich sie weiter oben beschrieben hatte ? Das der Reiter "Überwachen" ausgegraut ist, ist ja nun erstmal nicht weiter schlimm. Die Überwachungseinstellungen kannst Du ja später beim 2003er wieder in Ruhe so setzen, wie Du es brauchst. Da gehen ja keine Infos verloren, die die Funktionalität beim Senden und Empfangen beeinträchtigen, wenn Du das jetzt momentan nicht auslesen kannst. Trotzdem merkwürdig... bist Du mit dem Exchange-Account angemeldet, mit dem auf dem 5.5er auch die Exchange-Dienste gestartet werden ? Und auslesen kannst Du die Konfiguration ja auch in der produktiven Umgebung, oder ? Zur Deinstallation: Habe das jetzt schon ein Weilchen nicht mehr gemacht und momentan auch keinen Exchange 5.5 zur Hand, meine aber, daß Du den IMC einfach im Exchange-Administrator markierst, so daß er hinterlegt ist und dann oben aus der Menuzeile einfach dieses rote Kreuz anklickst, um ihn zu löschen. Generell kannst Du aber eigentlich auch hergehen und den Ex2K3 installieren und dann dort im Exchange System Manager den neuen als "Master" für die SMTP-Geschichten setzen und auf dem alten 5.5er einfach den Dienst "Internet mail Connector" beenden und deaktivieren. Mir ging es nur darum, daß nicht beide Server gleichzeitig meinen, sie wären Cheffe beim Mailübertragen. Führt schon mal zu unschönen Szenen... :D Wenn Du die Notwendigkeit hast, nach einem Löschen des IMC auf dem 5.5er diesen neu anlegen zu müssen, geht das über "Datei" => "Weitere neue Objekte" => "Internet Mail Connector", wenn ich mich recht erinnere... ;) Woher weißt Du, daß Du aus der Testumgebung momentan keine Mails senden könntest ? Klar, da hängt jetzt der Gateway/Firewall nicht dran, aber was lässt Dich glauben, daß es nicht funktionieren würde ? Der eine ausgegraute Reiter ? Da Du ja perfekterweise eine Testumgebung hast (sehr lobenswert, leider nicht immer üblich) kannst Du doch mal einfach in Ruhe den SMTP-Connector auf dem 2003er scharf schalten und Dir ansehen, was Du von der Konfiguration des alten IMC dort wo herein schreiben musst. Dann tauchen die konkreten Fragen von selbst auf, oder ? Zieh das am Wochenende mal in Ruhe durch und dann dröseln wir das in Ruhe auseinander, O.K ? Tut ja keinem weh, ist ja erstmal Test :D Wünsche Dir trotz der geplanten Arbeiten ein schönes Wochenende !!! Viel Erfolg noch ! Ciao schroeder750

Moin ganimard, gut, daß Du was in den Thread geschrieben hast, ich hatte das schon fast verdrängt, ich war da ja noch ein bisschen was "schuldig" :) Habe in den letzten Monaten etwas Stress, daher müssen die Exchangegeschichten noch etwas warten. Aber das kriegen wir schon... ;) Hier mal so fix aus der Pistole geschossen ein paar Antworten für Dich: Reihenfolge, die ich meistens so durchziehe: - ADC installieren, Verbindungsvereinbarungen für öffentliche Ordner und Postfächer erstellen - Exchange 2003 in die gleiche Organisation installieren, in der der 5.5er ist. - Replikation der öffentlichen ordner anstoßen (versteckte Systemordner nicht vergessen...) - Das ganze einen Tag vor sich hindümpeln lassen, bevor man die Postfächer verschiebt, sonst stresst es die Server arg und die Produktivität geht dahin ... ;) - Replikation der öffentlichen Ordner überprüfen und sucksessive die Postfächer verschieben. - Der Exchange 5.5 hält die ganze Zeit die externe Verbindung (Bekommen und Senden über den Internet Mail Connector) und sorgt für den Mailverkehr, egal wo welches Postfach nun gerade liegt. - Irgendwann wird dann manuell der Internet Mail Connector vom 5.5er entfernt und der SMTP-Connector auf dem 2003er schafr geschaltet. Am Besten vorher Screenshots von der Konfiguration des IMC des 5.5ers machen, dann geht keine Info verloren. Ich habe nur nicht so ganz geschnaggelt, was Du daüber den MX-Eintrag erzählst... :suspect: Im allerbesten Fall verpasst Du dem Exchange 2003 die IP vom Exchange 5.5, die Maildomain heißt gleich und alle sind glücklich, oder? Hängt Euer Exchange 5.5 direkt im Internet ? Normalerweisehat man da doch ne Firewall davor, die die Mails annimmt und durchroutet. Bekommt der Exchange 2003 die IP vom 5.5er, passt das alles wieder, bekommt er sie nicht, muss man halt an der Firewall eine Regel ändern, damit die mails eben an die IP des Ex2K3 geleitet werden. Wie der Server heißt, ist dabei doch erst einmal zweitrangig, oder ? Das geht doch im Normalfall draussen niemanden etwas an... Oder geht es Dir um Reverse-Lookup-Geschichten, bei denen exakt der Name des Exchange erwartet wird ? Werd da bitte mal etwas genauer, damit ich das schnaggel, O.K ? :D Und zur Frage, wie Du sicher gehen kannst, daß alles auf den neuen Exchange verschoben wurde: - Checkliste erstellen mit den Aufgaben, die so ein Outlook tagtäglich so erledigt und dann abhaken. Vorher natürlich mal testweise den Exchange 5.5 runterfahren und ein paar Tage nicht laufen lassen. Gibt im schlimmsten fall ein paar Meckermeldungen vom Exchange 2003, daß er seinen Kameraden nicht erreichen kann, das kann man für den Zeitraum ignorieren. Hier mal ein paar Ansätze für das Testprotokoll: - Mails rein/raus / Mails intern - Öffentliche Ordner und Berechtigungen - Verteilerlisten(5.5) => (universelle Gruppen im AD) stichprobenartig: Inhalt gleich ? - Posteingang Müller noch für Meier freigegeben und andere Berechtigungsgeschichten - Besprechungsanfragen - Kalendereinträge - Gruppenkalender - Formulare - Offline-Ordner passt alles? - Offline Adressbuch ? Einige dieser Funktionen werden evtl. nicht ganz sauber laufen, da sie noch auf dem Ex5.5 liegen (Besprechungsanfragen, Offline Adressbuch), die werden dann aber bei der Deinstallation sauber verschoben. Ein bisschen Nervenkitzel muss ja sein, oder ? :D Natürlich kannst Du die auch mühsam per Hand verschieben, spare ich mir aber meistens... Danach auf jeden Fall den Ex5.5 sauber vor den Augen des Ex2k3 deinstallieren... wichtig !! Sooo, das war jetzt mal ein wenig Input. Wühl Dich mal durch und mach wieder Meldung, O.K ? Viel Erfolg !! Grüsse schroeder750

Moin moin, mal kurz mein Senf dazu: Ich würde mal in der boot.ini unter dem Eintrag "multi(0)disk(0)rdisk(0)partition(2)\WINDOWS.0="Windows Server 2003 in .0 Directory, Standard" /fastdetect" einen weiteren Eintrag einfügen, der auf das alte Windows-Verzeichnis verweist, also etwa so: "multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003-alte Version, Standard" /fastdetect" Danach dürfte beim nächsten Systemstart ein weiterer Eintrag im Bootmenu auftauchen (notfalls mit "F8" das Menu anzeigen lassen). Dann den alten Server mal starten und sehen, ob der läuft. Dürfte aber nicht funktionieren, da der ja abgeraucht war... Sollte dies der Fall sein, kann dieses Verzeichnis eigentlich gelöscht werden. Läuft die Version im Verzeichnis "Windows.0" denn einwandfrei ? Wundert mich jetzt etwas, da ja x Einträge in der registry und sonstwo auf "Windows" verweisen dürften. Ich würde mir mal abends in Ruhe Zeit nehmen und versuchen, rauszufinden, was da bei der Rettungsaktion schiefgelaufen ist... Und um mal etwas genauere Grundlagenforschung zu betreiben: Wie ist denn die Rücksicherung gemacht worden ? Mit was für einem Programm ? Da ist doch mit den Partitionen auch was verschoben worden... sonst würde dieser ominöse Ordner Windows.0 auf D: nicht auftauchen... Haste mal genauere Infos? Grüsse schroeder750

Hy Ziegenhals, sorry, daß ich jetzt erst antworte, bin momentan etwas im Stress. Ich hatte diese Anfrage damals für einen Kunden gestellt, der aber diese Geschichte nicht weiter verfolgt hat, da muss ich nochmal nachfragen. Ich habe also momentan leider kein Ergebnis. Hast Du die Tips von Tom mal probiert ? Normalerweise würde ich mich jetzt mal an meine vmware-Testumgebung schwingen und das ansehen, aber ganz ehrlich, mir fehlt gerade die Zeit und Du willst ja irgendwann mal ein Ergebnis haben. Versuch doch mal die Tips vom Tom und melde Dich wieder, O.K ? Sorry, unzufriedenstellende Antwort, aber ich muss erst wieder die Zeit finden :( Grüsse schroeder750

Das sind doch ausreichend Infos... :D Tausend Dank !!!! Grüsse schroeder750

Hy Christoph, danke Dir für die Info. Das heißt durch die Blume, SQL-Server auf WinXP Prof: definitiv NEIN ? Richtig ? Grüsse schroeder750

Hy Klaus, habe den Link mal zum Durchprüfen weitergereicht. Mal sehen, ob das Produkt auch auf dieser Version läuft. Wäre natürlich schon prima... Ich danke Dir für die fixe Reaktion und den Link !! Super !! :D Grüsse schroeder750

Moin zusammen, kurze, knackige Frage: Kann man einen MS-SQL-Server auf einem Windows XP Professional laufen lassen ? Bitte nicht lachen, ist echt nicht mein Gebiet ... Geht um ein Preisinformationssystem, welches wohl einen SQL-Server voraussetzt, eine Serverlizenz kostet natürlich unwesentlich mehr als eine XP Workstation... :p Es gab da bei der Installation wohl Probleme, ich habe auch keine genauerern Infos... ich fange halt hier mal mit der ersten Frage an... ;) Wenn das generell nicht geht, braucht man ja auch nicht weiterzubasteln ... Falls das geht, gibt es was besonderes zu beachten ? Danke Euch schonmal !! Grüsse schroeder750

gerne ... :) ... schon neun Seiten is gut ... :D Wenn ich für einen mittelgroßen Kunden ein Projektdesign schreibe, hat so ein Ding zwischen 50 und 150 Seiten... Es gibt Punkte, die müssen einfach rein. Ich denke, das was Du bisher hast, ist das, was bei mir als eigentlicher "Aktivitätenplan" im Projektdesign auftaucht. Du solltest für eine nicht ganz triviale Geschichte (und das ist eine Migration ja nun mal leider) ein umfassendes Papier erstellen... Denk mal einfach über ein paar Begriffe nach, die ich jetzt hier in den Raum werfe: - Anforderungen / Projektziele - Projektteam - Terminrahmenplanung - Änderungsindex - Ist-Zustand (Hardware/Software/Struktur) - Soll-Zustand (Hardware/Software/Struktur) - Administrationsstruktur - Testumgebung - Aktivitätenplan - Zeitliche Abhängigkeiten - Rückwege bei Fehlern - Lizenzen - Vorteile durch Migration - Backup vor/während/nach der Migration - Checklisten Klar, man KANN alles künstlich aufblähen, es sollte aber knackig und treffend alles erwähnt werden. Lieber vorher etwas länger planen und schreiben, aber dann Samstags abends, wenn man langsam müde wird, einen klaren Plan haben, den man Stück für Stück abhakt und so die möglichen Fehler minimiert. Wenn Du vorher in der Testumgebung alles sauber zum Laufen bekommen hast und dafür ewig rumgemacht hast, ist nichts ärgerlicher, als dann an der produktiven Umgebung zu sitzen und sich die Frage zu stellen "wie war das jetzt nochmal ?" ... :mad: Wenn Du bisher keine projektleitenden Tätigkeiten gemacht hast, wirst Du spätestens nach der Migration wissen, worum es geht... Wenn ich die Tage wieder Zeit habe, kommt noch die eigentliche Exchangegeschichte. Installation Exchange 2003 -> Datenübernahme -> Bisschen was zur Administration -> Entfernen des alten Exchange und irgendwann auch der alten Domäne ... Wie gesagt, wenn ich die Zeit habe... Kümmer Du Dich inzwischen mal in Ruhe um ein Projektdesign und die Testumgebung. Dann fährst Du in der Testumgebung die hier genannten Punkte ab, stellst wieder Fragen und dieser Thread wird nochmal so lang ... ;) Bis später !!! Grüsse schroeder750

Einen habbich noch :D 231 Klicks bisher auf diesen Thread sagen mir, daß evtl. doch mal noch für irgendjemanden Interesse bestehen könnte, MS-fremde Clients ins AD einzubinden... Hauptproblem war hier, das das NetBEUI-Protokoll nicht mehr im W2K3 Server enthalten ist. Lösung: Man nehme eine Windows XP-CD und kopiere folgende Dateien auf den Windows 2003 Server: Aus dem Unterverzeichnis \Valueadd\mfst\net\netbeui der XP-CD die Datei "nbf.sys" nach <\Windows\System32\Drivers> des Servers und die Datei "netnbf.inf" nach <\Windows\inf> des Servers ... Schon kann man ganz normal aus den Eigenschaften der Netzwerkumgebung des W2K3-Servers das NetBEUI-Protokoll installieren, als wäre es schon immer da gewesen... ;) Evtl. testen wir demnächst noch den Zugriff der OS/2-Clients auf ein 2003er AD, dann werde ich hier nochmals kurz berichten... Grüsse schroeder750

Verbindungsvereinbarung für öffentliche Ordner Bevor die Verbindungsvereinbarung für öffentliche Ordner erstellt wird, muß in der Windows 2003-Domäne das Schema erweitert sein. Hierzu muss von der Exchange 2003-Server CD setup mit dem Paramater „/forestprep“ und anschliessend mit dem Parameter „/domainprep“ gestartet werden. Starten des Active Directory Connectors Neu => Öffentliche Ordner-Verbindungsvereinbarung Name für Vereinbarung vergeben, "In beide Richtungen" auswählen, entsprechenden W2K3 DC angeben. Im Tab "Verbindungen" wieder die Infos wie oben eingeben. Zeitplan wieder auf "Immer" Der Rest erklärt sich eigentlich von selber, bei Problemen einfach hier nachfragen... ==== Kurze Zusammenfassung =========== Was haben wir bisher ? Verbindungsvereinbarung für Empfänger: => Sorgt später dafür, daß wir die Postfächer über die Managementkonsole vom AD vom 5.5er auf den 2003er Exchange verschieben können. Repliziert auch die benutzerdefinierten Empfänger usw... Verbindungsvereinbarung für öffentliche Ordner: => Ist die "Autobahn" für die Replikation der öffentlichen Ordner zwischen den Exchangeservern. Beide Vereinbarungen sollten eigentlich ununterbrochen laufen, gibt dann die wenigsten Probleme. =========================== Konfiguration der ADC-Tools: Im ADC müssen noch die ADC-Tools laufen gelassen werden, sonst gibt es nachher Meckermeldungen. Natürlich kann man alle oben beschriebenen Vorgänge über die ADC-Tools abfackeln, ich mache sowas jedoch lieber manuell. Jeder, wie er es braucht ... :D Wenn die Verbindungsvereinbarungen manuell erstellt wurden, reicht es, bei den ADC-Tools die ersten beiden Schritte auszuführen und dann abzubrechen, dann gibt es später keine Meldung, daß die ADC-Tools nicht ausgeführt wurden... Schadet aber nicht, die ADC-Tools nochmal komplett durchlaufen zu lassen ... ;) Die Grundlagen sind jetzt geschaffen, später kann dann der Exchange 2003 in die gleiche Organisation installiert werden, wie der Exchange 5.5. Hierzu später mehr... :p Grüsse schroeder750

Aufbau des Active Directory Connectors DC der W2K3-Domäne, ADC installieren: (Exchange2003-CD bzw. Exchange Service Pack CD) Setup.exe starten aus dem Unterverzeichnis ADC und standardmäßig durchinstallieren... ADC starten. Empfängerverbindungsvereinbarung: Rechte Maustaste auf den Active directory connector, "Neue Empfängerverbindungsvereinbarung" auswählen. Tab "Allgemein": Name der Vereinbarung eingeben, "In beide Richtungen" auswählen, Meldung bestätigen. ACHTUNG !!!!! „In beide Richtungen“ bedeutet, dass Objekte, die in der W2K3-Umgebung gelöscht werden auch in der NT4-Domäne gelöscht werden !!! Sollte also beim ersten Test der Migration etwas schief gehen, ist man versucht, die OU, in die man importiert hat, einfach zu löschen und neu anzulegen. Steht die Verbindungsvereinbarung zu diesem Zeitpunkt auf „beide Richtungen“, hat man für weitere Importe keine Ressourcen mehr in der NT4-Umgebung, da alle Benutzer, Postfächer, Verteilerlisten u.ä nach einer kurzen Replikationszeitspanne gelöscht wurden !!!!! In der produktiven NT4-Umgebung ist dies natürlich der „worst case“ !!!!! Es empfiehlt sich daher, die Verbindungsvereinbarung vorerst nur von Exchange (5.5) zu Windows (2003) zu konfigurieren. Sind alle Ressourcen erfolgreich aus der NT4-Domäne in die W2K3-Domäne migriert worden und es ist davon auszugehen, dass beide Domänen noch eine Zeit lang nebeneinander existieren, so kann später eine zusätzliche Vereinbarung in die Gegenrichtung erstellt werden, um den Abgleich der beiden Domänen für den Zeitraum der Koexistenz zu sichern… Im unteren Feld den Server (DC) auswählen, der die Vereinbarung ausführen soll. Tab "Verbindungen": Server eingeben, administrative accounts angeben, LDAP-Port konfigurieren ( Im Zweifelsfall im Exchange 5.5 Administrator bei den Protkollen ==> LDAP nachsehen, welcher Port eingetragen ist) Der Exchange 5.5 Server sollte übrigens über Service Pack 3 oder höher verfügen … Tab "Zeitplan": Im Zeitplan "Immer" angeben, den unteren Haken setzen. Dies gilt für den gesamten Zeitraum der Koexistenz der beiden Domänen. Tab "Von Exchange": Auf "Hinzufügen" klicken, die Container angeben, aus denen die Benutzer / Verteiler / Benutzerdefinierten Empfänger importiert werden sollen. ACHTUNG !!! Hier NUR lokale Container angeben. Sollten weitere Standorte in der Exchange-Organisation existieren, so sollte für jeden Standort (Site) eine neue Verbindungsvereinbarung definiert werden. Unter "Standardziel" mittels des Buttons "Ändern" die OU aus dem AD auswählen, in die die Benutzer mit dem ADMT migriert wurden. Tab "Von Windows": Hier evtl. die OU im AD angeben, von der aus zurückrepliziert werden soll, wenn beide Domänen länger zusammen existieren (siehe oben) Unter "Standardziel" wieder den Benutzercontainer des Exchange 5.5 auswählen. Auch hier wieder NUR lokale Container angeben. Sollten weitere Standorte in der Exchange-Organisation existieren, so sollte für jeden Standort (Site) eine neue Verbindungsvereinbarung definiert werden Wenn der ADC mit dieser Verbindungsvereinbarung eine Zeit gelaufen ist, die Ergebnisse im AD überprüfen... Als nächstes kommt die Verbindungsvereinbarung für öffentliche Ordner.

Hy coyote, habe gerade ein paar Minuten und fange jetzt mal einfach mit der Exchange-Migration an, O.K.? Schaun mer mal: Der Exchange 5.5 hat, wie schon erwähnt, drei Datenbanken: A] Priv.edb (Privater Informationsspeicher) ==> Inhalte werden später als Postfächer auf den 2003er verschoben B] Pub.edb (Öffentliche Ordner) ==> Werden später auf beide Exchange repliziert, die Replikate dann vom 5.5er entfernt. C] Dir.edb (Verzeichnis) ==> Gibt es beim 2003er nicht mehr, ist dann das Active Directory. Um die Dinge sauber rüberschieben / rüberreplizieren zu können, sollten wir beide Exchangeserver in die gleiche Exchange-Organisation bringen, auch wenn bei einer Parallelmigration zwei unabhängige, vertrustete Domänen zu Grunde liegen. Um das zu schaffen, wird der Active Directory Connector (ADC) benötigt. Wenn der einmal steht und die entsprechenden Verbindungsvereinbarungen erstellt wurden können folgende Ressourcen rübergeschoben werden: Exchange 5.5: Postfächer mit verbundenen NT4-Benutzerkonten =wird zu=> Exchange 2003: EMail-aktivierte Benutzerkonten im AD mit verbundenen Postfächern Exchange 5.5: Verteilerlisten =wird zu=> Exchange 2003: Universale Verteilergruppen im AD Exchange 5.5: Benutzerdefinierte Empfänger =wird zu=> Exchange 2003: Kontakte im AD Ein paar Vorarbeiten sind da aber noch zu machen: ================================= Postfächer: Im Exchange 5.5 ist es möglich, mehrere Postfächer einem NT-Benutzeraccount zuzuordnen. Unter Windows 2003 AD / Exchange 2003 existiert ein Benutzer im Active Directory, der, sobald er mailaktiv geschaltet wird, eine Email-Adresse und ein Postfach auf dem Exchange 2003-Server hat. Es ist nun möglich, diesem Benutzer weitere Email-Adressen zuzuweisen, es ist jedoch NICHT möglich, ein zweites Exchange-Postfach mit diesem Benutzer zu verknüpfen. In letzter Konsequenz heißt dies, dass es Probleme bei der Migration der Exchange-Daten geben wird, wenn im Exchange 5.5-Server mehrere Postfächer mit einem NT-Account verknüpft sind. Hierzu sollte VOR der Migration der Exchangedaten auf den neuen Exchange 2003-Server eine Überprüfung des Exchange 5.5-Servers mittels NTDSNoMatch-Utility stattfinden. Dieses Tool findet NT-Accounts, auf die mehrere Postfächer verknüpft wurden und stellt diese in einer *.csv-Datei dar. Das Tool NTDSNoMatch Utility befindet sich im Service Pack für den Exchange Server 2000 im Unterverzeichnis \temp\server\support\utils\i386\ntdsatrb. Einfach auf einem W2K3-Server installieren, gegen den Exchange 5.5 laufen lassen ("ntdsatrb Name des Ex5.5"), damit doppelte Postfächer pro Benutzer in der NT4-Umgebung erkennen und entsprechend gegenarbeiten. Meiner Meinung nach am Besten manuell, das Tool selber bietet keine große Hilfe bei der Fehlerbeseitigung... Genauere Erläuterungen hier: http://support.microsoft.com/default.aspx?scid=kb;DE;274173#appliesto#appliesto Ach ja: Bei der Installation vom NTDSNoMatchUtility erscheint evtl. eine Fehlermeldung, die besagt, das die Datei "msvbvm50.dll" nicht gefunden wurde. Diese Datei kann von einer Windows XP-Workstation ins Verzeichnis \windows\system32 des Servers kopiert werden. Des Weiteren ist es auch möglich, die Datei „msvbvm60.dll“, die sich im Unterverzeichnis \System32 befindet, zu kopieren und umzubenennen zu „msvbvm50.dll“ … Weiter im nächsten Thread...

... und "Verschieben" ist auch nicht genau treffend ... Replizieren ist besser ... ;) Wenn der ADC mit der Verbindungsvereinbarung steht, zuerst eine Replikation der öffentlichen Ordner (auch die versteckten/Systemordner nicht vergessen) einrichten, dann replizieren lassen. Wenn alle Ordner auf beiden Servern vorhanden sind, die Replikate vom 5.5er entfernen. Danach dann den 5.5er sauber deinstallieren... Grüsse schroeder750

Hy msdtp, habe es ja oben in meinem EDIT schon geschrieben, hat sich jetzt überschnitten. :D Eingekreist haben wir das Problem jetzt, aber ne Lösung haben wir noch nicht... Ist auch Mist, da jetzt in der registry rumzufuhrwerken... dann passt nachher die dir.edb nicht mehr... Wenn Du irgendwas in der Richtung testen willst, zieh auf jeden Fall vorher ein Image vom Exchange 5.5 ... das wird heikel... Grüsse schroeder750

... hmmm... habe nochmal nachgesehen ... http://www.admins-tipps.de/MS-Tutorials/Migration_von_Exchange_5.5_nach_Exchange_2003/Vorbereiten_der_Exchange_5.5_Umgebung.htm Ich glaube, das war recht einfach, man musste nur unter den Eigenschaften des Exchange 5.5 schlicht und ergreifend die Exchange-Organisation umbenennen... Aber das ist dann, glaube ich, nur der Display-Name ... Wie man den Directory-Name ändert weiß ich jetzt so auf Anhieb auch nicht... Am Besten mal googeln, das wird Dein Problem sein, glaube ich... Grüsse schroeder750 EDIT: Hat sich jetzt überschnitten, aber das Problem ist noch nicht geklärt ... habe aber auch momentan keinen Ansatz...

Wow, da dümpelt bei mir leise was im Hinterkopf... Der Exchange-Organisationsname darf keine Leer- oder Sonderzeichen enthalten, wenn man da einen Exchange 200x reinbringt. Du musst im Vorfeld die Exchange 5.5 Organisation umbenennen. Ich schaue mal nach, wie das war, da gab es einen KB-Artikel zu ... Grüsse schroeder750

Hy Daim, mein Hintergrund war einfach folgender: habe letztens ein Partnerunternehmen von mir telefonisch betreut, da wurde auch ein 2003er DC in ein 2000er AD gebracht, das vorher mit adprep aufgemotzt wurde. Ursprung war hier auch ein W2K DC mit SP2 und ein Exchange 2000. Hier wurde also auch vorher noch die Geschichte mit inetorgpersonprevent durchgezogen. Hat alles sauber funktioniert, vom AD her keine Probleme, nur hat der neue 2003er Exchange nachher noch ein bisschen was angemeckert, daß er bei der Replikation leichte Probleme hatte, eben weil auf dem Gegenüber nur SP2 installiert war. Hat jetzt nichts unmittelbar hiermit zu tun, die Replikation ist auch gelaufen, da keimte jetzt gerade nur der leise Verdacht in mir auf, daß es evtl. doch mit "nur" SP2 Problemchen geben könnte. Wie gesagt, shietegal wer hier recht hatte, ich nehme solche kleinen Winks nur ganz gerne auf um ein wenig "Grundlagenforschung" zu betreiben... :D Danke Dir für die Infos !! Grüsse schroeder750

Hört sich gut an Worauf ? Bisher habe ich es so verstanden, daß der alte DC nur neu installiert werden soll, also gleiche Hardware, oder nicht ? Wenn Du neue Hardware hast und der Server nachher gleich heißen soll, würde ich den neuen Server ohne Verbindung zur Domäne erstmal mit dem gleichen Namen aufsetzen, wie er später heißen soll. Dann kurz umbenennen und in die Domäne bringen. Dann, wenn der alte raus ist, den neuen wieder umbenennen. Es gibt da einige Einträge in der registry, die auch beim Umbenennen nicht unbedingt umgebogen werden. Ist weniger mit Reibung behaftet, einen Server mit dem namen zu installieren, den er später auch haben soll.. Ansonsten sieht das so ganz gut aus, wie Du es vorhast... Grüsse schroeder750

@Daim: O.K. Lass uns Haarspaltereien machen :D :D :D - Neee, Spass beiseite ... Wenn ich auf einem 2000er DC das adprep anschmeiße, bekomme ich in der DOS-Box folgende Meldung: "...Alle Windows 2000 Domänencontroller sollten auf Service Pack 1 mit QFE265089 oder auf Windows 2000 oder höher aktualisiert werden, bevor ..." Sei so gut und gib mir bitte mal kurz Info, wo Du die Info mit dem SP3 herhast ? Jetzt BITTE auf keinen Fall falsch verstehen, erstens mal geht es mir hier echt nicht drum, wer Recht hat oder nicht (wirklich nicht) und zweitens wird es in den meisten Fällen eh egal sein, weil man heutzutage eh meist schon auf SP4 ist. Mir geht es nur ganz einfach drum, ob MS da irgendwo wiedersprüchliche Aussagen verbreitet... wäre ja schon mal interessant zu wissen... Hast Du die Info aus nem Technet-Artikel ? Grüsse schroeder750

Moin nonic, sehe da auch keine größeren Probleme, wenn die Applikationen das mitmachen, wie Daim es schon sagte. Folgendes beachten: - Auf den 2000er DCs sollte MINDESTENS Service Pack 2 installiert sein - Bevor Du einen 2003er DC ins AD bringst, muss das Schema auf einem der 2000er DCs erweitert werden. (adprep /forestprep + adprep /domainprep von der W2K3-Server CD ausführen). Wenn Du einen Exchange 2000 im Einsatz hast, der das Schema unter 2000 schon aufgebohrt hat, muss vorher noch eine Kleinigkeit verändert werden (inetorgpersonprevent), sollte das der Fall sein, meld Dich einfach nochmal kurz, O.K ? Grüsse schroeder750

moin ruzduzdavid, schau doch mal hier rein: http://www.msexchangefaq.de/internet/firewall4.htm Ziemlich weit unten steht was, was Dir erstmal weiterhelfen könnte. Grüsse schroeder750

Mal was generelles zu Profilen und Freigaben und Daten auf Fileservern usw... Ich habe mir angewöhnt (auch wenn es anderslautende Meinungen gibt, was ja absolut legitim ist), sämtliche Berechtigungen auf NTFS-Ebene zu setzen und die Freigaben dann einfach nur zu geben, d.h. für alle Vollzugriff. Von der Freigabe her kann dann jeder drauf zugreifen, wer dies aber nicht können soll, bekommt dann von den NTFS-Berechtigungen auf die Finger gehauen. So kann man sich ein Script erstellen, mit dem ich relativ fix wieder die Freigaben setzen kann und alles mit xcopy ( xcopy \\nt4fileserver\share \\w2k3fileserver\share /E /C /H /O /Y ) incl. NTFS-Berechtigungen auf den neuen Server rüberkopieren. Anschließend das Script für die Freigaben wieder drüber und fertig. Das Script für die Freigaben kann man sich relativ einfach zusammenbauen: - Net share Befehl absetzen und in eine Textdatei schreiben lassen - Textdatei bereinigen, so daß nur noch Namen der Verzeichnisse und Freigabenamen auftauchen - Excel öffnen, die Spalten mit den Verzeichnissen und Freigabenamen aus der Textdatei einfügen - Den Rest "drumherumbauen", also in der Form: net share Freigabename=Laufwerk:Pfad Hierzu an den richtigen Stellen Spalten einfügen und die Dinge wie "net share" einbauen. - Anschließend den Inhalt der Excel-Tabelle in eine Textdatei exportieren und zum Schluss umbenennen in *.cmd. Fertig ist das Script. Spiel damit mal rum und teste ein wenig in der VMWare-Umgebung... Ach ja da war noch die Frage, ob Du die Profile migrieren kannst, wenn die User angemeldet sind... meiner Meinung nach solltest Du solche Aktionen am Wochenende oder abends machen... stress Dich nicht. Bei der Migration wirst Du eh einige Abende und Wochenenden in der Firma verbringen... So, das wars erstmal dazu, als nächstes wäre dann der Exchange dran. Das schaffe ich aber heute wahrscheinlich nicht mehr. Später mehr dazu, O.K ? Grüsse schroeder750

Moin zusammen, sorry, hab mich die letzten Tage etwas dünne gemacht, da is leider noch ein Job, in dem ich meine Brötchen verdienen muss :D Habe ein paar Minuten zeit und dachte, ich mach mal ein bisschen weiter... :) Habe mal durchgelesen, was in den letzten Tagen hier so passiert ist und kann hh2000 auf jeden Fall schon mal zustimmen. Die Möglichkeit mit dem Backup ist eine sehr gute Möglichkeit, die ich auch des Öfteren einsetze. Hier halt darauf achten, daß mitgenommen wird, was mitgenommen werden soll, also evtl. NTFS-Berechtigungen und Freigaben. Im NT4-Benutzermanager musst Du wohl jeden einzeln anfassen, in der W2K3 MMC jedoch kannst Du viele Benutzer auf einmal markieren und dann über die Rechte Maustaste und "Eigenschaften" solche Dinge bei vielen Objekten (Eigenschaften von mehrfachobjekten) gleichzeitig bearbeiten. Solange sich die User also in der alten Domäne anmelden und auf den alten Fileserver zugreifen, keine Probleme. Wenn die User dann in die neue Domäne rüberkommen, werden ja die Einstellungen übernommen, d.h. auch die Infos zu den Profilpfaden. Da passt dann auch noch alles. Wenn nun der Server für die Profilpfade geändert wird, kann man das im AD ja bei allen Benutzern recht einfach ändern (siehe oben). Wenn also zuerst die Benutzer im AD sind und sich da auch anmelden und DANN erst der Profilserver und anschließend die Pfade geändert werden, geht das schlüssig auf. Problematisch ist es nur, wenn dann immer noch User in der alten Domäne angemeldet werden. Da musst Du dann mühsam via Hand im NT4-Usermanager nachregeln. Lässt sich aber bei vernünftiger Planung umgehen. ... schlecht ... wie sollst Du als Admin administrieren, wenn Du keine Berechtigungen hast ? Wie wird denn hier ein Backup gezogen, wenn es keinen Account gibt, der die Berechtigungen hat ? :) Ich würde mir die Berechtigungen verpassen, so viel Vertrauen in den Admin sollte sein... Hierzu bedient man sich des Tools „subinacl“ aus dem Resource Kit: “Subinacl /file \\NT4-Profilserver\share /grant=w2k3dom\administrator=f” Dieser Befehl gibt dem Administrator der neuen Domäne (hier: w2k3dom) VOLLEN Zugriff (=f) auf die Daten. Anschließend kann der xcopy-Befehl abgesetzt werden. Achtung: mit subinacl werden dem Administrator der neuen Domäne Berechtigungen ZUSÄTZLICH zu den bereits bestehenden NTFS-Berechtigungen gewährt. Wird versucht, über einen rechten Mausklick auf den jeweiligen Share die NTFS-Berechtigung für den Administrator zu vergeben, ist es schnell passiert, dass bestehende NTFS-Freigaben durch diese ERSETZT werden !!!! Die vorherigen NTFS-Berechtigungen existieren dann nicht mehr !!! Also mit Gefühl drangehen und vorher sauber testen... :D ... weiter im nächsten Thread...