Die wohl auffälligste Änderung in SharePoint 2010 zu den vorherigen Versionen, ist die Integration der bereits aus den Office Produkten bekannten Ribbon Leiste. Wie so vieles im SharePoint kann auch diese von Entwicklern erweitert und angepasst werden.

Im Folgenden wird ein Beispiel gezeigt, um eine eigene Schaltfläche in die Ribbon Leiste zu integrieren.

Zur Anpassung der Ribbon Leiste wird ein neues Feature mit Visual Studio 2010 erstellt. Dies vereinfacht das spätere Deployment durch die Erstellung einer wsp Datei.

(continue reading…)

Während in SharePoint 2007 Dokumente lediglich über Ordner strukturiert werden konnten, bietet SharePoint 2010 ein neues Feature, mit welchem Dokumente und zugehörige Metadaten einfach strukturiert und verwaltet werden können – das Document Set.

Das Document Set bietet die folgenden neuen Kernfunktionen:

• Definition der in einem Document Set erlauben Content Types
• Definition von Dateien, welche in jedem Dokument Set vorhanden sein sollen
• Alle Dokumente innerhalb eines Document Sets teilen die selben Metadaten
• Eine Welcome Page, welche eine Zusammenfassung der wichtigsten Metadaten liefert
• Das gesamte Set kann versioniert werden
• Einfache Verwaltung über die SharePoint Oberfläche
• Document Sets basieren auf den SharePoint Content Types, es können also beliebig viele Document Set Content Types mit verschiedenen Inhalten vordefiniert werden

Hinweis: Document Sets sind ein Feature des SharePoint Servers 2010, sie sind also nicht in den SharePoint Foundations vorhanden.

Document Sets bieten sich immer dann an, wenn es ein oder mehr Standarddokumente gibt, die in verschiedenen Bereichen benötigt werden, oder wenn verschiedene Dokumente dieselben Eigenschaften teilen müssen.

Die einzelnen Features im Detail

Definition von erlaubten Content Types

Man kann selbst bestimmen, welche Content Types innerhalb eines Document Sets erlaubt sind, unabhängig von den erlaubten Content Types der übergeordneten Document Library.

Standarddokumente

Dokumente, welche als Default Content, zu einem Document Set hinzugefügt werden, werden automatisch in jedem neuen Document Set erstellt. Zusätzlich kann definiert werden, ob jede Datei automatisch den Namen des Document Sets als Präfix erhalten soll.

Geteilte Metadaten

Die Inhalte, der unter Shared Columns ausgewählten Spalten, werden auf alle Dokumente innerhalb des Document Sets synchronisiert.

Welcome Page

Die Welcome Page zeigt zum einen eine Zusammenfassung der wichtigsten Metadaten (Welcome Page Columns) und kann zum anderen einen eigenen View zur Verfügung stellen, mit dem die Dokumente innerhalb des Document Sets angezeigt werden sollen (Welcome Page View). Dies ermöglicht es innerhalb des Dokument Sets andere Spalten anzuzeigen, als auf Bibliotheksebene.

Man kann die Standard Welcome Page verwenden, oder diese an die eigenen Bedürfnisse anpassen. Hierzu stehen dieselben Möglichkeiten zur Verfügung, wie bei der Bearbeitung einer normalen SharePoint Seite.

Versionierung

Das Document Set bietet die Möglichkeit unabhängig von den einzelnen Dokumentenversionen eine Gesamtversion des Document Sets zu erstellen. So ist es möglich, erst verschiedene Versionen der in dem Document Set enthaltenen Dokumente zu erstellen, bevor eine gemeinsame Document Set Version erstellt wird.

Die einzelnen Dokumente werden wie gewohnt anhand der Versionierungseinstellungen der Bibliothek versioniert und verfügen alle über eine eigene Versionshistorie.

Um nun eine Version des gesamten Document Sets zu erstellen, gibt es innerhalb des Document Sets die Schaltfläche “Capture Version” in der Ribbonleiste.

Die Versionierung des Document Sets erlaubt es uns selbst, zu entscheiden, welche Versionen der einzelnen Dokumente in die Version des Document Sets gehören. So können z.B. nur die letzten Hauptversionen aller Dokumente beachtet werden.

Zusätzlich kann ein Versionskommentar gesetzt werden.

Die Versionshistorie des Document Sets zeigt sowohl die Versionen des Document Set selbst, als auch die Versionen der einzelnen Dokumente an.

Workflows

Genau wie auf einzelnen Dokumenten können auch auf Document Sets Workflows gestartet werden. Dies ermöglicht z.B. einen globalen Genehmigungsprozess für alle Dokumente innerhalb des Document Sets. Zusätzlich können natürlich auch für alle Dokumente innerhalb des Document Sets einzelne Workflows gestartet werden.

Der Document Set Content Type

