Schlagwort-Archive: Online Migration

Exchange Migration nach Office 365

20. Türchen

In den letzten Tagen haben wir uns all die coolen Funktionen rund um SharePoint Online angeschaut. Aber eine wirkliche Zusammenarbeit startet natürlich nur dann, wenn wir auch mehrere Kollegen in Office 365 haben. Diese könnte man natürlich alle manuell „from scratch“ im Admin Portal anlegen. Was ist aber mit den bereits bestehenden Email-Konten und den Daten darin? Richtig, das wollen wir natürlich nicht verlieren, also machen wir uns heute an eine Migration bestehender Email-Konten nach Exchange Online.

Microsoft unterstützt – neben dem FastTrack Service vom 4. O365Adventskalender Türchen – natürlich auch nativ verschiedene Email-Quellen, die wir dann nach Office 365 schaufeln können. Dies sind aktuell:

  • Gmail
  • Exchange On-Premises
  • Yahoo
  • PST-Datei Import
  • „Weitere Quellen“

Exchange Online Migrationsmöglichkeiten

Wie ihr am Screenshot schon seht, werden wir uns auch gleich den vor kurzem neu eingeführte Migrationsdialog anschauen. Denn bis vor wenigen Tagen gab es nur die Exchange Migration und die Anbindung über einen IMAP Server, was wir unter „Other email sources“ finden. Es sind also ein paar Optionen hinzugekommen. Für alle Möglichkeiten gilt aber, dass ihr einen entsprechenden Exchange Plan in O365 abonniert habt bzw. den O365 Nutzern bereits eine Exchange Lizenz zugewiesen habt. Andernfalls können all diese Migrationsszenarien nicht durchgeführt werden.

Exchange On-Premises:

Als erstes schauen wir uns die Exchange On-Premises zu O365 Migrationsstrategien an. Dafür bauen wir im Prinzip eine hybride Umgebung auf, um die On-Premises Email-Konten mit Exchange Online zu synchronisieren. Dafür hat Microsoft nun extra ein „Office 365 Hybrid Configuration“ Tool eingeführt, dass für uns das hybride Setup deutlich vereinfacht. Das Tool kann direkt heruntergeladen werden, wenn ihr im O365 Admin Center -> Users -> Data migration auf Exchange klickt.

Office 365 Exchange Migration

Das Tool unterstützt das Aufsetzen einer hybriden Exchange Umgebung für die Versionen ab 2010. Damit wird dann im ersten Schritt ein lokaler Exchange Server gesucht oder man gibt selbst den On-Premises Exchange an. Außerdem kann man auswählen, in welcher O365 Region man einen Tenant hat. Schön ist zu sehen, dass man bereits Deutschland als dedizierten Standardort auswählen kann, auch wenn aktuell das Release für Office 365 in der deutschen Cloud erst für Q1-2017 angekündigt ist.

O365 Exchange hybrid Migration

Im nächsten Schritt muss man seine Zugangsdaten für den On-Premises Server sowie für den O365 Tenant angeben. Es wird dann eine Verbindung aufgebaut und geprüft, ob das angegebene Konto über die nötigen rechte verfügt. Sind wir da durch, können wir uns für eine Migrations-Strategie entscheiden:

Full Hybrid
(früher Remote Move Migration)
Minimal Hybrid
(früher Staged Migration)
Express Migration
(früher Cutover Migration)
Unterstützte Exchange Version Ab 2010
  • Ab 2007 (manuell konfiguriert)
  • Ab 2010 mit dem Konfigurations-Tool
  • Ab 2007 (manuell konfiguriert)
  • Ab 2010 mit dem Konfigurations-Tool
Nutzerverwaltung On-Premises Cloud Cloud
Anzahl der Nutzerkonten Empfohlen für mehr als 2.000 Keine Einschränkung Empfohlen für weniger als 2.000
Geplanter Migrationszeitraum Dauerhafte Koexistenz von On-Premises und Online bzw. sehr langer Zeithorizont Wenige Wochen bis Monate Weniger als eine Woche
Komplexität hoch mittel gering
Hinweis
  • Kein Cross-premises Free/Busy möglich
  • Kein TLS geschützer Mailverkehr zwischen On-Prem und Online
  • Kein Cross-premises eDiscovery
  • Kein Outlook im Web und ActiveSync Weiterleitung
  • Keine automatische Aufbewahrung/Löschung von archivierten Postfächern
On-Premises wird nach der Migration abgeschaltet. Dies ist also eine Komplettmigration ohne ein wirklich lebendes Hybrid-Szenario.
Weitere Informationen und Anleitungen Full Hybrid Minimal Hybrid

