FileShare Migration nach O365

9. Türchen

Nachdem wir gestern mit ein paar Tricks unseren FileShare vorbereitet haben oder zumindest die Daten sortiert haben, die wir migrieren möchten, steht heute die wirkliche Migration ins Haus. Wir wollen dabei nicht kleckern, sondern klotzen. Damit meine ich nicht, dass wir nicht lange warten wollen, um per CSOM langsam Daten hochzuladen oder eine Festplatte verschicken wollen, wofür es auch einige Limitationen gibt. Stattdessen wollen wir die – mittlerweile nicht mehr – neue High Speed Migration (HSM) API nutzen und Daten direkt über einen Azure Storage in eine SharePoint Online Bibliothek migrieren.

Dazu müssen wir aber folgendes beachten:

• Die Pfadlängen im Ziel dürfen 255 Zeichen nicht überschreiten. Dies ist eine SharePoint Limitation, die wir im FileShare nicht kennen. Achtet daher darauf, dass eure Ordnerstruktur nicht zu tief ist, um dieses Limit nicht zu erreichen.
• Sonderzeichen wie “ ? < > # % / \ werden in SharePoint nicht unterstützt
• Dateien aus dem FileShare, die gerade von einem anderen Programm verwendet werden, sind gesperrt und daher auch nicht für den Migrationsprozess zugänglich.

Um nun loslegen zu können, müssen wir (neben dem Ziel-Tenant und einer Quellumgebung mit Daten) noch folgenden Dinge vorbereiten:

1. Azure Verbindungs-Assistent
2. Online PowerShell Module – Beides aus dem O365Adventskalender Türchen 6
3. Azure Storage (Erstellung siehe unten)

Ok, dann starten wir nun in sechs Schritten.

1. Azure Storage erstellen

Diesen Storage brauchen wir, um das Migrationspaket in der Microsoft Cloud ablegen zu können. Ein komplett direktes Befeuern unseres SharePoints ist nämlich leider doch nicht möglich. Als Hinweis, der Storage muss aber nicht unter dem gleichen Tenant aufgehängt werden. Der Storage kann ganz woanders liegen – und auch unter einem anderen Konto laufen – als der Ziel SharePoint-Tenant. In unserem Test Tenant können wir uns auch einen Test Storage einfach konfigurieren.

1. Im Azure Portal zu Speicher navigieren und ein neues Speicherkonto anlegen
   
   
2. Anschließend werden wir gebeten, die Art des Speichers auszuwählen – in unserem Falle ein Testkonto – und unsere Identität per Telefonnummer und Kreditkarte zu überprüfen. Keine Sorge, es fallen wirklich keine Gebühren an, wenn man nicht explizit einem kostenpflichtigen Abo zustimmt.
    
3. Nun vergeben wir unserem Speicher einen Namen, der nur Kleinbuchstaben und Ziffern enthalten darf. Als Storage Replikation empfehle ich den Lokal Redundanten Speicher (LRS), da dieser einfach der günstigste Storage ist für 2,02 je 100 GB (aktuell) und für unsere (Test-) Migration völlig ausreichend ist. Die Ressourcengruppe, in der wir unseren Storage einordnen, muss auch noch einen Namen bekommen und die Region, die wir auswählen, sollte aus persönlicher Empfehlung immer nahe zu unserem Upload-Ort sein, denn die Verbindung der Speicher und Tenant untereinander ist von Microsoft extrem gut verkabelt. Also von welcher Azure Storage Region wir die Daten in SharePoint pumpen hat kaum einen Einfluss, aber natürlich unsere eigene Upload-Leitung zu einer entsprechenden Azure Storage Location schon.
   Die Bereitstellung des Speichers dauert nur wenige Sekunden bis Minuten. Danach finden wir unseren Storage Namen sowie den Storagy Key unter der Kategorie Zugriffsschlüssel. (für manche Prozesse ist auch die Application ID nötig, aber nicht für unsere Migration.)
   
   

 

2. Verbindungsaufbau zu O365

Zur Erinnerung, bevor wir mit PowerShell loslegen können, müssen wir zunächst der Verbindungsaufbau zu O365 aufbauen und die Module in der Azure PowerShell Konsole laden, die ihr als Administrator geöffnet habt:

• $Creds = Get-Credentials
• Import-Module Microsoft.Online.SharePoint.PowerShell -ErrorAction SilentlyContinue
• Connect-SPOService -Credential $Creds -Url https://yourdomain-admin.sharepoint.com

