schroeder750

@christoph: ... und das ist gut so ... :D Ich bitte darum !! ;) @coyote: Zum Clustern unter VMWare: natürlich kann man unter VMWare einen Cluster abbilden, hierbei ist folgendes (grob beschrieben) zu beachten: - Die (System-)Festplatten der virtuellen Maschinen müssen IDE-Platten sein, es muss angegeben werden: "Persistent: Changes are immediately and permanently written to disk" - Die gemeinsam genutzten Platten (Quorum usw...) müssen SCSI-Platten sein, es muss angegeben werden "Allocate Disk Space now" und auch wieder "Persistent: Changes are immediately and permanently written to disk" - Anschließend muss in der vmx-Datei der virtuellen Maschinen der Wert "dis.klocking=false" angegeben werden, damit beide Maschinen potentiell Zugriff auf die Platten haben können. Den Rest regeln dann später die Clusterdienste. Das können wir gerne später vertiefen, die Frage ist aber, ob es in der virtuellen Umgebung wirklich ein geclusterter Exchange sein muss... Das der Exchange 2003 sich prima clustern lässt, wissen wir, das brauchst Du nicht zu testen. Und bei der Migration auf einen Cluster gibt es eigentlich keinen Unterschied zur Migration auf einen Standalone-Exchange... Ist wirklich die Frage, ob Du Dir das in der Testumgebung geben willst. Ausser natürlich, Du möchtest generell mal Erfahrung mit nem 2003er Exchange-Cluster sammeln. Das würde ich dann aber wieder in einer eigenen Testumgebung machen... Wie dem auch sei, gib Bescheid, wenn Du genauere Infos brauchst... ;) Zu den servergespeicherten Profilen hatte ich ja weiter oben schonmal was geschrieben. Ich denke, da gibt es soooo viele Stolperfallen nicht... die Clientversionen bleiben ja gleich, d.h. Du migrierst ja nicht von "\Winnt\Profiles" nach "Dokumente und Einstellungen\...", sprich von NT4 auf XP-Profile oder etwas in der Art. Die grundsätzliche Struktur der Profile bleibt ja erhalten. Da ist eigentlich nur darauf zu achten, daß die Clients, egal in welcher Domäne sie sich jetzt anmelden, an ihre Profile kommen und die Berechtigungen haben. In diesem Kontext einfach darauf achten, daß die Einstellungen in den Benutzerkonten / Logonscripten passen... Clientmigration haten wir ja auch schon angerissen (movedom / netdom / manuell), wenn da spezifische Fragen auftauchen, lass es uns wissen, dann können wir drüber diskutieren. Zur Exchangemigration werde ich demnächst was schreiben, habe jetzt momentan nicht die Zeit, das schiebe ich asap nach, O.K ? Was generelles: Auch wenn die eigentliche Migration erst für später geplant ist, läuft das mit der Testumgebung denn jetzt relativ fix an ? Wird für Dich nicht sehr einfach werden, wenn Du jetzt alle Infos theoretisch von uns bekommst und einfach nur so in Deine Planung einfügst, ich denke, das wäre besser, wenn Du das evtl. jetzt alles direkt mal live testen könntest... :D Sonst sitzt Du irgendwann vor der Geschichte und merkst erst, was Du alles hättest fragen müssen ... :p Bis später !! Ciao schroeder750

@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

Super !!!! Freut mich. Und danke für die Info !! Immer mal gut zu wissen... ;) Grüsse schroeder750

Moin space, ... das aktuelle Service Pack hast Du nach der Repairinstallation schon noch drübergezogen, oder ? Grüsse schroeder750

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

Moin moin, ich hab ne Fritz Box Fon WLan im Einsatz, "FRITZ!Box Fon WLAN (UI), Firmware-Version 08.03.91" Im Menu unter "System" => "Nachtschaltung" kann man da einstellen, wann die gute FritzBox sich schlafen legen soll... Originalzitat aus der Konfiguration: Ich denke, problematisch dürfte der Satz sein, daß erst abgeschaltet wird, wenn keine WLan-Geräte mehr aktiv sind... das werden die lieben Kiddies schnell schnaggeln :D Grüsse schroeder750

