schroeder750

Moin Butze0815, was genau willst Du bezwecken ? Geht es Dir bei der "Gruppe in der Adressliste" um eine Verteilergruppe aus dem AD ? Willst Du, daß diese nur von bestimmten Personen gepflegt wird ? Grüsse schroeder750

Moin, Dirk sprach von 5 fsmo-Rollen... oben sind nur 4 aufgelistet. Mir fehlt oben in der Auflistung noch der Domain naming master. (Active Directory Domänen und Vertrauensstellungen, Rechtsklick, Betriebsmaster). Ist der auch schon verlegt ? Am einfachsten: Support-Tools installieren und in einer DOS-Box den Befehl "netdom query fsmo" absetzen. Da sieht man alle 5 auf einen Blick... Nicht das der untergeht ... :D Würde aber auch gemeldet werden, wenn man den dcpromo ausführt ... Grüsse schroeder750

... ach ja, einen hammwer noch: 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

... definitiv Ja. Die User wurden ja mit SID-History migriert, das passt dann... 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... 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... ... 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 Puha, da hat sich jetzt einiges überschnitten... :D Sind noch Fragen offen geblieben ? :cool: - Gibs mir ... :p Grüsse schroeder750

... das war mehr so theoretisch... :suspect: ich würde keine NT4 Memberserver mehr in die neuen Strukturen bringen. Deswegen machst Du ja unter anderem eine Parallelmigration. Die beiden Domänen können von mir aus sehr lange nebeneinander existieren, die NT4-Domäne wird erst dann ausgeknipst, wenn alle Ressourcen in die neue Struktur migriert wurden. Spar da nicht am falschen Ende... Sonst hast Du später eine W2K3 AD-Struktur mit alten NT4-Gurken drin. Wo ist da der Sinn der Migration ? ;) ... man könnte z.B. auch den neuen Exchange mit einer eigenen, neuen Organisation aufbauen. Dann ist eben nix mit mal eben öffentliche Ordner replizieren und Postfächer rüberschubsen... Der Trust bleibt so lange stehen, bis wir in der alten NT4-Domäne das Licht ausknipsen und das ist erst der Fall, wenn ALLES drüben ist... ... indem man die Useraccounts in der neuen Domäne z.B. so lange deaktiviert, bis man WILL, daß sie sich in der neuen Domäne anmelden. Also erst nach erfolgreichen Tests mit Profilen usw. usw. Man sollte sich immer Gruppen von Usern schnappen, denen man die PCs in die neue Domäne bringt, nachdem man die Profile rüberkopiert hat und z.B. die Postfächer rübergeschoben hat. Das kann man sehr übersichtlich gestalten... Weiter im nächsten Thread... :)

Ja ... ??? Verstehe ich jetzt nicht ganz... Du kannst Dich anmelden, wo Du willst und wirst auf beide Exchangeserver den Zugriff haben... Wenn die User allerdings noch in der NT4-Umgebung arbeiten und die Postfächer schon auf dem neuen Exchange 2003 liegen, kann es da gewisse Berechtigungsprobleme geben. Also am Besten zuerst User in die neue Domäne und dann erst die Postfächer rüber... Da Du mit einem Trust arbeitest, ist es für den Exchange absolut egal, ob die Domäne im native mode ist, oder nicht. Früher hat man bei Firmen mit mehreren Aussenstellen auch einzelne Domänen aufgebaut und die darin laufenden Exchangeserver in die gleiche Organisation gebracht. Hier machen wir es genauso. Der neue Exchange 2003 läuft in der AD-Struktur, wird aber bei der Installation in die gleiche Organisation gebracht, wie der alte. Weiter im nächsten Thread ... :D

Hy Christoph !! Danke fürs reinschauen und mithelfen ! Damit ist eigentlich schon alles gesagt. Ich führe Migrationsschulungen durch, in denen ich live auf einem Rechner mit teils noch weniger als 2 GB Ram Migrationen vorführe. Was benötigt man in der Testumgebung ? - Hostbetriebssystem z.b. WinXP = 128 MB RAM - NT4 PDC = 96 MB RAM - NT4 BDC = 96 MB RAM - NT4/Exchange 5.5 = 128 MB RAM - W2K3 Server (DC+Exchange 2003) = 256 MB RAM - Testclient (W2K oder XP) = 128 MB RAM summa summarum nicht mal ganz ein Gigabyte... Alle Maschinen zwecks Performance evtl. noch ein bisschen mehr mit RAM ausgestattet, da reichen 1,5 - 2 Gig locker aus... Testspielereien wie Fileserverdaten, Profile usw. incl. Berechtigungen aus der alten in die neue Domäne bringen kann man auf den oben genannten Servern zusätzlich abfackeln, ebenso wie Drucker usw... soll ja zum Testen sein und nicht produktiv... Weiter im nächsten Thread... schroeder750