3. Paket erstellen 

Nun haben wir alle Vorbereitungen getroffen, also erstellen wir uns nun ein Migrationspaket. Dabei geben wir mit, welche Dateien von dem FileShare inkludiert werden sollen. Daher ist die gestrige Vorbereitung so hilfreich gewesen. Ich habe versucht, in der Eingabeaufforderung die Variablen so eindeutig wie möglich zu formulieren, daher kommentiere ich es nicht weiter aus. Wenn ihr Fragen habt, einfach fragen! 🙂

Einen Hinweis noch: die Zielpfade müssen schon existieren, da im Konvertierungsprozess bereits eine Verbindung zum Ziel aufgebaut wird, um entsprechend die Daten zu mappen. Die PowerShell Befehle verwenden zudem die internen SharePoint-Namen. Also in Office 365 ist die „Documents“ Bibliothek intern immer noch die „Shared Documents“ MIT Leerzeichen, aber ohne „%20“. Darauf müsst ihr achten.

• $QuellPfad =   „\\Server\C`$\FileShare\O365Migration“
• $QuellPaketPfad = „\\Server\C`$\FileShare\O365Migration\Paket“
• $ZielPaketPfad = „\\Server\C`$\FileShare\O365Migration\Paket-Output“
• $Zielweburl = „https://yourdomain.sharepoint.com/sites/yoursite“
• $Zielbibliothek = „FileShare“
• $ZielOrdner = „OnlineMigration“ (optoinal)

 

• New-SPOMigrationPackage -SourceFilesPath $QuellPfad -OutputPackagePath $QuellPaketpfad -TargetWebUrl $Zielweburl -TargetDocumentLibraryPath $Zielbibliothek -TargetDocumentLibrarySubFolderPath $ZielOrdner –NoAzureADLookup

 

4. Paket konvertieren

Nachdem wir das Paket erstellt haben, müssen wir es in ein von SharePoint Online verständliches Format konvertieren. Dafür nutzen wir den ConvertTo-SPOMigrationTargetedPackage Befehl. Mit diesem Verbinden wir uns auch schon auf die zukünftige SharePoint Online Bibliothek, damit schon die Mappings auf die Zielbibliothek und Ordner vorgenommen werden können. Und ich kann sogar noch mehr mappen – nämlich Benutzer! Denn On-Premises Benutzer haben nicht immer genau die gleiche ID in O365. Ist das der Fall, macht also ein Mapping Sinn. Dazu müssen wir den -NoAzureADLookup Switch weg lassen, aber ersetzen ihn durch den -UserMappingFile Switch. Damit können wir eine CSV Datei referenzieren, in der für jeden Nutzer eine OnPremSID, UPN sowie eine Wahr/Falsch Angabe zur Gruppenzugehörigkeit angegeben wird. Was diese genau aussagen, seht ihr in der Tabelle:

OnPremSID	UPN	isGroup
Die Active Directory-SID des lokalen Benutzers oder der lokalen Gruppe (Windows/AD-Authentifizierung an der Quelle vorausgesetzt), die für den Nachschlag des Eintrags in der Datei UserGroup.XML verwendet wird.	Der UPN (z. B. E-Mail-Adresse) des Kontos, der im Ziel verwendet werden soll.	Handelt es sich bei dem Konto um eine Benutzer- oder Domänengruppe? (Gebt TRUE oder FALSE ein)

So eine CSV muss schon vor der Migration für alle Benutzer erzeugt worden sein, die vermutlich im Migrationspaket enthalten sein werden. Solltet ihr jedoch kein User Mapping brauchen, dann reicht nun also zum Konvertieren dieser Befehl:

• ConvertTo-SPOMigrationTargetedPackage -SourceFilesPath $QuellPfad -SourcePackagePath $QuellPaketPfad -OutputPackagePath $ZielPaketPfad -TargetWebUrl $Zielweburl -TargetDocumentLibraryPath $Zielbibliothek -TargetDocumentLibrarySubFolderPath $ZielOrdner -Credentials $Creds

 

5. Hochladen

Nun laden wir das neue Paket, das im Ordner kaum anders aussieht, als das erste Pakte, auf unseren Azure Storage hoch. Die entsprechenden Namen für unsere Pakete und Container dürfen übrigens auch nur Kleinbuchstaben und keine Sonderzeichen enthalten. Der Payload stellt dann die eigentlichen Daten dar und der PaketContainer das Manifest und Einstellungen für die Migration. Zusätzlich brauchen wir in diesem Schritt das Speicherkonto und den Schlüssel.

• $PayloadContainer = „migrationayload“
• $PaketContainer = „paketcontainer“
• $AzureWarteschleife = „fileshareupload“
• $AzureKontoName = „robtheninja“
• $AzureStorageKey =“hierdeinazurekey==“

 

• $Upload = Set-SPOMigrationPackageAzureSource –SourceFilesPath $QuellPfad –SourcepackagePath $ZielPaketPfad –FileContainerName $PayloadContainer –PackageContainerName $PaketContainer –AzureQueueName $AzureWarteschleife –AccountName $AzureKontoName -AccountKey $AzureStorageKey

Wer möchte, und wem der „Ladebalken“ in der PowerShell Konsole zu langweilig ist, der kann diesen Vorgang mit einem Explorer-Fenster verfolgen. Dazu gibt es auf Codeplex einen sogenannte Azure Storage Explorer, in dem das Ganze dann folgendermaßen aussieht.

Dieser Explorer ist auch sonst noch sehr nützlich, wenn man seinen Speicher auch noch für anderen Dinge verwendet, als nur zum Migrationsupload. Also schaut ihn euch wirklich einmal an.

 

6. Migration Starten

Das sieht ja nun schon mal gar nicht schlecht aus. Also müssen wir jetzt nur noch die Migration starten. Dies geht mit folgendem Befehl:

Submit-SPOMigrationJob –TargetwebUrl $Zielweburl –MigrationPackageAzureLocations $Upload –Credentials $Creds

Auch hier können wir mit dem Azure Storage Explorer den Migrationsfortschritt beobachten und schauen, welche Events in der Warteschleife hinzukommen.

Optional können wir auch:

1. den Status der Migration direkt in der Konsole abfragen mit
   Get-SPOMigrationJobStatus -TargetWebUrl https://yourdomain.sharepoint.com/sites/site
2. den Migrationsjob am Ende der Migration löschen mit
   Remove-SPOMigrationJob -JobId GUID -TargetWebUrl https://yourdomain.sharepoint.com/sites/site
   Weitere Informationen zum Remove-SPOMigrationJob gibt es hier: https://technet.microsoft.com/en-us/library/mt143607.aspx

Mit diesen beiden Befehlen könnt ihr also direkt den Status abfragen und sicher den Prozess beenden. Mit dem Azure Storage Explorer seht ihr es auch, wenn in der Warteschleife (hier: Queue „fileshareupload“) ein Event „End“ auftaucht. Danach wird auch eine Log-Datei zum abgeschlossenen Migrationsjob in den Payload-Ordner (hier: „migrationpayload“) gelegt.

Im Ziel kommt dann in der Tat alles so an, wie es auf dem FileShare war, sogar mit Ordnerstruktur und den originalen Metadaten, wie Ersteller oder Erstellungsdatum (siehe Screenshot).

Sicherlich ist eine Migration mit Hilfe des Microsoft FastTrack noch einfacher, auch wenn selbst dies keine „White Gloves“ Migration ist. Und generell sind 82% aller Migrationen keine einfachen Migrationen. Aber für kleine Firmen und einfache FileShares ist dieser Ansatz mit der HSM API kein komplizierter. Ich kann nur empfehlen, einfach mal ausprobieren, mir hat es wirklich Spaß gemacht, wie schnell und einfach hier alles funktionierte. Ich drücke die Daumen, dass dies auch bei euch der Fall ist.

Weitere Informationen zum Datendurchsatz und möglicher Drosselung der API erfahrt ihr hier:
https://support.office.com/de-de/article/Migrationsgeschwindigkeit-von-SharePoint-Online-und-OneDrive-for-Business-21cfb6a0-fa4c-44c6-9a39-0f45e85e371f?ui=de-DE&rs=de-DE&ad=DE&fromAR=1

Sollte euch das dennoch zu stressig sein oder ihr habt einfach nicht die Zeit und Ressourcen, so ein Projekt durchzuführen, dann gibt es auch sehr gute 3rd Party Lösungen am Markt, die ebenfalls die HSM API nutzen, aber auch direkt ohne Storage mit Multi-Threading die Daten hochladen können – und das Ganze nicht nur von FileShares, sondern auch Notes, LiveLink, Documentum, etc. Immer optimistisch denken, für jedes Problem, gibt es eine Lösung. 🙂

Happy „SharePointing“!

Zur O365Adventskalender Übersicht