Exchange 2003 Daten zu Exchange 2007 ohne SBS Migration

[samke 10]

Hallo,

 

wir haben hier einen SBS2003 mit Exchange 2003.

Nun haben wir neu einen SBS2008 mit Exchange 2007. Aus mehreren Gründen haben wir uns entschloßen nicht von SBS 2003 auf SBS 2007 zu migrieren.

 

Jetzt ist aber die Frage bzgl. Exchange. Wie geht man hier am Besten vor? Wir haben ca. 15 User. Der "Spitzenreiter" hat 16GB an Daten, dann kommen ca. 5 User mit ca. 4-6 GB Exchange Daten. Der Rest hat bis max. 2GB.

 

Wie kann man die Daten am Besten übernehmen?

Wir dachten jetzt zu erst an Export als PST aus Outlook und dann Import ins Exchange 2007 per Outlook. Da gibts aber doch Probleme mit der Dateigröße oder? Ich meine gelesen zu haben, das PST Dateien nur bis 2 oder 4 GB gehen? Da hätten wir ja viel "Spaß" beim 16GB User.

 

Gibt es eine andere Möglichkeit?

 

Danke u. Gruß

[GuentherH 61]

Hallo.

 

Postfächer bis 2 GB Größe kannst du mit Exmerge exportieren. Den Rest musst du mit Outlook erledigen. Und keine Angst, Outlook kann das schon, du solltest dir nur genügend Verpflegung an den Arbeitsplatz mitnehmen;)

 

LG Günther

[dmetzger 10]

Das hier als Ergänzung. Einer der Gründe, weshalb wir lieber innerhalb der gleichen Gesamtstruktur/Exchange Organisation migrieren als mit Exmerge exportieren. Aber es muss manchmal halt sein.

 

Cannot Reply To Old Emails Or Modify Old Calendar Items After PST Mail Migration - The Official SBS Blog - Site Home - TechNet Blogs

[samke 10]

Danke euch, das hat mir schon gut geholfen! Dann geht's jetzt mal los :-).

 

Schönes We euch!

Gruß

[Krombi666 10]

16GB.....:confused:

 

kann man ja bald nen eigenen Exchange-Server für bereitstellen.....

 

Denke auch das der Export per Outlook zwar zeitaufwändig ist, aber das haut in jedem fall hin.

[dmetzger 10]

16GB.....:confused:

 

kann man ja bald nen eigenen Exchange-Server für bereitstellen.....

 

Eine Migration oder Aktualisierung der Exchange-Organisation ist stets ein guter Zeitpunkt, die Nutzer zum Aufräumen ihrer Postfächer aufzufordern.

 

Zum anderen sollte die Grösse von Postfächern durchgehend beschränkt sein. Postfächer sind keine Archive.

 

Je nachdem könnte man diesen Nutzer, wenn er sich wiederspenstig zeigt weil Chef, auf dem Exchange Server 2007 in eine eigene Speichergruppe/Datenbank stecken, damit nicht die anderen mitleiden müssen, falls sein Postfach je wiederhergestellt werden muss. :D

[NorbertFe 1.799]

Eine Migration oder Aktualisierung der Exchange-Organisation ist stets ein guter Zeitpunkt, die Nutzer zum Aufräumen ihrer Postfächer aufzufordern.

 

Ja, aber ein für Nutzer schwer nachvollziehbares Argument, warum ein neues System denn auf einmal größenbeschränkte Postfächer hat. ;)

 

Zum anderen sollte die Grösse von Postfächern durchgehend beschränkt sein. Postfächer sind keine Archive.

 

Das sieht MS inzwischen wohl anders. ;)

 

Bye

Norbert

[dmetzger 10]

[

Ja, aber ein für Nutzer schwer nachvollziehbares Argument, warum ein neues System denn auf einmal größenbeschränkte Postfächer hat. ;)

 

Da muss man sich durchsetzen - 2 GB sind reichlich genug. :D

 