Moin mirki, sorry, daß ich bisher noch nicht reagiert habe. Liegt einfach daran, daß ich momentan echt keinen Ansatz sehe... Übrigens ist das hier leider nicht sonderlich aussagekräftig: ... ääähmmm, die Frage war "Ist es A oder B" die Antwort: Ja ... hmm ?? :) :) :) Die Frage, was es mit dem OWA zu tun hat, ist natürlich absolut legitim, wie schon gesagt, hat es bei mir in der Testumgebung auch nicht mehr hingehauen, OWA zu starten, wenn die Maildomäne umgebogen wurde. Das funktioniert alles wunderbar, wenn Du in der policy die alte Maildomäne drin lässt und ansonsten drumherum neue Maildomänen anlegst. Aber genau dann taucht ja unser Problem auf, daß die User vom alten Exchange keine Mails an die User vom neuen Exchange senden können... Darauf lässt sich unser Problem einkreisen. Also entweder a) dafür sorgen, daß die Maildomäne vom alten Server verschwindet und Grundlagenforschung betreiben, warum dann das OWA nicht mehr funktioniert (wobei ich dafür wirklich momentan keinen Ansatz habe :mad: ) oder b) über die Vorschläge aus meiner letzten Antwort nachdenken und dabei auch die firmenpolitischen Entscheidungen mit bedenken. Das wird aber dann eine größere Aktion. Ich denke nur, die Vorgehensweise, die DU / Ihr gewählt habt, ist technisch einfach problematisch. Ich hatte ja auch gehofft, daß noch wer anders zu uns stösst, der sich im Exchange gut auskennt und evtl. ne Idee hat, aber wie Du siehst, bisher leider nix. Ich muss ganz ehrlich gestehen, daß ich echt null Ansatz habe, wo man noch hingreifen könnte, um die Maildomäne vollends vom alten Server zu entfernen, ohne daß es beim OWA kracht... :mad: Wurmt mich selber ... Du hattest von Berechtigungen von einem Script gesprochen. Was für ein Script meinst Du ? Grüsse schroeder750

Moin Coyote, einen habbich übrigens noch so nebenbei, ein Tip, den ich in solchen Fällen öfter gebe: Da Du das alles sauber planst, solltest Du Dir evtl mal die Zeit nehmen, alles in einer Testumgebung durchzuspielen, dann ist das nachher ein "Heimspiel", wenn Du es in der produktiven Umgebung machst. Besorg Dir einfach VMWare Workstation oder Virtual PC (von beiden gibt es Testversionen zum Runterladen, in beide hat man sich relativ fix eingearbeitet). Ich habe den Aufbau so einer Testumgebung, abgesaugt aus der produktiven Umgebung in diesem Thread: http://www.mcseboard.de/showthread.php?t=80790 mal beschrieben. Kann auf keinen Fall schaden, an der "fast produktiven" Umgebung in Ruhe testen zu können... :D Grüsse schroeder750

Moin Maik, schon mal die Verbindungsvereinbarung für die öffentlichen Ordner im ADC platt gemacht und neu angelegt ? Ist mir nicht ganz unbekannt, daß die schon mal Probleme haben. Ich lege sie meist neu an und dann tun die Dinger auch oft wieder. Sag mal, wie lange soll denn die Mischumgebung so noch stehen bleiben ? Ich benutze den ADC meist für die Parallelmigration und dann verschwindet der recht fix wieder ... Grüsse schroeder750