Moin moin, mal kurz etwas Senf von mir dazu: Terminalserver produktiv unter VMWare GSX-Server zu virtualisieren halte ich persönlich nicht für sonderlich elegant. Wenn mehrere gleiche Maschinen auf einem Server virtualisiert werden, wird eine deutliche Ressourceneinsparung dadurch verursacht, daß Fragmente, die von allen Maschinen gleichermaßen benötigt werden nur einmal in den Arbeitsspeicher geladen werden müssen und so allen weiteren virtuellen Maschinen zur Verfügung stehen. Das kann ein ESX-Server, der ja sein eigenes Betriebssystem ist, wesentlich besser. Dann ist ein weiterer Vorteil der Virtualisierung (am extremsten natürlich beim ESX) ja, daß Ressourcen, die eine Maschine nicht benötigt, anderen Maschinen zugeteilt werden können. Beispiel ist hier der DC, der morgens zwischen 7 und 9 Uhr die Anmeldungen abfackelt und ansonsten den ganzen Tag mehr oder weniger in der Nase bohrt... Dessen Ressourcen könnten dann vom VMWare auf den auf dem gleichen Hostsystem liegenden Datenbankserver geschoben werden. Bei Terminalservern ist es ja aber nun mal so, daß ich als Admin schon versuche, daß alle so ziemlich die gleiche Auslastung haben. Im Besten Falle realisiere ich hier Load-Balancing oder ähnlich geartete Dinge, damit sich keiner der WTS in der Nase bohrt, während der Kollege nebenan schwer schuftet... Auf einer virtuellen Umgebung macht das nicht allzu viel Sinn... jedenfalls nicht von der Performance her. Waren nur so ein paar Gedanken von mir dazu ... ;) Grüsse schroeder750

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 äää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

Hy Burly, danke fürs Feedback !!! Feiner Zug von Dir, sowas freut den Schreiber doch !! :D Grüsse schroeder750

Hy Maik, ... nicht die ganzen Connectoren entfernen, sondern nur die Verbindungsvereinbarung für die öffentlichen Ordner... ;) Habe da bisher keine Probleme gehabt. Die Konfiguration vorher ansehen und merken, dann killen und neu aufbauen... Grüsse schroeder750

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

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...

Sooo, was hammwer noch: Die VM-Testumgebung: ... 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... ... 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: 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

- 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

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 ? :) 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...

Hy Edgar, ... siehste... und deswegen mein bescheidenes leises Anklopfen in diesem Thread... Du kannst mir viel von Termes und Delimeter erzählen, ich stecke in solchenScript- und Programmiersauereien einfach nich drin... is echt nich meine Baustelle :D :D :D ... ich weiß, wann ich mit angeklappten Ohren nur einen Begriff in den Raum werfen und mich schnell wieder verziehen sollte ... ;) Grüsse schroeder750

... aber wenigstens schon beim richtigen Kunden, oder ? Harr harr :D Kannst ja ruhig einen Testuser neu anlegen und dort mal über M einen neuen Unterordner manuell erstellen, wirst sehen, daß es sauber funktioniert. Dabei kann nicht sonderlich viel passieren... Grüsse schroeder750

Moin, ich stecke da nich so drin, aber mir spukten gerade KIX-Scripte ('http://www.kixtart.org') im Kopf rum. Können die sowas eventuell ? Falls nicht, vergesst mein Geschwafel :D Grüsse schroeder750

... dann schmeiß die verwaisten DNS-Einträge per Hand raus... ;) Grüsse schroeder750

... normalerweise, wenn ein Exchange 2000 nackt installiert wird, erzeugt er automatisch ein Laufwerk M:, über das man mittels Explorer wie auf ein normales Dateisystem zugreifen kann. Inhalt dieses Laufwerkes sind Unterordner, in denen sich die öffentlichen Ordner und die Mailboxen wiederfinden. Beim Exchange 2003 wurde das wieder entfernt, weil zuviel Mist damit gebaut wurde... Man spricht hier, wenn ich mich recht erinnere, vom IFS (Installable File System). Ebenso, wie man das beim Exchange 2000 ausblenden kann, kann man es auch beim Exchange 2003 wieder einblenden. geht über registrykeys... Am Besten mal hier reinschauen: http://support.microsoft.com/kb/821836 Wenn das beim Kunden definitiv ein Exchange 2000 und kein 2003er ist, dann wurde das aber von irgendwem manuell nachbearbeitet und so ausgeblendet. Ändere abends irgendwann mal die im Artikel genannten Registryeinträge beim Kundenserver (abends, weil Neustart des Informationsspeicherdienstes erforderlich) und schau es Dir danach mal an. Wirst im Explorer ein Laufwerk M sehen, mein Geschreibsel von oben durchlesen und einen A-Ha-Effekt haben :D Und nochmal: Ganz wichtig: am Laufwerk M: NICHT irgendwie an den Berechtigungen rumbiegen. Da haben sich schon einige Exchange-Admins in den Anfangszeiten des Exchange 2000 alles mit verbogen. Daher wurde es beim Exchange 2003 standardmäßig ausgeblendet. Ich hole es mir aber oft wieder, wenn man da mit Gefühl drangeht, ist das ein feines Tool, die Inhalte der Datenbanken im Filesystem zu haben... Grüsse schroeder750