Das Document Set ist ein normaler SharePoint Content Type. So kann das Document Set z.B. global über die Site Content Types angepasst werden, oder für jede einzelne Bibliothek, in welcher es verwendet wird. Zusätzlich können neue Content Types basierend auf dem Document Set erzeugt werden.

Verwendung von Document Sets

Der Document Set Content Type ist im SharePoint standardmäßig nicht verfügbar. Dieser muss erst mit dem “Document Sets Feature” auf Site Collection Ebene aktiviert werden.

Um Document Sets verwenden zu können, müssen die folgenden Schritte ausgeführt werden:

1. Unter Site Collection Features muss das Document Set Feature aktiviert werden

   

   Damit ist der Document Set Content Type verfügbar

2. In der Bibliothek, in welcher das Document Set verwendet werden soll, muss dieses als Content Type hinzugefügt werden. Hierzu unter Library Settings –> Advanced Settings den Punkt “Allow management of content types” aktivieren.

   

   In den Einstellungen für die Bibliothek erscheint nun ein neuer Bereich – “Content Types”

3. Unter Einstellungen einen existierenden Content Type hinzufügen und den Document Set Content Type auswählen

   

   Das Document Set kann ab jetzt in der Bibliothek verwendet werden

   

4. Alle oben genannten Einstellungen für das Document Set können über die Eigenschaften des Content Types unter “Document Set Settings” vorgenommen werden.

Die neue Fast Search für SharePoint bietet viele neue Funktionen, u.a. eine Vorschau von Dokumenten. Für Word Dokumente wird die erste Seite angezeigt, für PowerPoint kann sogar die gesamte Präsentation als Preview eingesehen werden.

Läuft die SharePoint Seite unter SSL wird man statt mit der Preview, jedoch mit einem JavaScript Fehler begrüßt.

Der Fehler betrifft nur die Vorschaubilder, während alle anderen Features der Fast Search anscheinend problemlos funktionieren.

Die Details des Fehlers lauten ungefähr wie folgt:

Meldung: Syntaxfehler
Zeile: 2
Zeichen: 1
Code: 0
URI: https://meinSharePoint.oraylis.de/personal/documents/_vti_bin/wacproxy.ashx?redirect=https%3A%2F%2FmeinSharePoint.oraylis.de%2Fpersonal%2Fdocuments%2F_layouts%2FWordViewer.aspx
%3Fid%3D2Fpersonal%2Fdocuments%2FShared%2520Documents%2F
Der%2520ORAYLIS%2520Test.docx%26DefaultItemOpen%3D1&spsite=https%3A%2F%2FmeinSharePoint.oraylis.de%2Fpersonal%
2Fdocuments&docType=docx&zone=undefined&callbackFunctionName=
DelegateFn_SRB_g_3897520d_8fa6_4997_88c8_5ac1f1b642a5_5

Um den Fehler zu lösen muss das Root-Zertifikat nicht nur am Server selbst und im IIS installiert werden, sondern auch noch einmal explizit in die SharePoint Trusts aufgenommen werden.

Hierzu in der SharePoint Central Administration in den Bereich Security wechseln und die Seite Manage trust aufrufen.

Hier auf New klicken und das Root Zertifikat hinzufügen.

Der JavaScript Fehler verschwindet sofort und auch die Vorschaubilder werden bei der nächsten Suche angezeigt. Sollte der JavaScript Fehler behoben sein, die Vorschaubilder jedoch nicht angezeigt werden, heißt es ein wenig Geduld haben. Die Dokumente müssen erst gecached werden.

Der Object Cache wird vom Publishing Feature genutzt und speichert Eigenschaften von verschiedenen SharePoint Elementen. Das Ziel des Object Caches ist es u.a. die Last des SQL Servers zu reduzieren. Mehr Informationen zum Object Cache gibt es unter http://technet.microsoft.com/en-us/library/ff758656.aspx.

Wurden die Standardeinstellungen des Object Caches übernommen und das Publishing Feature in einer Applikation aktiviert, so wird in regelmäßigen Abständen die folgende Warnung ins Windows Event Log geschrieben:

Event ID: 7362

Log Name:          Application
Source:               Microsoft-SharePoint Products-Web Content Management
Date:                  11.10.2010 12:03:30
Event ID:           7362
Task Category: Publishing Cache
Level:                 Warning
Keywords:
User:                  <SharePoint System Account>
Computer:          <SharePoint Server>
Description:
Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.
To configure the account use the following command ’stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
Additional Data:
Current default super user account: SHAREPOINT\system

Ursache

Standardmäßig wird der SharePoint Systemaccount als Cache Super User Account eingetragen. Allerdings sollte dieser für jede Webapplikation, welche das Publishing Feature verwendet, auf zwei Domänenbenutzer aufgeteilt werden.

Warum zwei Benutzer?