Siehe oben... sobald ein Trust steht, können sich die Clients potentiell in beiden Domänen anmelden. Man kann es aber in der neuen Domäne verhindern, wenn man es nicht will. Zum migrieren der Clients gibt es hier im Board einen Thread über das Tool "netdom", mit dem es gut zu gehen scheint. Den Computermigrationsassistenten des ADMT kann ich NICHT empfehlen. Ich habe die Dinger bisher immer manuell in die neue Domäne integriert. Kommt auf die Anzahl an. Ich traue generell erstmal nur meinen eigenen Pfoten ... wenn das nicht zu viele sind, dann lieber manuell. Ansonsten solltest Du den Thread über das moven mit netdom inhalieren ... :D EDIT: Hier isser: http://www.mcseboard.de/showthread.php?t=75857 Zu den Profilen kommen wir später noch, O.K ? Grüsse schroeder750

Kein Problem, schreibe ich eben langsamer... :D Hört sich schon wesentlich symphatischer an. :D Wie Du genau einzelne Ressourcen evtl. zwischenparkst, wenn Du die Server neu aufsetzt, gehen wir dann an, wenn es soweit ist. "Native mode" heißt schlicht und ergreifend nur, daß keine DOMÄNENCONTROLLER kleiner W2K oder W2K3 (je nach native mode) mehr in der neuen Domäne erlaubt sind. Und wir haben ja nicht vor, in die neue Struktur noch NT4 BDCs zu bringen, oder ? Genau deswegen machen wir ja ne Parallelmigration ;) Man könnte sogar noch NT4 Memberserver in diese AD-Struktur bringen, wenn man denn wollte. Hat aber überhaupt gar nichts mit dem Zugriff aus einer getrusteten NT4-Domäne zu tun... Den Exchange bringen wir später als Exchange 2003 auf einem Win2003 Server in die neue Domäne, achten aber darauf, daß er über den Trust hinweg mittels ADC usw. in die gleiche Organisation kommt, wie der jetzige Exchange 5.5 in der NT4-Domäne. Dann kann man prima öffentliche Ordner replizieren und Postfächer schubsen ... Per default melden sich die Rechner noch in der alten Domäne an. Wenn man in die neue will, muss man das explizit auswählen bei der Anmeldung. Man kann ja die Anmeldung in der neuen Domäne auch so lange verhindern, bis man die Profile sauber rübergeholt hat. Und erst dann werden auch die Clients in die neue Domäne gebracht. Erfahrungsgemäß ist es vorteilhaft, die Clients zu einem recht frühen Zeitpunkt in die neue Domäne zu bringen und die Server / sonstige Ressourcen dann in Ruhe nachzuziehen. Du migrierst zuerst die Gruppen, dann die Benutzer. Danach wirst Du feststellen, daß alles sauber rübergenommen wurde, nur eben der Administrator der alten Domäne nicht. Die Gruppen, in denen der Administrator der alten Domäne vorher Mitglied war, werden überprüft und der Administrator der neuen Domäne dort wieder hinzugefügt. Am einfachsten ist es, sich den Administrator der alten Domäne anzusehen und nachzuschauen, wo der überall Mitglied ist. Dann rüber in die AD Struktur und dort den neuen Administrator eben wieder genau bei diesen Gruppen eintragen. Sache von wenigen Minuten, muss nur beachtet werden... Grüsse schroeder750

:D Prima. Gerne ! Schau Dir den Link von Dippas mal an, das is ne gute Alternative ... ;) Grüsse schroeder750