Am Ende des Wizard haben wir die Möglichkeit eine Einmal-Synchronisation durchzuführen. Dies ist empfohlen, weil wir damit direkt als Tenant-Administrator eine Verbindung zum Azure Active Directory herstellen. So können die Nutzer und Gruppen aus Exchange On-Premises ausgelesen und im Azure AD erzeugt werden. Anschließend sehen wir diese Nutzerkonten in unserem O365 Admin Center und müssen nur noch alle oder bestimmte Nutzer auswählen, deren Postfach migriert werden soll. Dies ist beispielsweise ein Vorteil gegenüber der früheren „Staged Migration“, bei der man für das Mapping noch eine CSV-Datei erstellen musste.

O365 Exchange hybrid Migration User Mapping

Zusammengefasst werden bei dieser Migration die Nutzerkonten von Exchange On-Premises mit dem Hybrid Configuration Tool zu Exchange online synchronisiert und anschließend startet der Datentransfer der Postfächer. Ob man dann hybrid weiter fährt, ob minimal hybrid mit entsprechenden Einschränkungen oder sogar den On-Presmies Server komplett abschaltet ist eure Entscheidung.

IMAP:

Die IMAP Konfiguration war bis vor kurzem noch die zweite und letzte mögliche Option, bei der man eine Verbindung zu einem beliebigen Email-Dienst über IMAP herstellen kann. Daher heißt dieser Ansatz auch mittlerweile einfach „Other email sources“. Mit dieser Möglichkeit könnte man sogar seine Email von privaten Konten von beispielsweise 1und1 oder GMX in seinen O365 Tenant migrieren. Der jeweilige Email-Dienstanbieter sollte die nötigen Informationen aus dem Screenshot standardmäßig zur Verfügung stellen, sodass ihr die Verbindung schnell konfigurieren könnt.

O365 Exchange IMAP Migration

Wenn dies geschehen ist, dann könnt ihr die Mappings zu existierenden Nutzern in O365 vornehmen. Ihr seht im Screenshot, dass ich so also eine Verbindung zu meinem Homepage-Provider hergestellt habe und nun die dortigen Konto referenzieren kann.

O365 Exchange IMAP Migration User Mapping

Aber Achtung: verlasst ihr dieses Menü, dann sind die vorherigen Einstellung zur IMAP-Verbindung auch wieder weg. Bei diesem Migrationsansatz müsstet ihr also immer wieder die Konfiguration vornehmen, wenn ihr nicht alles auf einmal starten möchtet. Auch wenn es nicht super aufwendig ist, so ist es doch unschön.

Yahoo, Gmail, Outlook, Hotmail:

Schöner hat es Microsoft stattdessen mit den bekanntesten Email-Diensten gelöst. Dort ist diese einfache IMAP-Verbindungskonfiguration bereits vorgenommen worden, sodass ihr direkt mit dem Benutzerkonto-Mapping sowie Migration starten könnt. Der Screenshot ist also sehr ähnlich, wie zur obigen manuellen IMAP Konfiguration.

O365 Exchange Google Migration User Mapping

Bei Google, Outlook und Hotmail müssen zuvor noch ein paar wenige Konfiguration vorgenommen werden, damit eine Verbindung aufgebaut werden kann. Diese sind aber sehr übersichtlich mit Screenshots hinter dem entsprechenden Link erklärt (siehe erster Screenshot oben).

Natürlich wäre es sehr aufwendig, jeden einzelnen User zu mappen, daher empfehle ich die Verwendung einer CSV-Datei, um dies einfacher in Excel zu erledigen und dann automatisiert in O365 zu übertragen. Dieser Ansatz kann für Yahoo, Google, Outlook und Hotmail verwendet werden, aber auch für die manuelle IMAP Anbindung. Wie so eine CSV-Datei auszusehen hat, findet ihr hier: https://technet.microsoft.com/de-de/library/jj200730(v=exchg.150).aspx

Habt ihr so eine Datei erstellt und wollt nun loslegen, dann könnt ihr das aktuell noch nicht im O365 Admin Center. Stattdessen geht ihr direkt in das Exchange Admin Center und gelangt über Empfänger und Migration zum entsprechenden Dialog (siehe folgender Screenshot), der (aktuell) noch auf dem alten User Interface basiert. Alle weiteren Schritte der IMAP Migration mit PST-Datei werden dann auch von hier verwaltet.

O365 Exchange PST-file Migration

Ganz harmonisch ist dies noch nicht, weil die Ansichten zum O365 Admin Center unterschiedlich sind und das oben gezeigte Hybrid Konfigurationstool mehr Funktionen anbietet, welche direkt in Exchange nicht (mehr) möglich sind, z.B. die Express Migration. Ich denke aber, dass wir dennoch alle eine IMAP Migration hin bekommen, da sich die Komplexität wirklich in Grenzen hält.

Upload PST:

Als letzten Ansatz schauen wir uns den Upload einer PST-Datei an. Im Prinzip läuft dies eigentlich genau so ab, wie wir bereits im 9. Kalendertürchen zur PowerShell Datenmigration gesehen haben. Hierbei starten wir nun jedoch das ganze mit einem kleinen User Interface über das Admin Center und nutzen nicht nur PowerShell. Im UI wählen wir bei der Datenmigration nun PST Upload aus (Mit dem Upload zu OneDrive gelangen wir zum selben Interface).