Der Object Cache führt seine Abfragen als einer von zwei Benutzern aus, entweder als “Super User”, welcher vollen Zugriff auf alle Objekte im SharePoint hat (so z.B. auch auf Dokumente, welche noch den Status “Entwurf” haben), oder als “Super Reader”, welcher nur Zugriff auf veröffentlichte Objekte hat. Führt ein Benutzer nun z.B. eine Suche aus, so werden die Ergebnisse aus dem Cache angezeigt. Je nach dem, über welche Berechtigungen der Benutzer selbst verfügt, werden ihm entweder die Ergebnisse des “Super Users” oder des “Super Readers” angezeigt.

Lösung

Im Active Directory müssen zwei neue Benutzeraccounts angelegt werden. Diese Accounts benötigen keine besonderen Rechte oder Gruppenzugehörigkeiten. Die beiden Accounts sollten ausschließlich als Cache Accounts verwendet werden und niemals dafür die SharePoint Seite über den Browser aufzurufen.

Um die Benutzer nun richtig zu konfigurieren gibt es verschiedene Möglichkeiten. Diese Schritte müssen für alle Webapplikationen durchgeführt werden müssen, welche das Publishing Feature verwenden.

Variante 1: Central Administration und Power Shell

1. In der SharePoint 2010 Central Administration im Bereich Application Management die Seite Manage web applications öffnen.
2. Den Namen der Webapplikation auswählen, für welche die Konfiguration vorgenommen werden soll.
3. Aus dem Web Applications Tab die Option User Policy auswählen.
4. Im “Policy for Web Application” Fenster auf “Add Users” klicken.
5. Als Zone “All zones” auswählen und auf “Next” klicken.
6. Den Namen des Super User Accounts eintragen und als Berechtigung “Full Control – Has full control” auswählen.
7. Auf “Finish” klicken und auf die selbe Art und Weise den Super Reader Account hinzufügen. Als Zone wieder “All zones” wählen und als Berechtigung “Full Read – Has full read-only access” einstellen.
8. Eine Power Shell/SharePoint 2010 Management Konsole öffnen die folgenden Befehle ausführen:

   $wa = Get-SPWebApplication -Identity "<Name oder URL der WebApplication>"
   $wa.Properties["portalsuperuseraccount"] = "<SuperUser>"
   $wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"
   $wa.Update()

   Hierbei ist wichtig, dass die Namen der beiden Benutzer Accounts in der selben Schreibweise angegeben werden, wie sie im Fenster “Policy for Web Application” angezeigt werden.

Tipp: Die oben gezeigten Befehle können auch als Power Shell Skript (.ps1 Datei) gespeichert werden.

Variante 2: Power Shell

Muss die Einstellung für mehrere Applikationen vorgenommen werden, lohnt sich die Automatisierung über ein Power Shell Script.

$webapp = Get-SPWebApplication –Identity http://webapp

# Reader Account registrieren und berechtigen
$rdrcred = New-SPManagedAccount –Credential (Get-Credential)
$rdrpol = $webapp.Policies.Add($rdrcred.Username, $rdrcred.Username)
$rdrpol.PolicyRoleBindings.Add($webapp.PolicyRoles.GetSpecialRole(“FullRead”)) 

# Writer Account registrieren und berechtigen
$wrtcred = New-SPManagedAccount –Credential (Get-Credential)
$wrtpol = $webapp.Policies.Add($wrtcred.Username, $wrtcred.Username)
$wrtpol.PolicyRoleBindings.Add($webapp.PolicyRoles.GetSpecialRole(“FullControl”)) 

# Accounts zuweisen
$webapp.Properties["portalsuperuseraccount"] = $wrtcred.Username
$webapp.Properties["portalsuperreaderaccount"] = $rdrcred.Username 

$webapp.Update()

Variante 3: Central Administration und STSADM

Für alle, die sich noch nicht mit der PowerShell auseinander gesetzt haben, gibt es die Möglichkeit die Benutzer auch über stsadm zu konfigurieren. Ich lege allerdings jedem SharePoint 2010 Administrator ans Herz sich schnellstmöglich mit der Power Shell vertraut zu machen, da stsadm in Zukunft von dieser abgelöst wird.

1. Die Schritte 1 bis 7 aus dem Abschnitt “Variante 1: Central Administration und Power Shell” ausführen, um die Benutzer der Web Applikation zuzuordnen.
2. Die nachfolgenden stsadm Befehle für jede Webapplikation ausführen:

   stsadm -o setproperty -propertyname portalsuperuseraccount
                         -propertyvalue "<SuperUser>" -url "<http://webapp>"
   stsadm -o setproperty -propertyname portalsuperreaderaccount
                         -propertyvalue "<SuperReader>" -url "<http://webapp>"  

Dieser Beitrag macht den Anfang einer kleinen Serie, in welcher die häufigsten Fehler- und Warnmeldungen thematisiert werden, welche sowohl nach einer Neuinstallation, als auch einer Migration von SharePoint 2007 auf SharePoint 2010 auftreten können.
Alle hier beschriebenen Fehler werden im Windows Event Log protokolliert.

