In diesem Beitrag möchte ich einige Hinweise zum Thema Upgrade auf SharePoint 2013 geben. Zunächst einmal einige Fakten:

• Inplace-Upgrade existiert nicht mehr
• Visual Upgrade aus SharePoint 2010 gibt es in dieser Form auch nicht mehr und wird durch das Deferred Site Collection Upgrade ersetzt

Database Attach

Der einzig gangbare Weg für ein Upgrade von SharePoint 2010 ist demnach das Database Attach, das auch bereits von vielen für das Upgrade auf SharePoint 2010 empfohlen wurde. Dabei wird eine komplett neue Farm aufgebaut und nur die Inhalte über ein Anhängen der Content Datenbanken überführt. Zusätzlich können in SharePoint 2013 die Datenbanken folgender Service Applications angehängt werden:

• Business Data Connectivity
• Managed Metadata
• PerformancePoint
• Secure Store
• User Profile (Profile, Social, and Sync databases)
• Search administration

Hier möchte ich mich aber zunächst nur auf die Content-Datenbanken beziehen. Wie bisher auch können diese an eine WebApplication angehängt werden. SharePoint stellt dabei dann Version Mismatch fest und wird ein “Version to Version”-Upgrade vornehmen. Vor dem Anhängen sollten aber einige Punkte beachtet werden:

• Welche Solutions bzw. Features werden noch benötigt? Nicht mehr benötigte sollten sauber entfernt und deinstalliert werden, alle anderen müssen in der neuen Umgebung installiert werden
• Inhalte sollten aufgeräumt werden, z.B. nicht mehr benötigte Sites und Site Collections gelöscht werden
• Welche Authentifizierungsmethode wird verwendet?

Vor allem die letzte Frage ist hier kriegsentscheidend!

Authentication Provider

WebApplications werden in SharePoint 2013 über die Zentraladministration immer im Claims Based Mode erstellt. Der in SharePoint 2010 voreingestellte Classic Mode wird zwar noch unterstützt, jedoch kann eine WebApplication damit nur per PowerShell erstellt werden. Zudem funktionieren hierunter dann (anders als in 2010) die Previews für die Office WebApps nicht mehr.

Daher wird stark empfohlen, bestenfalls vor der Migration eine Umstellung auf Claims Based Authentication vorzunehmen, spätestens aber direkt nach dem Anhängen der Content Database.

Wer in der alten Umgebung bereits Claims Based Authentication einsetzt, hat hier also eventuell einen Vorteil, jedenfalls wenn er Windows Claims verwendet. Bei SAML Claims sieht das Ganze wieder anders aus, denn die entsprechenden Provider und Claim Types müssen wieder registriert werden. Die Reihenfolge der Installation ist nun nicht mehr entscheidend, aber bei den Claim Types wird es kritisch: Denn in SharePoint 2010 wird jedem Claim Type für die Eindeutigkeit ein Encoding Character beginnend bei Unicode 500 mitgegeben. Dieser muss in 2013 natürlich wieder exakt passen, damit die Claim Types wieder korrekt funktionieren. Hier ist also weitere Arbeit notwendig

Deferred Site Collection Upgrade

Diese neue Upgrade-Funktion ist sehr interessant. Nach dem Anhängen und dem Upgrade einer Content Datenbank sehen die Sites standardmäßig genau aus wie in SharePoint 2010. Dies hört sich nun erst einmal nach Visual Upgrade an, das Verfahren hier ist jedoch komplett anders. Sie sehen nämlich nicht nur wie in SharePoint 2010 aus, sondern verhalten sich auch exakt gleich.

Diese Tatsache liegt daran, dass SharePoint 2013 nicht nur einen 15er-Hive, sondern auch einen 14er-Hive installiert, die kompletten Binaries und Dateien von SharePoint 2010 werden also mitgeliefert. Befindet sich eine Site Collection in Compatibility Range 14, rendern die 2010er-Binaries die Website. Der Mechanismus dahinter ist sehr komplex, daher lasse ich ihn an dieser Stelle erst einmal weg. Das Datenbankschema wurde nun also angepasst, aber die eigentlichen Inhalte sind noch nicht migriert.

Nun hat ein Site Collection Administrator selbst die Möglichkeit, ein Upgrade vorzunehmen. Da es hier keinen Weg zurück gibt, gibt es die Möglichkeit, eine Eval-Site zu erzeugen. SharePoint legt dabei eine Kopie der Site Collection an und führt dort das Upgrade durch. Diese wird nach standardmäßig 30 Tagen automatisch gelöscht. Die Kopie wird dabei (wenn lizenztechnisch möglich) über einen SQL Snapshot vorgenommen, ansonsten über Backup/Restore der Site Collection.

Dies ermöglicht es nun auch, dass generell SharePoint 2010-Websites erstellt werden können, hierzu existiert ein entsprechendes DropDown:

Die CompatibilityRange hat jedoch auch noch Einfluss auf Solutions und Features. Hier eröffnet sich also auch für Entwickler eine große Thematik, die beachtet werden muss, z.B. entscheidet SharePoint wenn man es nicht direkt angibt beim Installieren einer Solution auf Basis der im Manifest hinterlegten SharePointProductVersion, in welchen Hive die Daten kopiert werden.

Site Upgrade Limits

Wird nun eine Site Collection aktualisiert, stellt dies natürlich einen extremen Arbeitsaufwand auf WebServer- und Datenbankseite dar. Daher werden Standardlimits auf beiden Seiten gesetzt. Pro Content Datenbank sind im Standard maximal 10 Upgrades gleichzeitig erlaubt, pro WebService-Instance (d.h. pro WebApplication pro Server) sind 5 voreingestellt. D.h. mit zwei SharePoint-Servern und einer Content-Datenbank sind 10 Upgrades gleichzeitig möglich. Alle weiteren werden in eine Queue eingestellt und später abgearbeitet. Ein Timer Job übernimmt die komplette Upgradeaufgaben, nach dem Upgrade verschickt er dann eine E-Mail an den Site Collection Administrator.