O365 Exchange PST-Fil eMigration

Im ersten Schritt sehen wir gleich, egal ob PST-Datei oder Daten für SharePoint/OneDrive, dass wir ein PowerShell Tool benötigen und wir uns Container anlegen lassen können. Dies sind exakt die, welche wir noch am 9.12. per PowerShell selbst definiert haben. Wir brauchen aber nun PowerShell, um eben wieder die Daten in O365-freundliche Formate zu konvertieren.

O365 Exchange PST-File Migration Mapping

Ist dies erledigt, erzeugen wir uns noch eine Azure Warteschleife.

O365 Exchange PST-File Migration azure queue

Im Anschluss müssen wir nun per Azure PowerShell (und SharePoint Online PS-Module, je nach Upload Daten) das Paket konvertieren und im nächsten Schritt über das UI hochladen.

O365 Exchange PST-File Migration Upload

Ist das erledigt, kann es auch schon losgehen. Ich persönlich würde den PST-Upload lieber komplett per PowerShell machen, weil ich über das UI hin und her springe und ich über PowerShell nicht drum herum komme. Außerdem empfehle ich auch hier dringend die Verwendung einer CSV-Datei, um die Benutzer entsprechend zu mappen. Dies ist im Detail sehr schön Schritt für Schritt hier erklärt und ich empfehle euch diese Anleitung wirklich sehr.

https://support.office.com/de-de/article/Verwenden-des-Netzwerkuploads-zum-Importieren-von-PST-Dateien-in-Office-365-103f940c-0468-4e1a-b527-cc8ad13a5ea6?ui=de-DE&rs=de-DE&ad=DE

Manche Ansätze bei der Exchange Online Migration funktionieren wirklich gut und sind sehr intuitiv. Andere sind hingegen noch etwas „Buggy“ oder umständlich. Aber wir sind ja schließlich nicht bei „Wünsch dir was“ und um ehrlich zu sein, eine Migration ist in den allerseltensten Fällen simpel. Daher geht so ein Projekt ohnehin mit viel Planung und Tests einher, bei den dann auch diese auf den ersten Blick komplexeren Ansätze sehr schnell einfach werden, weil die Anwendungsszenarien aus meiner Sicht wirklich gut beherrschbar sind. Und mit den nativen Möglichkeiten haben wir aktuell auch schon wirklich viele gute Ansätze, um Benutzerkonten nach Office 365 zu migrieren. Also nicht warten, sondern starten! 😉

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

SharePoint zu O365 Migration

11. Türchen

Unsere FileShare Daten haben wir schon in der Cloud. Gestern haben wir mit dem eDiscovery Workaround versucht, unseren SharePoint und die darin gespeicherten Daten etwas besser zu verstehen. Mit dem heutigen Beitrag, wie wir mit PowerShell unseren SharePoint nach Office 365 migrieren, finden wir das letzte Puzzle-Teil, um Daten mit nativen Mitteln in die Cloud zu bekommen. Grundsätzlich muss man dann also das große Projekt Office 365 Migration nicht mehr länger vor sich her schieben.

Bevor es aber losgeht, müssen wir bei der SharePoint Migration über die High Speed Migration API noch ein paar Dinge beachten:

  1. Das größte mögliche Migrationspaket kann maximal eine Dokumentenbibliothek (inkl. Ordnerstruktur) umschließen. Eine Site Collection und/oder Subseiten Struktur muss ich also zuvor manuell nachbauen
  2. Die Migration wird nur für SharePoint 2013 und 2016 unterstützt
  3. Bibliotheken und Datenvolumen mit mehr als 15 GB sind nicht möglich
  4. Anpassungen (Solutions, Vorlagen, Apps, etc.) sind auch nicht möglich
  5. die Limits bei der FileShare Migration kommen auch noch dazu

Ansonsten läuft der Prozess identisch zur FileShare Migration ab. Nur ganz wenige PowerShell Befehle unterscheiden sich. Fassen wir das ganze also kurz zusammen.

Voraussetzungen:

  1. Microsoft Azure Login Assistent und PowerShell Module installieren
  2. SharePoint Online PowerShell Modul installieren und laden
  3. Azure Speicherkonto
  4. O365 Tenant mit Administrator-Konto – logisch
  5. Azure Storage Explorer als netter Zusatz für das Überwachen des Prozesses

Ablauf der SharePoint Online Migration:

1. Verbindung zu O365 herstellen

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

2. Migrationspaket erstellen