Den Anfang machen die Warnmeldungen mit den Event IDs 1001,1004, 1015 und die Fehlermeldung mit der Event ID 7043.

Jonathan Briggs hat in seinem Blog übrigens eine sehr ausführliche Sammlung von weiteren Fehlern, welche nach einem In Place Upgrade auftreten können.

http://wiki.softartisans.com/display/~jonathanb/2010/08/13/Adventures+upgrading+to+SharePoint+2010

Windows Installer Warnung bei Benutzerprofilimport

Bei jedem Profilimport werden vom MsiInstaller drei Warnmeldungen ins Event Log geschrieben, der Profilimport scheint allerdings ohne weitere Probleme zu funktionieren.

Event IDs: 1001, 1004, 1015

Log Name:          Application
Source:               MsiInstaller
Date:                  08.10.2010 01:00:00
Event ID:           1001
Task Category: None
Level:                 Warning
Keywords:          Classic
User:                  NETWORK SERVICE
Computer:          <SharePoint Server>
Description:
Detection of product ‘{90140000-104C-0000-1000-0000000FF1CE}’, feature ‘PeopleILM’ failed during request for component ‘{9AE4D8E0-D3F6-47A8-8FAE-38496FE32FF5}’

Log Name:         Application
Source:              MsiInstaller
Date:                  08.10.2010 01:00:00
Event ID:           1004
Task Category: None
Level:                 Warning
Keywords:          Classic
User:                  NETWORK SERVICE
Computer:          <SharePoint Server>
Description:
Detection of product ‘{90140000-104C-0000-1000-0000000FF1CE}’, feature ‘PeopleILM’, component ‘{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}’ failed.  The resource ‘C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe’ does not exist.

Log Name:         Application
Source:              MsiInstaller
Date:                  08.10.2010 01:00:00
Event ID:           1015
Task Category: None
Level:                 Warning
Keywords:          Classic
User:                  NETWORK SERVICE
Computer:          <SharePoint Server>
Description:
Failed to connect to server. Error: 0×80070005

Ursache

Die WMI Aufrufe werden unter dem Network Service Account ausgeführt, welcher keine Berechtigungen auf das Verzeichnis hat, in welchem sich die Microsoft.ResourceManagement.Service.exe befindet.

Lösung

Erteilen Sie dem Network Service Read & Execute Rechte auf das Verzeichnis C:\Program Files\Microsoft Office Services\14.0\. Alternativ können Sie dem Network Service auch explizit Read & Execute Rechte auf den beiden Verzeichnissen C:\Program Files\Microsoft Office Servers\14.0\Service und C:\Program Files\Microsoft Office Servers\14.0\SQL geben.

“Load control template file /_controltemplates/TaxonomyPicker.ascx failed”

Spätestens nach jedem IIS Reset wird ein Fehler im Windows Event Log ausgegeben, welcher besagt, dass die Datei “TaxonomyPicker.ascx” nicht geladen werden konnte.

Event ID: 7043

Log Name:         Application
Source:              Microsoft-SharePoint Products-SharePoint Foundation
Date:                  08.10.2010 11:02:52
Event ID:           7043
Task Category: Web Controls
Level:                 Error
Keywords:
User:                  <SharePoint Systemaccount>
Computer:          <SharePoint Server>
Description:
Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.

Ursache

Dieser Fehler scheint eine Altlast in SharePoint zu sein, da die Datei “TaxonomyPicker.ascx” in SharePoint 2010 eigentlich nicht mehr im Gebrauch ist und durch die Datei “TaxonomyTreePicker.ascx” ersetzt wurde.

Lösung

Öffnen Sie das Verzeichnis C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES und benennen Sie die Datei “TaxonomyPicker.ascx” um, z.B. in “TaxonomyPicker.ascx_alt”.
Durch das Umbenennen der Datei wird verhindert, dass bei jedem neu übersetzen des Application Pools versucht wird die Datei zu laden.

Wird in SharePoint eine neue Page erstellt (sei es eine Webpart-, Publishing- oder Blank Page) wird in dieser die Quick Launch Navigation (zu deutsch Schnellstartleiste) standardmäßig nicht angezeigt. Dies gilt auch für Seiten vom Typ “Meeting Space”.

An dieser Stelle geht leider das einheitliche “Look and Feel” des SharePoint  verloren und viele möchten die Navigation wieder anzeigen. SharePoint selbst bietet hierfür auch in der 2010er Version noch keinen Schalter in der Oberfläche. Doch mit Hilfe des SharePoint Designers kann dieses Verhalten schnell geändert werden.