Sooo, Du hattest jetzt über 20 Minuten Zeit. Wird Zeit weiterzumachen :D :D :D Harrr ... - Mit dem ADMT zuerst die Gruppen rüberholen, dann die Benutzer: Hier als Beispiel mal die Benutzermigration: - Ich erstelle mir ganz gerne in der AD-Struktur eine neue OU, z.B. "NT4-Importe", in die ich erst einmal die Benutzer reinmigriere. Verschieben kann man immer noch... Wenn was nicht ganz sauber laufen sollte, kann ich die ganze OU killen und wieder neu erstellen. Dann habe ich nichts mit den im AD schon standardmäßig vorhandenen Usern am Hut und muss nicht groß raussuchen, was ich gerade evtl. falsch rübergeholt habe... - Rechte Maustaste auf "Active Directory Migrationsprogramm" - Auswahl "Assistent zum Migrieren von Benutzerkonten" - "jetzt migrieren" auswählen (testen kann jeder, nix für Wikinger...) Quelldomäne = NT4-Domäne / Zieldomäne = W2K3-Domäne … - Mit "Hinzufügen" die zu migrierenden Benutzer auswählen - Als Ziel die neue OU angeben, die oben erstellt wurde. - "Kennwörter migrieren" angeben und auf den BDC verweisen, der den PWDMig-Server hat... - Ziel- wie Quellkonten behandeln und Haken setzen bei "Benutzer SIDs migrieren"... - Hier dürfte eine Meldung kommen, daß das Auditing nicht eingeschaltet ist (auch wenn man es vorher eingeschaltet hat), hier mit "Ja" bestätigen, daß es eingeschaltet werden soll. - Die weiteren Fragen nach Geschmack beantworten und die Migration anstoßen... - Ergebnisse im AD prüfen. (Wurden alle Einstellungen und Gruppenzugehörigkeiten übernommen ?) Noch ne Anmerkung: Einige vordefinierte Benutzer / Gruppen existieren bereits in der neuen AD-Struktur. Diese Accounts führen bei der Ausführung des ADMT zu Fehlermeldungen. Hier sei beispielhaft der Account des Administrators angeführt. Auf Grund der Existenz dieses Benutzers in der neuen AD-Struktur wird hier nicht mit SID-History migriert. Es sollten also nach der Migration mittels ADMT die Gruppen überprüft und entsprechend aktualisiert werden, speziell die Gruppen, in denen der Administrator Mitglied ist. Gleiches gilt im späteren Verlauf für Postfächer von vordefinierten Konten. Hier muss manuell zusammengeführt werden. ... damit hast Du schonmal einen Stand, der sich sehen lassen kann. Die Benutzer können sich jetzt in beiden Domänen anmelden und arbeiten. Der Migration der weiteren Ressourcen steht nun nicht mehr viel im Weg... Weiter demnächst in diesem Kino, O.K ? :D Mach einfach meldung, wenn es weitergehen soll. Grüsse schroeder750

... Jouuuhh !! Wäre ne gute Idee :D :D :D Grüsse schroeder750

Ahoi, Sehr ordentlich :D :D So sollte jeder denken :D ... solltest Du nochmal drüber schlafen ... bin ich wirklich kein Fan davon ... :suspect: Gut, dann lass uns beim Passwort Export Server weitermachen... Ich gehe mal davon aus, daß folgende Vorarbeiten schon erledigt sind: - Aufbau Trust / Deaktivieren des SID-Filters - Verschachtelunng der Gruppen / Vergabe der Berechtigungen - Installation und Konfiguration ADMT - Erstellen einer lokalen Gruppe in der NT4-Umgebung mit dem Domänennamen und drei $ hintendran - Einschalten des Auditing (Überwachung) Wenn dazu noch Fragen auftauchen, einfach Meldung machen, O.K ? Gut, dann Passwort Export Server: - NT4 PDC: Unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA den Wert "TcpipClientSupport" als "REG_DWORD:0x1" hinzufügen, Neustart des Servers - Auf dem NT4 PDC und dem BDC, auf dem der Passwort-Export Server landen soll, müssen die administrativen Freigaben (C$ usw.) bestehen... - 128 Bit Verschlüsselung muss aktiv sein (notfalls den IE 601 SP1 auf PDC und BDC installieren) - Encryption key: Eine leere Diskette ins Laufwerk des W2K3 DCs einlegen, auf dem ADMT installiert wurde. Folgenden Befehl in einer DOS-Eingabeaufforderung absetzen: "admt.exe key %SourceDomainNetBIOSName% Zielpfad\Zieldatei Beispiel: admt.exe key nt4dom a:\key\ Dieser Befehl speichert den Key für die Domäne „NT4DOM“ auf dem Laufwerk a:\key\*.pes des W2K3-DCs - Installation PWMig-Server auf einem BDC in der NT4-Domäne (bestenfalls extra dafür einen neuen BDC installieren, wenn es Probleme gibt) - Ausführen der Datei Pwdmig.exe aus dem Unterverzeichnis "PWDMIG" des ADMT 2.0-Installationsverzeichnisses - Diskette einlegen, Name der Encryption Key-Datei von oben angeben. - BDC neu starten - Danach Kontrolle: Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa muss unter dem Eintrag "AllowPasswordExport" der Wert "1" gesetzt sein. Witzigerweise steht der meistens auf "0" ... no comment... - W2K3 DC: Benutzer "Jeder" und "Anonymous" zur Gruppe Prä-Windows 2003 kompatibler Zugriff" hinzufügen. - Default Domain Policy öffnen: Unter „Computerkonfiguration“ => „Windows-Einstellungen“ => „Sicherheitseinstellungen“ => „Kontorichtlinien“ => „Kennwortrichtlinien“ im rechten Feld die Richtlinie „Kennwort muss Komplexitätsvoraussetzungen entsprechen“ deaktivieren. - Ist übrigens ein guter Zeitpunkt, die neue Domäne jetzt in den native mode zu schalten, falls noch nicht passiert ... Danach dann Benutzermigration mit dem ADMT, natürlich incl. SID-History und Kennwörtern. Sooo, geh das erstmal durch und meld Dich wieder, O.K ? Dann machen wir an unserer Monsterdoku weiter ... :D Grüsse schroeder750