Add-PSSnaping Microsoft.SharePoint.PowerShell

  • $QuellPfad„\\Server\C`$\SP-O365-Migration“
  • $QuellPaketPfad = „\\Server\C`$\SP-O365-Migration\Quellpaket“
  • $ZielPaketPfad = „\\Server\C`$\SP-O36-5Migration\Zielpaket“
  • $Zielweburl = „https://yourdomain.sharepoint.com/sites/yoursite“
  • $Zielbibliothek = „SharePointMigration“
  • #$OptionalZielOrdner = „OnlineMigration“

Export-SPWeb -Identity „http://onpremwebapp/sites/Sitename“ -ItemUrl „Quellbibliothek“

3. Migrationspaket konvertieren

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

4. Paket zum Azure Storage hochladen

  • $PayloadContainer = „sharepointpayload“
  • $PaketContainer = „sharepointpaketcontainer“
  • $AzureWarteschleife = „sharepointupload“
  • $azureKontoame = „robtheninja“
  • $AzureStorageKey = „hierdeinazurekey==“
  • $SPUpload = Set-SPOMigrationPackageAzureSource –SourceFilesPath $QuellPfad –SourcepackagePath $ZielPaketPfad –FileContainerName $PayloadContainer –PackageContainerName $PaketContainer –AzureQueueName $AzureWarteschleife –AccountName $AzureKontoName -AccountKey $AzureStorageKey

5. Migration starten

  • Submit-SPOMigrationJob –TargetwebUrl $Zielweburl –MigrationPackageAzureLocations $SPUpload –Credentials $Creds

Wir sehen, den einzigen Unterschied zwischen FileShare und SharePoint Migration über die HSM API finden wir in Punkt zwei, nämlich einerseits das Laden der SharePoint On-Premises PowerShell Befehle (Add-PSSnapin) und andererseits wie das Paket erzeugt wird (Export-SPWeb). Diese beiden Befehle habe ich aus der Aufzählung raus genommen und zentriert, um deutlich zu machen, dass dies tatsächlich der einzige Unterschied zur FileShare Migration ist. Der Rest ist identisch (sofern ihr mit Variablen arbeitet). Übrigens, bei dem SharePoint Export-Befehl können wir auch die gewohnten Switches verwenden, wie z.B. „IncludeVersions 4“.

Wie hat es bei euch mit der Migration geklappt geklappt? Lasst es mich wissen. Ich hoffe genauso unkompliziert, wie bei mir.

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

SharePoint Datenklassifizierung

10. Türchen

Um gleich zu Anfang eine wahrscheinlich sehr große Erwartungshaltung zu dämpfen, eine automatische Klassifizierung von Dokumenten in SharePoint ist mit nativen Mitteln aktuell praktisch nicht möglich. Wir können nur PowerShell Skripte schreiben oder 3rd Party Anbieter verwenden. Daher soll euch der heutige Beitrag nur einen Workaround liefern, wie ihr dennoch identifizieren könnt, welche Daten in die Cloud können und welche nicht.

Ein nützliches Feature, das mit der SharePoint Enterprise Edition geliefert wird, nennt sich eDiscovery. Der eigentliche Zweck ist, dass eine SharePoint Farm nach bestimmten Suchbegriffen abgesucht wird. Alle gefundenen Treffer können nicht nur protokolliert werden, sondern die dazugehörigen Daten können auch direkt exportiert werden oder vor Änderungen geschützt werden, damit sie in ihrer originalen Form erhalten bleiben. Diese Daten könnte man dann als Beweis in einem Rechtsstreit verwenden, um z.B. bei einer Patentsverletzung zu zeigen, dass man schon länger an einer entsprechenden Lösung arbeitet, weit bevor ein Konkurrent ein Patent angemeldet hat.

Die eDiscovery beruht auf der SharePoint Suche und damit können wir nicht nur die offensichtlichen Begriffe, wie Dokumententitel, suchen, sondern auch nach dem wirklichen Inhalt der Dokumente. Dies ist entscheidend, um beispielsweise Dokumente zu identifizieren, die in ihrer Fußzeile das Wort „vertraulich“ als Indiz für die Sensibilität stehen haben.

Erstellung einer eDiscovery Query:

Bevor wir unsere Farm nach sensiblen Daten absuchen können, müssen wir eine Site Collection mit der Enterprise Vorlage „eDiscovery Center“ erstellen. Auf dieser Seite können wir dann einen neuen Fall erstellen. Jeder Fall, der aus eDiscovery Sets, Queries und Exporten bestehen kann, stellt dann im Prinzip eine Art Sub-Seite dar.

01a-ediscovery

Für unser Szenario zur Vorbereitung auf eine Office 365 Migration sind die Queries interessant.

01b-ediscovery

Im sich dann öffnenden Fenster ist erst einmal der Suchbegriff wichtig und die Quelle, in der gesucht werden soll. Bei der Quelle können wir einzelne Site Collections angeben. Bequemer ist direkt die Root-Site, da sie auch die Suchergebnisse aller Site Collections dieser Web Application beinhaltet. In der 2013er Version sehen wir aber leider nur eine Komplettanzahl und nicht sortiert nach Site Collection. Um also wirklich unsere Query-Ergebnisse pro Site Collection sehen zu können, müssten wir also leider in der Tat jede Site Collection einzeln zum Scope hinzufügen.

01c-ediscovery

In SharePoint 2016 wurde das besser umgesetzt, da man hier als Quelle angeben kann, dass alles durchsucht werden soll.

02-ediscovery

Auswertung der Ergebnisse:

In SharePoint 2016 wird in den Ergebnissen bereits schön aufgeschlüsselt, in welcher Site Collection viele der Dokumente liegen, die unseren Suchbegriff beinhalten (siehe Screenshot oben). Dies ist im Prinzip genau das, was wir brauchen.

  1. Sichere Daten: Suchen wir nach explizit sicheren Daten, also mit dem Suchbegriff „Öffentlich“ oder „Nicht vertraulich“, so erhalten wir solche Site Collections, welche wir für die Migration „verpacken“ können (siehe morgiges Türchen – ups, jetzt hab ich’s verraten… 😉 )
  2. Sensible Daten: Suchen wir hingegen nach Dateien, die vertrauliche Informationen enthalten, wie z.B. „vertraulich“ oder „Gehaltsnachweis“, dann erhalten wir die Site Collections, die wir lieber noch On-Premises belassen sollten und wenden darauf gleich entsprechende Data Lost Prevention (DLP) Policies an, damit die Mitarbeiter sensibilisiert werden, dass es sich um sensitive Daten handelt (siehe mein Blogbeitrag zu Governance und Compliance mit dem neuen SharePoint 2016 – DLP im Compliance Center).

Diese schöne Übersicht haben wir leider nicht in SharePoint 2013. Da empfehle ich, die Ergebnisse zu exportieren (was aber auch in SharePoint 2016 möglich ist).

04-ediscovery

Die Ergebnisse, also die gefundenen Dateien, kann man direkt exportieren und sie anschließend in ein FileShare Online Migrationspaket verpacken, wie gestern in der FileShare zu O365 High Speed Migration erklärt. Ich persönlich finde, dass dieser Ansatz aber zusätzliche Komplexität erzeugt, weil so einzelne Dateien in der Cloud liegen, andere wieder nicht, die zuvor gemeinsam an einem Ort lagen. Daher dient dieser Workaround nur für sehr spezielle Szenarien.

Interessanter ist jedoch die Möglichkeit, den Report zu exportieren. Damit erhalten wir eine CSV-Liste, die uns alle gefunden Dokumente anzeigt. So können wir, wie schon einen Schritt zuvor mit SharePoint 2016, die Site Collections identifizieren, deren Inhalte entweder noch nicht oder doch schon in die Cloud migriert werden können – je nach Suchbegriff.

Empfehlung:

Diese Workarounds funktionieren ab SharePoint 2010. (Die PowerShell High Speed Migration funktioniert aber erst ab SharePoint 2013 Inhalten). Mit SharePoint 2016 kommen die einfachere Verwaltung sowie DLP Queries hinzu, die uns die Vorbereitung auf eine Online Migration weiter vereinfachen. Nichts desto trotz ist dieser Ansatz nur für sehr eingeschränkte Migrationsszenarien nützlich. Stattdessen empfehle ich hier den Microsoft FastTrack Service oder noch besser 3rd Party Anbieter. weil diese noch weniger Einschränkungen haben und direkte Migrationspfade auch ab SharePoint 2007 bieten.

Für einen Überblick der gespeicherten Daten in meiner Farm und damit etwas mehr Licht in meinen „Dark Data“ kann ich diesen Ansatz dennoch empfehlen als erste Vorbereitung auf eine Online Migration. Denn wenn ich damit sichere Daten und Site Collections identifiziert habe, kann ich diese bereits in die Cloud über die High Speed Migration API migrieren. Wie man diese bestimmten Inhalte oder eine gesamte Farm in die Cloud migriert, erfahren wir morgen.

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

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
    02a-fs-migration
    01a-fs-migration
  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.
    01-fs-migration 02-fs-migration
  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.
    03-fs-migrationDie 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.)
    04-fs-migration
    05-fs-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.

08-fs-migration

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.

08a-fs-migration

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

10-fs-migration

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

FileShare Klassifizierung für O365 Migrationen

8. Türchen

Wir haben uns nun auf Office 365 vorbereitet und wissen, was es grundsätzlich kann – und auch nicht kann hinsichtlich der verfügbaren SharePoint Online PowerShell Befehle. Was fehlt uns nun noch? Die Daten!

Also wollen wir uns heute im ersten Teil den FileShare als Migrationsquelle nach Office 365 anschauen. Viele Firmen sagen mir immer wieder: „Wir können nicht migrieren, weil wir so viele Daten auf dem FileShare haben und wir wissen nicht, ob da sensible Daten dabei sind oder nicht.“ Also wird nicht migriert! Was viele aber gar nicht wissen, Microsoft liefert bereits seit Windows Server 2003 R2 den File Server Resource Manager (FSRM), der den Speicherplatz auf Laufwerken überwacht und auch verhindert, dass bestimmte Dateitypen auf dem Laufwerk abgelegt werden können.

Mit der Zeit wurden diesem Tool immer mehr Funktionen und Richtlinien spendiert, sodass es mittlerweile (seit 2008 R2) auch Daten in FileShares anhand ihres Inhalts klassifiziert kann. Sogar Verschiebe-Aktionen können anhand dieser Klassifizierungen automatisiert vorgenommen werden. Natürlich kann er noch mehr, aber für eine „Sortierung“, um a) sichere Daten zum Migrieren von b) Archivdaten oder sensiblen Daten zu trennen, reicht uns diese Klassifizierungs- und Verschiebe-Funktionalität völlig aus.

Wir schauen uns dies am neuen Windows Server 2016 an. Zunächst müssen wir den Resource Manager über die Management Konsole als Server Rolle aktivieren.

01-addrole

Unter dem Punkt „File and Storage Services“ > „File and iSCSI Services“ müssen wir die „File Server“ sowie „File Server Resource Manager“ Rolle aktivieren. Damit müssen automatisch ein paar zusätzliche Features aktiviert, wie im Screenshot zu sehen ist.

02-addrole

Wir klicken uns weiter durch den Dialog und lassen die Installation abschließen. Anschließend öffnen wir den Resource Manager über die Management Konsole und ich empfehle besonders für den produktiven Betrieb ein paar Grundsätzliche Einstellungen vorzunehmen.

04-fsrm

05-fsrmDies sind die Email-Einstellungen, Ablageorte für Reports und ein automatischer Klassifizierungs-Zeitplan.

06-fsrmWarum ist das wichtig? Ganz einfach! Auf aktiven FileShares sollte

  1. kontinuierlich eine Klassifizierung stattfinden, um Dateien mit Metadaten anzureichen und gegebenenfalls an den richtigen Ablageort automatisch zu verschieben
  2. über Email darüber informiert werden, falls eine automatische Verschiebung stattfand, damit man weiß, wo die Datei nun hin gelangt ist
  3. generell eine Protokollierungen stattfinden, damit man die Dateiverschiebung nachträglich nachvollziehen kann.

Für unser Demo Szenario ist auch eine einfache einmalige Aktion in Ordnung, um Dateien in die richtigen Migrationsordern zu verschieben.

Dieses Szenario der Datensortierung wollen wir nun in drei Schritten konfigurieren:

  1. Im Classification Manager müssen Eigenschaft definieren, die wir in Regeln einbauen wollen. Das heißt, diese Eigenschaftspaare aus Kategorie und Wert werden dann einer Datei oder Ordner hinzugefügt.
    07-fsrm
    08-fsrm
  2. Die oben definierten Eigenschaften binden wir nun in eine Regel ein. Wir vergeben einen entsprechenden Namen und wählen den Ort aus, wo die Regel angewendet werden soll.
    09-fsrm
    10-fsrm
    11-fsrm
    Als nächstes binden wir unsere Werte ein. Für dieses Szenario lasse ich nach den Strings „Oeffentlich“ und „NUR FUER DEN DIENSTGEBRAUCH“ suchen. Werden diese mindestens einmal im Dokument gefunden, dann soll unser Resource Manager die Eigenschaft „O365-Migration-Readiness“ mit dem Wert „O365-Migration-Ready“ hinzu. Zusätzlich suche ich exemplarisch noch nach dem Wert „Vertraulich“ und klassifiziere es entsprechend mit „Nicht O365 Ready“.
    12-fsrm
    Alternativ kann man noch definieren, ob unsere Metadaten existierende Informationen überschreiben oder zusätzlich aggregiert werden sollen (was neu in Windows Server 2016 ist).
    13-fsrm
  3. Im letzten Schritt wollen wir, dass die Daten nicht nur mit Metadaten angereichert werden, sondern zusätzlich sollen die Dateien basierend auf ihrer Klassifizierung in entsprechende Ordner verschoben werden. Dies macht eine anschließende Migration über die High Speed API extrem einfach. Also erstellen wir uns für unser Szenario zwei Aktionsaufgaben.
    14-fsrm
    Auch hier vergeben wir den Aktionen wieder aussagekräftige Namen und den Speicherort, auf den die Aktion angewendet werden soll. Interessant wird es nun auf dem Aktions-Tab. Dort könne wir die Dateien verschlüsseln lassen, „Custom Actions“ wie lokale Skripte ausführen oder die „File Expiration“ auswählen, was wir auch tun. Bitte nicht verwirren lassen. Wir können so natürlich veraltete Dateien ganz einfach auf ein Archiv verschieben. Aber für die Migration nutzen wir diesen kleinen Trick, um die zu migrierenden Dateien in die richtigen Ordner zu verschieben. Der muss also noch in diesem Tab als Zielordner angegeben werden.
    16-fsrm
    Wichtig ist nun noch die Konfiguration, wann die Aktion ausgeführt werden soll, also wann unsere vorher definierte Eigenschaft am Dokument gefunden werden. Dies ist ein Real-Time Scanning, wovon wir in SharePoint Online aktuell noch sehr weit entfernt sind.
    17-fsrm
    Der Tab mit den Notifications und dem Report-Ablageort spielt eine Rolle für die eingangs erwähnte Empfehlung bei produktiven Umgebungen. Beim Schedule-Tab ist noch interessant zu erwähnen, dass neben regelmäßigen Scans auch die Aktion sofort bei neu hinzugefügten Dateien durchgeführt werden kann.

Nun müssen wir die Aktionen nur noch direkt ausführen, damit wir gleich ein Ergebnis sehen. Dies ist bei kleinen FileShares in der Regel in wenigen Sekunden erledigt. Als Ergebnis erhalten wir folgende Ordnerstruktur:

21-fsrm

Wir sehen also, an die Datei wurde im Tab „Classification“ unsere definierte Eigenschaft „O365-Migration-Readiness“ mit dem Wert „O365-Migration-Ready“ angehängt, weil in der Datei der String „Oeffentlich“ gefunden wurde. Daraufhin hat der Resource Manager die Datei in den von mir definierten Zielordner „O365-Migration“ (siehe Hervorhebung in gelb) verschoben. In Orange hervorgehoben sehen wir, von welchem Server die Datei kommt und zu welchem Scan/Aktionszeitraum dies geschah. Danach wird dann (grün hervorgehoben) die originale Ordnerstruktur nachgebaut, wo die Datei ursprünglich lag. Die Metadaten, die ich mir oft in FileShares durch eine Ordnerstruktur aufgebaut habe, bleibt also erhalten. Dennoch habe ich die sensiblen von den sicheren Daten getrennt und kann nun im nächsten Schritt ein Migrationspaket bauen, um die sicheren Dateien nach O365 zu migrieren. Aber dazu später mehr…

Im obigen Teil haben wir lokale Eigenschaften definiert. Aber wer von euch hat mehr als nur einen FileShare? Richtig, für gewöhnlich habe wir mehrere FileShares und lokale Eigenschaften müssten so mehrfach definieren. Dafür haben wir die Dynamic Access Control, die wir über das Active Directory Administration Center erreichen. Damit können wir zentral von einem Domain Controller Eigenschaften veröffentlichen, um sie anschließend einfach auf jedem FileShare auswählen zu können. Die Dynamic Access Control im Administration Service sollte standardmäßig auf einem DC mit Active Directory Services installiert sein.

Von da aus wählen wir die Resource Properties und sehen, dass schon einige existieren, die wir nun aktivieren können. Wir können hier aber auch neue Eigenschaften definieren, wie schon oben als lokale Eigenschaft, die dann auf allen unseren FileShare Servern auftauchen.

24-fsrm

Mit dem einfach PowerShell Befehl

Update-FsrmClassificationPropertyDefinition

kann man die Synchronisation der neuen Eigenschaften forcieren oder man wartet bis zum nächsten AD Synchronisationsjob. Geht man dann wieder zum Resource Manager, so sehen wir, dass nun die beiden veröffentlichten Eigenschaften auftauchen mit dem Scope „Global“.

25-fsrm

Weiterhin haben wir die Möglichkeit, auf weitere vordefinierte (englische) Eigenschaften zurück zu greifen. Dafür gibt es von Microsoft das Data Classification Toolkit. https://www.microsoft.com/en-us/download/details.aspx?id=27123

Dieses Paket, welches aktuell noch nicht auf Windows Server 2016 Kompatibilität gebracht wurde, enthält noch weitere Eigenschaften für folgende fünf Bereiche

  • Information Privacy
  • Information Security
  • Legal
  • Records Management
  • Organizational

Weitere Details, wie ihr dieses Toolkit nutzen könnt, findet ihr auf diesem Blog von Russell Smith: http://www.biztechmagazine.com/article/2011/12/how-use-microsofts-data-classification-toolkit

Fassen wir also zusammen. Wir können den Windows Server File Resource Manager nutzen, um Ordnung in unsere FileShares zu bringen. Das heißt, sensible von sicheren Daten trennen, um so eine Office 365 Migration vorzubereiten.

Dazu definieren wir zunächst Eigenschaften und dazugehörige Werte, anhand dessen wir aufräumen wollen. Als zweites legen wir Scan-Regeln fest, die definieren, bei welchen gefundenen Informationen dieentsprechenden Dokumente mit welchen Metadaten klassifiziert werden sollen. Als drittes kommen die Aktionen ins Spiel, die auf diese Metadaten anspringen und dann bestimmte Aktionen durchführen können. Hinweis: Mit einer Custom Action über PowerShell könnte man direkt Migrationspakete erstellen lassen. Aber alles zu seiner Zeit.

„So viel Heimlichkeit, in der Weihnachtszeit…“ 😉

Happy „SharePointing“!

Zur O365Adventskalender Übersicht

Microsoft FastTrack

4. Türchen

Zunächst einmal einen fröhlichen 2. Advent!

Aber nun „back to Business“. Nehmen wir einmal an, ihr habt euch bereits für Office 365 entschieden und möchtet nun eure Daten in die Cloud migrieren. Obwohl Microsoft so schnell und viele Daten wie möglich in O365 intergieren möchte, so gab es bis vor Kurzem nur sehr eingeschränkte Möglichkeiten, diese zu migrieren. Entweder konnten Daten über das Netzwerk auf einen temporären Speicherort in der Microsoft-Cloud abgelegt werden und danach in O365 importieren werden. Oder man hat ein komplettes Laufwerk mit den FileShare-Daten oder SharePoint Datenbanken verschickt. Auf die Details und weitere Möglichkeiten gehen wir in einem späteren Türchen ein.

Für heute ist zunächst wichtig zu verstehen, dass bisherige Migrationsmöglichkeiten sehr umständlich waren und Microsoft die Kunden damit eher allein gelassen hat. Nicht weiter verwunderlich, dass sich besonders im deutschsprachigen Raum dadurch nicht gerade Migrations-Euphorie breit gemacht hat.

Umso mehr freue ich mich, dass Microsoft wieder auf die Wünsche der Kunden hört und nun seit einigen Monaten den FastTrack Service im Angebot hat. Damit gibt es nun nicht nur die Werkzeuge, sondern auch das Know-How direkt aus dem Hause Microsoft, um Kunden bei der Migration nach Office 365 zu unterstützen.

Migrationsprozess:

Aber der Reihe nach. Was heißt Know-How? Microsoft stellt wirklich Ressourcen zur Verfügung, die mit dem Kunden gemeinsam seine Quellumgebungen analysieren. Mit einem „Sanierungsplan“ und den Ergebnissen der Umgebungsanalyse wird dann eine Check-Liste erarbeitet. Diese wird abgearbeitet und die Migration mit all ihren Voraussetzungen und Tests vorbereitet.
fasttrack-01-small

Migration von Emails:

Neben dem Wissenstransfer bringt Microsoft auch die Programme mit, die nicht nur die Umgebungen analysieren, sondern auch bei der Migration unterstützen. So ist es Microsoft möglich, Emails von verschiedenen Anbietern problemlos zu migriert. Den aktuellen Stand der Email-Migrationsquellen seht ihr im Screenshot.
fasttrack-02-small

Datenmigration:

In Sachen Daten können File-Server, Google Drive und Box angesprochen werden. Im Gegensatz zu normalen Uploads über SharePoint Online, Synchronisierungen oder der Verwendung der Explorer-Ansicht, können bei diesem Ansatz auch Ordnerstrukturen, Berechtigungen, Versionen sowie einfache Metadaten beibehalten werden. Dies ist ein wirklich großer Mehrwert!

Aber noch besser ist, dass seit der Ignite Konferenz im September 2016 auch SharePoint On-Premises Team Sites und MySites als Migrationsquelle in den FastTrack Service aufgenommen wurden. Damit können nun folgende einfache SharePoint-Seiten mit Microsoft migriert werden:
fasttrack-05-small

Bei komplexeren Seiten und Strukturen rät Microsoft,

  1. diese zunächst in einem hybriden Deployment On-Premises zu belassen
  2. Nur die Inhalte zu migrieren oder
  3. In der Cloud zu rekonstruieren.

Zu diesen komplexeren Geschichten gehört folgendes:
fasttrack-06-small

Abschluss und Mehrwert:

Aber auch nach der Migration hört der Service nicht auf. Es wird das Ergebnis evaluiert und gemeinsam mit dem Kunden die finalen Schritte geplant und umgesetzt, wie z.B. die alte Farm abschalten, zusätzliche Apps und Clients installieren und Endanwender per HelpDesk in der neuen Umgebung „an die Hand nehmen“.
fasttrack-07-small

Da mehr als 50% der Menschen Neuerungen zunächst skeptisch gegenüberstehen, steht und fällt so ein neues Portal oft mit der Nutzerakzeptanz. Mit Hilfe des Microsoft FastTrack Services wird sichergestellt, dass der gesamte Migrationsprozess reibungslos abläuft und selbst nach Abschluss zusätzlich die Nutzerakzeptanz durch Flyer, Poster, Videos und sogar Schulungen verbessert wird.

Dies ist aus meiner Sicht definitiv die richtige Strategie, um Kunden von der Office 365 Cloud zu überzeugen. Man lässt sie nicht mehr mit ihren Fragen allein, sondern arbeitet Hand in Hand zu einem gemeinsamen Ziel.

Und das Beste kommt zum Schluss: Dieser Service ist für alle Office 365 Kunden mit mindestens 50 Nutzer-Lizenzen kostenlos! Also worauf warten und gleich ausprobieren:

http://fasttrack.microsoft.com/de-DE/

Die Aufzeichnung zur FastTrack Präsentation auf der Ignite Konferenz findet ihr hier:

https://myignite.microsoft.com/videos/2660

Viel Spaß und „Happy SharePointing“!

Zur O365Adventskalender Übersicht