1. Die gewünschte Page im SharePoint Designer öffnen (am einfachsten über das Kontextmenü der Page, direkt aus SharePoint heraus)
2. Wer bereits mit dem SharePoint Designer 2010 arbeitet muss noch den “Erweiterten Modus” aktivieren

   

3. In der Codeansicht nach einem “SharePoint:UIVersionedContent”-Element mit der ID “WebPartPageHideQLStyles” suchen. Dieses muss komplett gelöscht werden

    

4. Ebenso die folgenden Placeholder Elemente löschen: 
   1. PlaceHolderPageImage (optional)
   2. PlaceHolderNavSpacer (optional)
   3. PlaceHolderLeftNavBar (erforderlich)

   

5. Speichern und die Seite im Browser neu aufrufen 

Tritt diese Anforderung häufiger auf, so sollte ein eigenes Template erstellt werden, welches zukünftig bei der Erstellung einer neuen Page verwendet wird.

Bei der Migration von Microsoft Office SharePoint Server 2007 auf Microsoft SharePoint Server 2010 kann gewählt werden, ob direkt das neue SharePoint Layout eingesetzt werden soll, oder ob das Portal zunächst im alten Layout weiterbestehen soll.

Das Visual Upgrade erst später durchzuführen ist vor allem dann sinnvoll, wenn zunächst noch Anwenderschulungen durchgeführt werden sollen, welche jedoch zum Zeitpunkt der eigentlichen Migration noch nicht stattfinden konnten, oder diese am eigenen System durchgeführt werden sollen.

Einer der Vorteile beim Visual Upgrade ist die Möglichkeit, das neue Layout erst zu testen, bevor es endgültig freigeschaltet wird. So können Administratoren beliebig zwischen beiden Ansichten umschalten, ohne das dies Auswirkungen auf die Ansicht der Endanwender hat.
Das Visual Upgrade ist außerdem Seitenbasiert, so können einige Seiten bereits migriert werden, während andere noch im alten Layout verbleiben.

Um das Visual Upgrade für eine einzelne Site durchzuführen müssen zwei Schritte ausgeführt werden:

1. Ändern der Masterpage auf “V4.master”
2. Auswahl der Aktion “Visual Upgrade” aus dem Site Actions Menü. An dieser Stelle können Administratoren festlegen, ob es sich bereits um das endgütige Upgrade oder nur um eine Vorschau zum Testen handeln soll.

Hat man viele Sites in seinem Portal kann das manuelle Visual Upgrade ziemlich lange dauern, doch zum Glück lässt es sich (wie fast alles in SharePoint 2010) über die PowerShell automatisieren:

$db = Get-SPContentDatabase <Name der Content Datenbank>
$db.Sites | Get-SPWeb -limit all | ForEach-Object {$_.UIversion = 4;
$_.UIVersionConfigurationEnabled = $false; $_.update()}

Der folgende Beitrag spiegelt unsere Erfahrungen mit der Variante der Database Migration als Migrationsart von SharePoint 2007 nach SharePoint 2010 und beleuchtet einige Eigenheiten dieser Variante. Eine Übersicht über die verschiedenen Upgrade Möglichkeiten können diesem Beitrag entnommen werden.

Für die Migration des ORAYLIS internen MOSS 2007 auf SharePoint 2010 haben wir uns für den Weg der Database Migration entschieden. Dieses Vorgehen wurde vor allem gewählt, da die Migration auch gleichzeitig genutzt werden sollte, um einige infrastrukturelle Änderungen vorzunehmen. Außerdem kann auf diese Art und Weise vermieden werden, dass Altlasten aus dem bestehenden System übernommen werden. Auch ist die Ausfallzeit des Systems bei dieser Variante am geringsten.

Einem erfahrenen SharePoint Administrator sollte das Upgrade mit Hilfe der Database Migration keine allzugroßen Probleme bereiten. Vorteilhaft ist es, wenn bereits Erfahrungen mit dem Austausch oder Umzug der Content Datenbanken gemacht wurden. Und – wie bei so vielen Aufgaben – ist auch hier die Vorbereitung das halbe Leben. Die Dokumentation von Microsoft zum Upgrade sollte gelesen und verstanden sein, genauso sollte bereits im Vorfeld ein wenig Erfahrung mit den neuen Features von SharePoint 2010 gesammelt werden.

Jedem, der die Variante der Database Migration wählt, rate ich dringend dazu, einen “Probelauf” zu machen, bevor der neue SharePoint Server live geschaltet wird. Dies ermöglicht es, die neue Umgebung ausgiebig zu testen, ohne die Endbenutzer zu beeinträchtigen.

Vorbereitung

Als erstes sollte mit Hilfe des PreUpgradeChecks (stsadm Befehl ab MOSS SP 2) überprüft werden, ob es mögliche Konflikte innerhalb der Farm gibt. Der PreUpgradeCheck nimmt keine Modifikationen an der bestehenden Umgebung vor. Aufkommende Konflikte sollten gelöst werden, bevor mit der Migration begonnen wird.