... kann das jetzt momentan nicht nachvollziehen, habe kein Outlook in meiner Testumgebung zur Hand. Wenn Du das Outlook unter einem administrativen Account startest, der alle Exchange-Berechtigungen hat, kannst Du das nicht ändern ? Aber generell mal: Mal angenommen, Du kannst den Besitzer jetzt ändern auf irgend einen Kollegen. Was hast Du davon ? Diese Verteilergruppen werden, wie Dirk schon sagte, im AD gepflegt, also vom Administrator oder einem entsprechenden Account dort verwaltet. Soll der neue Besitzer (aus Outlook-Sicht) dann neue Mitglieder hinzufügen dürfen ? Grüsse schroeder750

... ich würde abwarten, bis das AD definitiv einmal auf alle DCs durchrepliziert wurde (evtl. nochmal mit "replmon" antriggern) und was dann noch übrig bleibt, manuell löschen... Ich denke aber, aus dem DNS werden die nicht von selbst verschwinden... Grüsse schroeder750

... und wenn Dir das zu umständlich ist, alle Ordner per Hand anzulegen machst Du folgendes: - DOS-Box öffnen und folgenden Befehl absetzen: dir /B M:\domänenname\mbx >C:\mailboxes.txt (Wobei natürlich "domänename" durch den Namen Deiner maildomain ersetzt wird), kannste ja am Laufwerk M: ablesen, wie der Ordner heißt... Als Resultat hast Du eine handliche Textdatei "C:\mailboxes.txt", in der alle Postfächer aufgelistet werden. Die importierst Du jetzt in Excel, schiebst die Liste mit den Postfächern in die zweite Spalte und setzt in die erste Spalte ein "cd" davor. Da reicht es, in der ersten Spalte (Feld A1) ein "cd" reinzuschreiben und danach doppelt auf das Viereck unten rechts vom Feld draufzuklicken. Das wird dann bis runter überall davorgesetzt. Anschließend noch nach jeder dieser nun entstandenen Zeilen zwei neue einfügen, in der ersten steht: "md archivordner" oder wie der Ordner auch heißen soll, den die User bekommen sollen, in der zweiten steht cd .. Kannst Du mit etwas Phantasie auch irgendwie einigermaßen automatisieren... Es entsteht eine Excel-Tabelle mit folgendem Inhalt: cd mueller md archivordner cd .. cd meier md archivordner cd .. cd schroeder md archivordner cd .. usw... Den Krempel jetzt in eine Textdatei exportieren und in *.cmd umbenennen. Wenn Du diese *.cmd nun aus dem Verzeichnis M:\domänenname\mbx rennen lässt, werden automatisch überall die Unterordner erzeugt... ;) Frage ist, was schneller geht, die Dinger per Hand anzulegen oder die Excel-Tabelle zurechtzulöten und das ganze zu exportieren... :rolleyes: Vielleicht bist Du ja auch in VB fit und kannst Dir ein kurzes Script erzeugen, welches Du mit der "mailboxes.txt" füttern kannst... :D Ist vielleicht auch einfacher, die Zeilen md archivordner cd .. erst im Notepad oder so einzufügen, wenn Du die Excel-Geschichte schon exportiert hast... Wie gesagt, am M: - Laufwerk bitte vorsichtig, O.K ? Habe das gerade mal hier in einer Testumgebung angesehen, läuft wunderbar. Auch die Berechtigungen passen, die werden ja von oben auf dem Laufwerk M durchgereicht... Im Outlook sind die Ordner sofort verfügbar... Grüsse schroeder 750

Moin masterschenk, das einzige zentrale, was mir da so einfällt ist das M:-Laufwerk auf dem Exchangeserver. Da kann man ja (naja, nicht ganz automatisiert) in jedem Postfach einen Ordner erstellen bzw. irgendwo ein Ordner-Template erstellen und den mit "Kopieren" in die Zwischenablage legen und dann durch die einzelnen Postfächer durch und jedesmal Rechtsklick => Einfügen. Ich gebe diesen Tip äusserst ungerne, weil man am Laufwerk M: eigentlich nicht auf Dateiebene rumfummeln sollte... Vielleicht mal einen Testaccount samt Postfach erstellen und das da erstmal ausgiebig testen ... Bitte vorsichtig, O.K ? Wenns schiefgeht war der Tip NICHT von mir :D :D :D Grüsse schroeder750

... seht mich jetzt ja nicht als Erbsenzähler an :D :D :D das fiel mir nur auf ... ;) Grüsse schroeder750