... und noch ne kurze Hilfestellung zum Testen, was hier genau bei crocrow nicht geht: Habe hier ne Testumgebung mit Exchange 2003. Es gibt einen Benutzer bzw. Mailadresse: "u.mueller@testdom.de", richtiger Name: Mueller, Ute. Ich habe der guten Dame eben zusätztlich "rumpelstielzchen@testdom.de" verpasst und anschließend unter dem Adminaccount via OWA eine Mail an "rumpelstielzchen@testdom.de" geschrieben. Wenn ich auf das Feld zum Auflösen der Mailadresse klicke, wird auch sofort "Mueller, Ute" eingetragen... Das sollte auf jeden Fall funzen, wenn nicht, stimmt da von vorne herein etwas nicht. Übrigens dauert das schon mal ein Weilchen, bis das durchs AD durch ist... mal den Replmon bemühen oder einfach etwas Geduld haben... gerade wenn mehrere DCs im Einsatz sind ... Grüsse schroeder750

... ach soooo, dann reicht es natürlich normalerweise aus, den einzelnen Usern nur eine weitere Adresse mit der gleichen Domain hintendran zuzuweisen. Dann muss natürlich auch nicht dem Exchange beigebogen werden, daß er auch auf andere Domains hört... Im Outlook zu sagen, unter welcher Adresse genau gesendet werden soll wird schwierig. afaik nimmt Outlook immer die Hauptadresse ... Das auswählen einer anderen Absendeadresse geht nur mit "Senden als", also wenn man von einem ANDEREN BENUTZER das Recht bekommen hat, in dessen Auftrag zu senden... Was passiert denn genau, wenn Du eine Mail an eine der neuen Adressen schickst ? Grüsse schroeder750

... mehrere Mailadressen geht über die Default policy im System Manager oder und /oder manuell bei jedem Benutzer eine neue SMTP-Adresse hinzufügen. NUR den Benutzern eine weitere Adresse zu verpassen reicht nicht, da man dem Exchange noch beibiegen muss, daß er auch auf diese Mailadressen hört. Grüsse schroeder750

Hy Coyote, ich mache gerne weiter, nur ist das irgendwie so ein wenig komisch, hier alleine herumzuschreibseln, wenn kein akuter Bedarf da ist... Geplant war es, hier im Dialog vorwärts zu kommen, wenn jemand gerade mit diesem Thema beschäftigt ist. Bist Du gerade an einer Migration dran ? - Dann sag mir, wo Du gerade hängst und wir machen sehr gerne weiter, kein Problem. ich wollte mich hier nur nicht als Schiftsteller betätigen, der nicht mal weiß, ob ihm gerade irgendwer zuhört ... :D Wenn Bedarf ist können wir gerne sofort weitermachen. ;) Grüsse schroeder750