Läuft der PreUpgradeCheck ohne Probleme durch, so kann die zweite Farm aufgesetzt werden. In dieser müssen alle Anpassungen (eigene oder Third Party Features, Solutions, Webparts, Themes etc.) installiert werden, welche derzeit noch von der alten Farm verwendet werden. Alle diese Anpassungen müssen 64Bit fähig sein!

Wer längere Zeit SharePoint 2007 administriert und konfiguriert hat, der wird während der Konfiguration von SharePoint 2010 vieles wiedererkennen. Sofort ins Auge springt die Unterstützung durch einen zweiten Wizard in der Central Administration und die Service Applications. In meinen Augen sollte grade den Service Applikationen der Office Web Apps und der sogenannten “User Profile Service Application” besonders viel Aufmerksamkeit geschenkt werden.
Die “User Profile Service Application” ersetzt den Teil des Shared Service Providers, welcher früher für die Benutzerprofile und MySites zuständig war.

Die Installation und Grundkonfiguration von SharePoint 2010 unterscheidet sich nicht sonderlich von der des SharePoint 2007. Interessant wird dies erst bei der Konfiguration der Service Applications. Allerdings nimmt hier der neue Configuration Wizard in der Central Administration auch eine Menge Arbeit ab.

Language Packs

Alle Language Packs, welche im bisherigen SharePoint 2007 im Einsatz waren, müssen auch auf dem neuen SharePoint 2010 Server installiert werden.
Liegt z.B. eine Site in einer Sprache vor, für welche kein Language Pack installiert wurde, so lässt sich diese Site ohne das entsprechende Language Pack nicht öffnen!

Steht die neue Farm, so kann ein erster Probelauf durchgeführt werden. Bei diesem “Probelauf” wird die neue SharePoint 2010 Farm bereits vollständig konfiguriert und eingerichtet. All diese Einstellungen müssen bei der Übernahme der endgültigen Content Datenbank nicht erneut vorgenommen werden, diese bleiben erhalten.

Datenbank Migration

Als erstes müssen die alten Inhaltsdatenbanken auf dem neuen SQL Server wiederhergestellt werden. Dies kann einfach mit Hilfe der Backup und Restore Funktionalität des SQL Servers erfolgen.

Über die Central Administration muss zunächst eine neue Web Applikation erstellt werden, in welcher später das Portal liegen soll. Bei der Erstellung der neuen Web Applikation wird auch eine neue Content Datenbank angelegt. Diese kann später wieder gelöscht werden.

Zur Sicherheit sollte an dieser Stelle noch der PowerShell Befehl “Test-SPContentDatabase” ausgeführt werden, um sicher zu stellen, dass auch tatsächlich alle erforderlichen Komponenten installiert wurden:

Test-SPContentDatabase -Name <alte Content Datenbank> -WebApplication <URL zur neu angelegten Webapplikation>

Ist auch dieser Test erfolgreich, so kann der neuen Applikation die “alte” Content Datenbank zugewiesen werden.
Wer bereits Erfahrungen mit dem Anfügen von Content Datenbanken hat, dem werden die folgenden Schritte bekannt vorkommen.

1. In der SharePoint Central Administration in den Bereich Application Management wechseln
2. Die Seite “Manage content databases” aufrufen

   

3. Nicht vergessen die neu erstellte Applikation auszuwählen

   

4. Die alte Content Datenbank entfernen

   

5. Mit Hilfe des stsadm Befehls “addContentDB” oder über die PowerShell mit “Mount-SPContentDatabase”  die neue Content Datenbank anfügen. Mit diesen Befehlen wird die Datenbank automatisch migriert. In unserer Umgebung hat die Migration einer Content Datenbank mit ca. 3,5 GB knapp 15 Minuten gedauert.
6. Überprüfen des Upgrade Status in der Central Administration:
   Central Administration –> Upgrade and Migration –> Check upgrade Status

Das ist bereits alles. Natürlich muss dieses Vorgehen für alle Content Datenbanken wiederholt werden. Sollen auch die MySites migriert werden, so muss auch der Shared Service Provider migriert werden.

Sowohl bei dem stsadm Befehl “addContentDB”, als auch beim äquivalenten PowerShell Befehl “Mount-SPContentDatabase” besteht die Möglichkeit zu wählen, ob der Content noch im alten SharePoint 2007 Style, oder direkt im neuen SharePoint 2010 Layout inklusive Ribbons angezeigt werden soll. Setzt man das Flag nicht, so wird standardmäßig das alte Layout beibehalten. Dieses kann später über das Visual Upgrade manuell geändert werden.

Reporting Services (Integrierter Modus)

Waren Reporting Services Reports vorhanden, so müssen diese neu bereitgestellt werden.

Funktionstest

