Office 365 .pst Import erstellt keine Unterordner
Hallo zusammen,
mit diesem Thema kämpfe ich bereits eine Weile, aber vielleicht hat hier ja jemand eine Idee.
Folgendes Szenario:
Kundenmigration von on premise Exchange (2010 u. 2013, jeweils alle Updates vorhanden) zu Office 365. Emails werden entweder über die Exchangeshell in .psts exportiert, oder händisch aus dem Outlook - macht keinen Unterschied.
Nun werden die Daten mittels AzCopy in die Cloud geladen und mithilfe einer .csv dem jeweiligen User zugeordnet, folgend ein Beispiel der Zuordnungsdatei:
Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl
Exchange,,annb.pst,annb@contoso.onmicrosoft.com,FALSE,/,,,,
Dies ist die Angabe von Microsoft direkt, ich tausche natürlich entsprechende Namen etc. aus. Einzige Anpassung meiner Seite: Ich verwende anstatt der Emailadresse für die Zuordnung die eindeutige GUID des Users... um etwaige Doppelgänger auszuschließen.
Nun zu meinem Problem.
Lasse ich die .csv so durchlaufen erstellt er mir unter "Posteingang" keine Unterordner. Vergleicht man die Größen der Postfächer sind diese Identisch, die Emails an sich werden also Importiert. Nun spuckt die Zuordnungsroutine ein Ergebnis aus zum Beispiel: "3000/3000 Emails Importiert, 20/30 Ordnern importiert".
Diese fehlenden 10 Ordner sind auch jene die Fehlen. (Ich hatte auch schon Importergebnisse die ohne meckern abgeschlossen wurden, bin also weiterhin verwirrt)
Wie ich mir bisher geholfen habe:
Lässt man bei "TargetRootFolder" den / weg erstellt er mir einen neuen Ordner Namens "imported" - HIER sind dann auch alle Unterordner zu finden.
Dann ziehe ich diese mit Müh und Not an Ihre richtige Stelle... ich fürchte mich aber vor dem Tag wenn ein größerer Kunde einen Umzug plant...
Postfächer sind zwischen 2GB und 20GB groß, macht auch keinen Unterschied.
Hat jemand eine Idee? Ich bin bereit fürs Brainstorming.
Freundliche Grüße
mit diesem Thema kämpfe ich bereits eine Weile, aber vielleicht hat hier ja jemand eine Idee.
Folgendes Szenario:
Kundenmigration von on premise Exchange (2010 u. 2013, jeweils alle Updates vorhanden) zu Office 365. Emails werden entweder über die Exchangeshell in .psts exportiert, oder händisch aus dem Outlook - macht keinen Unterschied.
Nun werden die Daten mittels AzCopy in die Cloud geladen und mithilfe einer .csv dem jeweiligen User zugeordnet, folgend ein Beispiel der Zuordnungsdatei:
Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl
Exchange,,annb.pst,annb@contoso.onmicrosoft.com,FALSE,/,,,,
Dies ist die Angabe von Microsoft direkt, ich tausche natürlich entsprechende Namen etc. aus. Einzige Anpassung meiner Seite: Ich verwende anstatt der Emailadresse für die Zuordnung die eindeutige GUID des Users... um etwaige Doppelgänger auszuschließen.
Nun zu meinem Problem.
Lasse ich die .csv so durchlaufen erstellt er mir unter "Posteingang" keine Unterordner. Vergleicht man die Größen der Postfächer sind diese Identisch, die Emails an sich werden also Importiert. Nun spuckt die Zuordnungsroutine ein Ergebnis aus zum Beispiel: "3000/3000 Emails Importiert, 20/30 Ordnern importiert".
Diese fehlenden 10 Ordner sind auch jene die Fehlen. (Ich hatte auch schon Importergebnisse die ohne meckern abgeschlossen wurden, bin also weiterhin verwirrt)
Wie ich mir bisher geholfen habe:
Lässt man bei "TargetRootFolder" den / weg erstellt er mir einen neuen Ordner Namens "imported" - HIER sind dann auch alle Unterordner zu finden.
Dann ziehe ich diese mit Müh und Not an Ihre richtige Stelle... ich fürchte mich aber vor dem Tag wenn ein größerer Kunde einen Umzug plant...
Postfächer sind zwischen 2GB und 20GB groß, macht auch keinen Unterschied.
Hat jemand eine Idee? Ich bin bereit fürs Brainstorming.
Freundliche Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 390354
Url: https://administrator.de/contentid/390354
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
5 Kommentare
Neuester Kommentar
Moin,
ich müsste das mittels AzCopy einmal nachstellen, allerdings frage ich mich, warum Du für eine OnPrem -> Office365 Migration nicht den Office365 Migrationsbatch verwendest. Darüber werden automatisch sämtliche (gewählten) Postfächer inkl. sämtlicher Objekte (und Ordnerstrukturen) vom onprem Exchange zu Exchange Online synchronisiert. Darüber hinaus kann man, solange man den MX noch nicht umgestellt hat und den lokalen Exchange noch betreiben möchte, permanent synchronisieren um kein Delta zu erhalten, ähnlich wie bei einer Hybridlösung.
Die Vorarbeiten für diesen Migrationsprozess (ggf. Autodiscover anpassen und Zertifikatserstellung damit Exchange Online Zugriff auf den onprem Server erhält) sind eigentlich überschaubar.
Gruß Malte
ich müsste das mittels AzCopy einmal nachstellen, allerdings frage ich mich, warum Du für eine OnPrem -> Office365 Migration nicht den Office365 Migrationsbatch verwendest. Darüber werden automatisch sämtliche (gewählten) Postfächer inkl. sämtlicher Objekte (und Ordnerstrukturen) vom onprem Exchange zu Exchange Online synchronisiert. Darüber hinaus kann man, solange man den MX noch nicht umgestellt hat und den lokalen Exchange noch betreiben möchte, permanent synchronisieren um kein Delta zu erhalten, ähnlich wie bei einer Hybridlösung.
Die Vorarbeiten für diesen Migrationsprozess (ggf. Autodiscover anpassen und Zertifikatserstellung damit Exchange Online Zugriff auf den onprem Server erhält) sind eigentlich überschaubar.
Gruß Malte
Welchen Vorteil sieht Dein Chef in eurer Variante? Ich sehe in eurem Vorgehen mehr Aufwand und potentielle Fehlerquellen (siehe eben auch das Erzeugen der Ordnerstruktur) und das Rumfrickeln an einer CSV Datei. Das würde man sich bei der "Best Practice Variante" alles sparen... Insofern kannst Du ja mal kritisch hinterfragen... ;)
Die Frage ist, wenn ich einen Weg von A nach B vor mir habe und zur Auswahl einen Kleinwagen oder einen komfortablen Sportwagen habe, warum ich dann den Kleinwagen nehme und noch dazu nicht direkt von A nach B fahre sondern noch einen Umweg über C und D in Kauf nehme.. ;)
Zu Deinem konkreten Problem könnte man auch den Microsoft Support noch konsultieren, der ist i.d.R. auch ganz gut und darf sich mit seinen eigenen Produkten und Lösungen ja auch gern mal beschäftigen...
Zu Deinem konkreten Problem könnte man auch den Microsoft Support noch konsultieren, der ist i.d.R. auch ganz gut und darf sich mit seinen eigenen Produkten und Lösungen ja auch gern mal beschäftigen...