Hy mirki, ganz ehrlich, ich habe es echt noch nicht gemacht, einem Exchange die komplette EMail-Domäne, auf die er hören soll, umzubiegen... Ich hätte irgendwie versucht, das anders anzugehen... Ist es nicht möglich, den Exchange für die "Aussenstelle" sage ich jetzt mal, als Memberserver der Domäne anzubinden, in der sich der jetzige Exchange auch befindet ? Für die Anmeldungen der Benutzer am "domainfremden" Exchange kann man ja einen Trust aufbauen... Dann könnten die Postfächer der umgezogenen Benutzer auf den neuen Exchange verschoben werden, der erste Exchange holt weiterhin die Mails ab und gibt sie an den Neuen weiter... Ich hätte irgendetwas in dieser Richtung favorisiert... Ich bin auch noch nicht so ganz dahintergestiegen, warum Ihr das so löst... der alte Exchange soll also die Mails für die bestehenden Postfächer nicht mehr holen, die liegen jetzt auf dem neuen. O.K... bekommt der neue jetzt auch die Mails direkt von draussen oder läuft das weiterhin über den alten ? Was treibt der alte jetzt ? Hat der dann überhaupt noch eine Daseinsberechtigung ? Bekommen die User, die noch auf dem alten verbleiben, jetzt neue Adressen ? Klär mich bitte nochmal etwas genauer auf, O.K ? Das einige User einen eigenen Exchange bekommen kann ich nachvollziehen. Das sie die gleichen Adressen behalten sollen auch. Aber das da ein "fremder" neuer Exchange in einer eigenen Domäne aufgezogen wird, finde ich irgendwie nicht logisch. Ich hätte einen zweiten in der gleichen Organisation hochgezogen... Mailadressen bleiben, zwischen den Exchangeservern können prima Mails hin und her geschickt werden, man muss an der externen Connectivität nix schrauben... alle sind glücklich ... Hilf mir, Dir zu helfen ... :D Grüsse schroeder750

... Du arbeitest an einem Server, an dem das Schema geändert werden darf und bist mit einem Benutzer angemeldet, der es darf ? Grüsse schroeder750

Moin moin, bitte daran denken, daß, wenn via exmerge die Postfächer exportiert werden, nur die reinen Nutzdaten rübergeholt werden. Sämtliches "Drumherum" wie Berechtigungen (x hat Posteingang + Kalender für y freigegeben usw.), Abwesenheitsnotizen, servergespeicherte Regeln usw. usw. wird dabei verloren gehen und muss gesondert betrachtet werden. Die öffentlichen Ordner kann man, soweit ich das weiß, nicht mit exmerge rausholen, da sollte man sich ein Outlook schnappen und die ganze Struktur in eine *.pst exportieren. An dieser *.pst kleben dann noch Berechtigungen dran, die bei Einspielen in den neuen Exchange evtl. unschöne Nebeneffekte haben können. Tip von mir wäre daher in diesem Fall ein Outlook an den neuen Exchange zu hängen, hier die *.pst der öffentlichen Ordner zusätzlich öffnen und die Inhalte per Drag & Drop in die neue öffentliche Ordner-Struktur zu ziehen. Auf jeden Fall vorher in Ruhe Gedanken machen, was evtl. noch so am Exchange eingerichtet wurde und bei Nichtbeachtung über die Klinge springen wird (Formulare usw...). Grüsse schroeder750

... noch ein schneller Nachtrag aus meinen Tests: - Die Namensänderung der Strukturen auf Laufwerk M: ergibt sich erst nach einem Neustart des Informationsspeicherdienstes, wenn die policy geändert wurde. - Die User hatten ja vorher die ursprüngliche Mailadresse und sehr wahrscheinlich ja auch ihre Mailadressen entsprechend publiziert. Wenn Du die alten Adressen jetzt komplett killst und durch eine neue ersetzt, werden da aber einige Mails nicht ankommen. Ich denke, da ist doch oben beschriebene Methode das Beste. So existiert die alte Adresse noch zum Mailempfang und beim Versenden von Mails wird automatisch die neue (Hauptadresse) genommen und so publiziert. So, nun aber genug. Jetzt warte ich erstmal auf Rückinfos von Dir ... :p Grüsse schroeder750

O.K. ich glaube, ich kann das nachvollziehen... Du hast in der default policy die Standard-Hauptadresse geändert, stimmts ? Habe das gerade getestet und bekomme die gleiche Fehlermeldung. Ich würde folgendes versuchen: Ändere die Hauptadresse wieder zurück auf den alten Wert und erstelle eine zusätzliche SMTP-Adresse in der default policy, die Du dann zur Hauptadresse machst... Die User haben dann alle Ihre alte Mailadresse und zusätzlich als Hauptadresse die neue. OWA wird noch funktionieren, die Struktur auf M wird nicht umbenannt und der Exchange hört auch auf die neuen Mailadressen der User. Könnte das als Lösung für Dich reichen ? Grüsse schroeder750