Nachdem die alte Content Datenbank der neuen Applikation zugewiesen wurde, sollte das Portal aufgerufen und getestet werden. Die folgenden Punkte sollten überprüft werden:

1. Lassen sich alle Seiten öffnen?
2. Funktionieren alle Webparts?
3. Wurde das alte Layout fehlerfrei übernommen? / Wird die neue Ribbon Oberfläche angezeigt?
4. (optional) Funktionieren Reports (sowohl Reporting Services, wie auch Excel Services)?
5. (optional) Können die neuen Office Web Apps genutzt werden?
6. (optional) Funktionieren die MySites?
7. (optional) Funktioniert die Suche?

Des Weiteren sollte nun sowohl das Windows Event Log, wie auch die SharePoint Logs nach Fehlern überprüft und eine Weile beobachtet werden.

Abschluss

Waren alle Tests erfolgreich, kann die endgültige Migration durchgeführt werden:

1. die alte SharePoint 2007 Farm offline nehmen
2. ggf. erneut ein Backup der alten Content Datenbank erstellen und diese der neuen Webapplikation hinzufügen. Die Konfigurationen innerhalb der Service Applications müssen nicht neu gesetzt werden. Das Anfügen der alten Content Datenbank hat ausschließlich Auswirkungen auf die Web Applikation, zu welcher die Datenbank gehört.
3. Den neuen SharePoint Server 2010 live schalten

Fazit

Die Database Migration ist für einen erfahrenen SharePoint Administrator kein Problem. Die meiste Arbeit mach das Installieren und Konfigurieren der neuen Umgebung. Die eigentliche Migration ist im Gegensatz hierzu schnell gemacht und mit wenig Aufwand verbunden.
Desweiteren bietet Sie die optimalen Voraussetzungen für eine (zumindest für den Benutzer) sehr schnelle und unkomplizierte Umstellung. Die Database Migration ist mein absoluter Favorit und eigentlich für alle empfehlenswert, die eine schnelle, sichere und saubere Lösung bevorzugen.

Viele Unternehmen haben bereits den Microsoft Office SharePoint Server 2007 im Einsatz und stehen nun vor der Aufgabe, diesen nach Microsoft SharePoint Server 2010 zu migrieren. In diesem Beitrag werden die verschiedenen Upgrade Mechanismen vorgestellt und einige allgemeine Hinweise zum Upgrade gegeben.

Wer mit der Migration von SharePoint 2003 auf 2007 schon Erfahrung hat, dem wird es vermutlich vor dem Upgrade auf 2010 grausen. Allerdings kann ich hier bereits sagen, dass Microsoft sich sehr große Mühe gegeben hat und wirklich gute Upgrade Mechanismen entwickelt hat.

Hinweis: Eine Migration von SharePoint 2003 auf 2010 ist nicht möglich. Hier muss zuvor ein Upgrade auf 2007 erfolgen.

Vor dem eigentlichen Upgrade

Wichtig für alle Upgrade Varianten ist, dass die Systemvoraussetzungen für SharePoint 2010 erfüllt sind und dass die bisherige MOSS Installation über das Service Pack 2 verfügt.
Desweiteren sollte man mit Hilfe des “Pre-Upgrade-Checks” überprüfen, welche “Problembereiche” in der aktuellen Farm existieren.

Der PreUpgradeCheck ist ab MOSS SP2 ein Befehl des Administrationstools stsadm:

stsadm –o preupgradecheck

Nachdem dieser Befehl durchgelaufen ist wird eine übersichtliche Website angezeigt, welcher man die Ergebnisse des Checks und eventuelle Probleme (inkl. Lösungsvorschlag!) entnehmen kann.

Werden eigene (oder eingekaufte) Solutions/Features oder Webparts verwendet, so müssen auch diese 64-Bit fähig sein, oder entsprechend angepasst werden, bevor die Migration erfolgt.

Variante 1: In-Place Upgrade (Direktes Upgrade)

Das In-Place Upgrade ist wohl die “rabiateste” Methode. Hierbei wird der neue SharePoint 2010 über den bereits existierenden SharePoint 2007 installiert.
Wichtig bei diesem Vorgehen ist, dass auf allen beteiligten Servern die Systemvoraussetzungen bereits erfüllt sind. Sollte die bestehende Umgebung noch nicht auf 64-Bit implementiert sein, so muss vor dem Upgrade auf SharePoint 2010 eine Migration auf 64-Bit erfolgen (gleiches gilt natürlich auch für Windows Server 2008 und die SQL Server Komponenten).
Sind alle Voraussetzungen erfüllt, so sollte die Farm noch einmal mit dem “Pre-Upgrade-Check” überprüft werden.

Ist der “Pre-Upgrade-Check” erfolgreich durchgelaufen, so kann mit dem Upgrade begonnen werden.