Das sieht MS inzwischen wohl anders. ;)

 

Man darf auch anderer Meinung sein als MS :wink2:

 

Seit E2K10 SP1 können die Archiv-Postfächer wenigstens in eigenen Datenbanken beherbergt sein. Das ermöglicht Sicherungszeitpläne unabhängig von denjenigen der produktiven Postfächer. Sicherungen sind aufwändiger, wenn Nutzer ihre produktiven Postfächer zu riesigen Archiven umfunktionieren.

[NorbertFe 1.799]

[

 

Da muss man sich durchsetzen - 2 GB sind reichlich genug. :D

 

Welchen Grund, aus Sicht des Nutzers, sollte diese 2GB Grenze denn haben? ;)

 

Man darf auch anderer Meinung sein als MS :wink2:

 

Da bin ich bei dir.

 

Seit E2K10 SP1 können die Archiv-Postfächer wenigstens in eigenen Datenbanken beherbergt sein. Das ermöglicht Sicherungszeitpläne unabhängig von denjenigen der produktiven Postfächer. Sicherungen sind aufwändiger, wenn Nutzer ihre produktiven Postfächer zu riesigen Archiven umfunktionieren.

 

Jupp und? dann kauft der Kunde halt mehr Platten mehr Backup mehr Mehr. Wo ist das Problem? ;) Wer große Postfächer hat, muß eben investieren.

 

Bye

Norbert

[dmetzger 10]

Welchen Grund, aus Sicht des Nutzers, sollte diese 2GB Grenze denn haben? ;)

 

Ich schaue das weniger aus der Sicht des Nutzers an als aus der Sicht des Dienstleisters mit SLAs, die beispielsweise die Wiederherstellungszeit von Datenbanken und Postfächern auch in Umgebungen vor Exchange Server 2010 (DAG) regeln. Wir haben zahlreiche Kunden mit 10'000+ Postfächern (und ich untertreibe, um mich nicht dem Vorwurf des Übertreibens auszusetzen).

 

Ich finde nachstehendes Papier zu diesem Thema interessant:

 

You Had Me At EHLO... : Thinking about Mailbox and Message Size Limits

 

Dann gibt es andere Aspekte auf Client-Seite (nicht ausschliesslich theoretisch, haben wir bei Kunden schon beheben müssen, wobei diese Kunden heute Postfächer ebenfalls durchgehend auf 2 GB beschränken):

 

You may experience performance problems when you are working with items in a large .pst file or in a large .ost file in Outlook 2007

Email Archiving and Mailbox Size - Best Practice Recommendations Under Microsoft's Exchange Server

 

Da wir dabei sind, das hilft vielleicht ebenfalls bei Entscheidungen, ob und wie die Grösse von Postfächern beschränkt werden soll:

 

You Had Me At EHLO... : Exchange 2010 Mailbox Server Role Requirements Calculator

 

Ich stimme zu, dass im kleineren Umfeld ein oder mehrere Postfächer mit 16 GB kein Problem darstellen oder darstellen sollten. Im Enterprise-Umfeld möchten wir möglichst viele Parameter unter Kontrolle haben, weils unser Leben leichter macht (SLAs, SLAs, SLAs) und wir besser planen können. Die Nutzer haben in den meisten Fällen auf die eine und andere Art ebenfalls einen Nutzen davon, deshalb heissen sie ja auch Nutzer :D

 

Ich frage mal zwei oder drei MCM Exchange Server nach ihren Meinungen und Erfahrungen. Das Thema ist grundsätzlich interessant. Ob und wie Postfachgrössen festgelegt werden sollen, hängt von verschiedenen Faktoren ab (Grösse des Unternehmens, Architektur, Unternehmensrichtlinien, interne und externe SLAs, Budget, ggf. juristische Argumente, mobile Nutzer etc. etc.) So kann unser Vorgehen und unsere Handhabung nur eine von vielen sein.

Selbstverständlich