Das Upgrade muss in einer bestimmten Reihenfolge erfolgen. (Zuerst auf dem Server, auf dem die Central Administration installiert ist. Konfigurationsassistenten nicht ausführen, bevor das Upgrade nicht auch auf allen Front-End-Webservern ausgeführt wurde!)

Da in SharePoint 2010 kein Shared Service Provider mehr existiert, wird dieser während des Upgrade Prozesses in einzelne Service Applikationen “zerlegt”. Somit werden auch diese Einstellungen übernommen. Die so angelegten Service Applications sollten jedoch genau auf die richtigen Einstellungen und ihre Funktion überprüft werden.

Nach dem Upgrade erscheint das neue Portal zunächst im alten SharePoint 2007 Layout. Dieses kann mit Hilfe des Visual Upgrades auf die neue Ribbon Oberfläche umgestellt werden. Sehr schön bei diesem Vorgehen ist auch die “Vorschau” Funktion. So kann die neue Oberfläche erst für Administratoren zur Verfügung gestellt werden und diese können dann entscheiden, wann das Upgrade auch an den Endanwender weitergegeben wird.

Für wen ist das In-Place Upgrade geeignet?
Meiner Meinung nach ist das In-Place Upgrade nur geeignet, wenn es sich um eine kleine Serverfarm handelt und wenn die bisherige Architektur übernommen werden soll. Es ist auf jeden Fall ratsam, sich für das In-Place Upgrade professionelle Hilfe zu holen, da dieses das Risiko birgt, die komplette Farm zu “verlieren”.

Variante 2: Database Migration (Upgrade mit Anfügen der Datenbanken)

Die Variante der Database Migration ist in meinen Augen die sanfteste und sicherste Variante, ist jedoch gleichzeitig auch ressourcenintensiv.

Bei der Database Migration wird neben der existierenden Farm eine neue Farm aufgebaut (daher ressourcenintensiv). Diese ist vollkommen unabhängig von der bisherigen SharePoint 2007 Farm. Auch hier gilt: erst alle Voraussetzungen erfüllen, bevor SharePoint 2010 installiert wird. Auch sollten vor dem Umzug der alten Inhaltsdatenbanken unbedingt alle eigenen Features/Solutions installiert werden. Wichtig ist hierbei z.B. auch das eigene Theme.
Steht der neue SharePoint, dann können die alten Inhaltsdatenbanken der neuen Farm hinzugefügt werden (entweder über die Power Shell, oder über den altbekannten stsadm Befehl “addcontentdb”)

Auch nach der Database Migration erscheint das neue Portal zunächst im alten Layout. Dies kann mit Hilfe des Visual Upgrades angepasst werden.

Für wen ist die Database Migration geeignet?
Die Database Migration ist vor allem für Umgebungen mit sehr vielen und sehr großen Datenbanken geeignet, da hierbei das Upgrade der Datenbanken parallel geschehen kann. Außerdem ist diese Variante auch für alle zu empfehlen, deren Endanwender so wenig wie möglich von der Migration beeinflusst werden sollen. Während man beim In-Place Upgrade die Farm bis zur Vollendung des Upgrades offline nehmen muss, können bei der Database Migration beide Farmen parallel laufen, bis es zur eigentlichen Datenübernahme kommt.

Variante 3: Hybrid Variante

Die Hybrid Variante ist eine Kombination aus dem In-Place Upgrade und der Database Migration.

Die Hybrid Variante selbst teilt sich noch einmal in zwei unterschiedliche Methoden:

Methode 1:
Während des Upgrade Vorgangs wird weiterhin schreibgeschützter Zugriff auf die Inhaltsdatenbanken gewährt, während das Upgrade in einer anderen Farm ausgeführt wird.

Methode 2:
Die Möglichkeiten des In-Place Upgrades werden genutzt, um die Farm zu migrieren, jedoch werden die Datenbanken hierbei nicht migriert. Erst nach dem Upgrade werden die Datenbanken nach dem Verfahren der Database Migration getrennt, aktualisiert und wieder neu angefügt. Somit ist ein paralleles Upgrade der Datenbanken möglich.

Die Hybrid Variante vereinigt somit alle Vor- und Nachteile der In-Place und der Database Migration Variante.

Fazit

Egal für welche Methode man sich entscheidet, alle erfordern einiges an Planung, Vorbereitung und auch Nachbereitung (Beobachtung der Logfiles, evtl. Fehlerbehebung). Microsoft hat sehr viel Arbeit in die neuen Upgrade Mechanismen investiert, viel dokumentiert und vor allem viel Unterstützung geliefert. Dennoch sollte das Upgrade nur von erfahrenen SharePoint Administratoren durchgeführt werden, da es doch immer wieder kleine Stolperfallen gibt.

In meinem nächsten Post werde ich von den Erfahrungen berichten, die wir während des Upgrades auf SharePoint 2010 gemacht haben und etwas detaillierter auf die Variante der Database Migration eingehen.