Ausgangslage

Beide SharePoint Umgebungen laufen virtualisiert auf dem Produkt Virtual Box , welches dank einer Gratislizenz kostenlos benutzt werden kann. Als Hostsystem verwenden wir ein Windows 7 64 Bit Ultimate mit 6 GB RAM. 

Migrationsvorbereitung 
Als Unterstützung haben wir folgende Dokumente verwendet welche von Microsoft Technet zur Verfügung gestellt werden. Da SharePoint 2010 (Beta) erst vor kurzem Veröffentlicht wurde sind dies die einzigen nützlichen Dokumente, welche über die Migration von Office SharePoint Server 2007 zu SharePoint Server 2010 (Beta) zu finden waren. Referenzieren möchten wir daher nur auf die folgenden Dokumente: 

• Upgrade_Planning_SharePointProducts
• Upgrade_Approaches_SharePointProducts
• Upgrade_Testing_SharePointProducts

Die Dokumente können hier heruntergeladen werden. 

Migrationsablauf 

In den von Microsoft publizierten Dokumenten wird die Migration aus drei Sichtweisen (Planung, Vorgehen und Testen) beschrieben. Zusätzlich möchten wir Euch eine detailliertere Anleitung zur Verfügung stellen. Grundsätzlich gehen wir von folgendem Ablauf aus um eine Migration erfolgreich durchführen zu können. 

1. Vorbereitung Testmigration
2. Testmigration durchführen
3. Vorbereitung Migration Liveumgebung
4. Information an die Anwender da ohne Unterbruch nicht möglich
5. Durchführung der Migration Liveumgebung
6. Test der migrierten SharePoint Umgebung
7. Freigabe an die Anwender

Mit dem Befehl stsadm –o preparetomove müssen die Datenbanken von SharePoint 2007 vorbereitet werden.  Dieser Befehl terminiert laufende Profil und Membership Synchronisation Services, damit die Datenbanken sicher migriert werden können.

Alle Content Datenbanken sowie die Profil Datenbank welche die Informationen wie Skills usw. beinhaltet, werden für die Migration vorbereitet.

 

  

Content Datenbanken Migration durchführen

• Content Datenbanken
• Content Profil Datenbank

Nicht betroffen sind: 

• SharePoint Config DB
• Central Administration DB
• Alle Search Datenbanken

 

Schritt 2: Kopieren der Datenbank-Files 

Standardmässig werden die SQL Server 2005 Datenbank Files im Verzeichnis C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data abgelegt. Nun gilt es die Files *.mdf und *.ldf der Content Datenbanken in die Struktur C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA auf dem SQL Server 2008 mit SP1 (Kumulatives Update 2) zu kopieren. 

Schritt 3: Verbinden der Datenbanken an die neue Farm 

Über den Befehl stsadm –o addcontentdb –url http://portalname –databasename WSS_Content_xxx müssen nun alle bestehenden Content Datenbanken verbunden werden. Hier ist zu beachten, dass je nach Grösse der Datenbank der Vorgang lange dauern kann. 

Das Verbinden der Datenbanken ist nur erfolgreich, resp. ohne Fehler, wenn Languagepacks und Solution mit der alten SharePoint Farm übereinstimmen. Ansonsten erscheinen im Log Errors welche auf die fehlenden Features hinweisen. Das LOG ist sehr detailliert und übersichtlich, so dass schnell die Ursache des Problems gefunden werden kann. Das Verbinden der Datenbanken funktioniert jedoch trotzdem auch wenn Languagepacks und Solutions nicht vorinstalliert wurden.

Im Verzeichnis C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\LOGS wird das Upgrade Log geschrieben.

 

Nach der Migration

Visual upgrades:

Die nun migrierten SharePoint Seiten, werden im alten Office SharePoint Server 2007 „look and feel“ angezeigt. Über „Site Actions“ kann ein „Visual upgrade“ durchgeführt werden, welche die MasterPage „v4.master“ für das neue SharePoint UI aktiviert. Das Upgrade über das Web-Interface funktioniert perfekt, jedoch muss man so alle Sites einzeln und manuell anpassen. Damit nicht alle einzeln angepasst werden müssen, gibt uns ein PowerShell Script welches diese Operation für alle Sites einer Sitecollection durchführt.

Referenz: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=173

$db = Get-SPContentDatabase WSS_Content_SharePoint_2007

$db.Sites | Get-SPWeb -limit all | ForEach-Object {$_.UIversion = 4;

$_.UIVersionConfigurationEnabled = $false; $_.update()}

 

Test Checkliste

 

Nach der Migration sollten folgende Punkte überprüft werden:

• WebParts

Funktionieren die WebParts korrekt?

• Layout

Werden angepasste Seiten weiterhin richtig angezeigt?

• Berechtigungen

Haben die berechtigten Personen weiterhin Zugriff auf die entsprechenden Seiten?

 

Fazit

Wichtig ist eine genaue und detaillierte Vorbereitung der Migration so dass Probleme schon frühzeitig erkannt und behoben werden können. Damit die Testmigration auch erfolgreich abläuft ist das Vorinformieren auf der Technet Seite zwingend notwendig. Ansonsten verzettelt man sich schnell und erhält zum Schluss keine eindeutige Aussage ob ihre SharePoint Umgebung migrierbar ist. Ein spezielles Augenmerk ist auf die Master Seiten zu legen. Denn mit dem neuen UI wird eine separate Master Page „v4.master“ aktiviert. Oder man verzichtet auf das neue Ribbon UI von SharePoint 2010 und behält die bestehende Master Page.

Planung ist die halbe Miete. Darum bereiten Sie sich jetzt schon auf die kommende Migration vor.

 

In der aktuellen SharePoint Server 2010 Beta Version braucht es noch ein paar Schritte um den Filter zu aktivieren. Bei dieser Beschreibung sind die Terms schon erstellt.
Als erstes muss in der Site Collection, in der man den Filter haben möchte, das entsprechende Site-Feature (Metadata Navigation and Filtering) aktiviert werden

In der Quick Nav Leiste erscheint nun das entsprechende Filter Web Part. Allerdings kann man in den Site Settings  das erstellte Metadata Term Set nicht hinzufügen, da es nicht vorhanden ist.

Um sein Term Set in den Metadata Navigation Settings auswählen zu können, muss in der Dokumente Bibliothek eine Spalte des Types „Managed Metadata“ vorhanden sein. Diese kann wie in der Site Settings wie in MOSS hinzugefügt werden. Wenn man den Typ „Managed Metadata“ auswählt, kann man weiter unten bei „Term Set Settings“ das erstellte Term Set auswählen.

Sobald die Spalte vorhanden und einer Sicht zugewiesen wurde, kann man das Term Set der Navigation hinzugefügt werden.

Danach sollte das Term Set im Filter Web Part erscheinen und auch funktionieren.

Damit dem Benutzer der Metadaten Browser zur Verfügung steht, ist ebenfalls dieses Vorgehen anzuwenden.

PS: Eine kleine Einführung in Metadaten und Keywords von Microsoft SharePoint Server 2010 gibt es in diesem Artikel.

Dies passiert bei der aktuellen Beta Version wenn die Synchronisation der Site Collection mit dem Profile Store stoppt. Wie man dieses Problem löst, hat mir Mike Oryszak am MVP Summit 2010 verraten. Die Datenbank kann mit dem Befehl:

stsadm -o sync -deleteolddatabases 1

gelöscht und neu aufgebaut werden. Der Prozess standardmässig alle zwei Stunden, wenn die DB aber korrupt ist, bleibt sie korrupt.

Für diejenigen, die sich gerade die Agenda zusammenstellen hier ein bisschen Werbung in eigener Sache. Meine erste Session am Mittwoch ist wie der „Fuzzy Tail“ eine Motivation Session die aufzeigt, dass man sich einen Schritt weiter getrauen sollte. Die Verbindung von interdisziplinärem Wissen in seine SharePoint-Search-Architektur ist ein Muss. Dieses Wissen lässt einem einige Fehler erst gar nicht machen und bringt so deutlich mehr Benutzerakzeptanz und Nutzen.
Die Session trägt den Titel „Wege in die digitale Unordnung“ und zeigt die Problem die mach sich mit den neuen SharePoint Server 2010-Funktionen, wie Metadaten und Keywords schaffen kann. Architekten die SharePoint-Suchportale erstellen und betreiben stoßen irgendwann auf die Aufgabe dem Inhalt des heterogenen Datenkorpus eine Struktur zu geben. Dabei entsteht eine Ordnung  in Kategorien. Diese Ordnung kommt aber ins Wanken. Unser Denken kommt mit festen Kategorien nicht weiter. Wir müssen lernen Chaos, Unordnung und Unschärfe abzubilden.  Die Session schlägt den Bogen von den Bibliothekaren die vor 200 Jahren dieses Problem schon angegangen sind, bis zu Tim Berners-Lee der das Problem mit seinem Entwurf vom Semantic Web lösen möchte. Dabei wird der geschichtliche Exkurs mit aktuellen SharePoint-Search-Beispielen verglichen. So wird dem Zuhörer klar, dass man Modelle, die vor 200 Jahren nicht funktioniert haben, heute nicht anwenden soll. Stattdessen werden die neusten Ideen auf ihre Machbarkeit in SharePoint überprüft.

Die zweite Session mit dem Titel „Metadaten in SharePoint Server 2010“ zeigt die die neuen Management Funktionen  von SharePoint Server 2010 wie Document Sets, Location-based metadata, metadata navigation, metadata filtern und Document IDs. Ein besonderes Augenmerk wird auf die neuen „managed metadata“ von SharePoint 2010 gelegt.  Die Session zeigt wie man diese konfiguriert, indexiert und für eine optimierte Suche verwendet. Einen ausführlichen Post zu diesem Thema habe ich bereits früher hier geschrieben.

Ich freue mich wieder in München zu sein und hoffe es wird so lustig wie letztes Mal.

In den Outlook Optionen gibt es den Punkt Menüband anpassen.

Wenn man in der ersten Spalte „Alle Befehle“ auswählt findet man den Befehl „Besprechungsarbeitsbereich“. Es ist aber nicht möglich diesen Befehl einem bestehenden Ribboneintrag hinzuzufügen (so wie es in Outlook 2007 möglich war). Neu muss man sich einen eigenen Reiter erstellen. Im rechten unteren Bereich kann man sich dann eine neue Registerkarte erstellen. Innerhalb dieser Registerkarte muss dann der Befehl in einer Gruppe untergebracht werden.  Diese Gruppe kann ebenfalls hier erstellt werden. Sobald diese Vorbereitungen gemacht worden sind, kann man sich endlich den Befehl hinzufügen.

Falls jemand einen besseren Weg kennt, lasst es mich wissen.

Diese Tendenz, der Ordnung und Management über Metadaten zu organisieren, spiegelt sich auch in „File Classification Infrastructure“ die mit dem Windows Server 2008 eingeführt wurde. In der Zukunft werden wir vermutlich noch einheitlichere Klassifizierung von Daten antreffen.

Nun, wie funktioniert der „Managed Metadata Service“ und wo ist der Unterschied zwischen einem Term und einem Keyword? Wenn man den Managed Metadata Service editiert,

stösst man auf das „Term Store Management Tool”. Die Microsoft SharePoint Lingo verwirrt ein bisschen, aber die Metadaten werden als Terms bezeichnet. Ein Term kann ein Wort oder mehrere Wörter sein die irgendeinem Objekt innerhalb von SharePoint 2010 als Metadaten angehängt sind. Diese Wörter nennt man Labels.

Ein Term kann mehrere Labels haben. Im Beispiel oben ist zum Beispiel die Abkürzung von Januar (Jan.) ein anders Label des ursprünglichen Labels (Januar) des Terms. Wenn ein Benutzer nun bei den Metadaten zu schreiben beginnt werden sowohl „Januar“ als auch „Jan“ angeboten:

Was immer der Benutzer nun sucht (Januar oder Jan.), wird nun gefunden.

Terms werden in Termsets organisiert. Diese Organisation fürht zu einer Art Hierarchie. Terms können im „Term Store Management Tool” in mehreren Sprachen erfasst werden. In diesem Artikel ist beschrieben wie man die Mehrsprachigkeit in SharePoint Server 2010 Beta aktiviert.
Terms werden normalerweise von einem Administrator angelegt und organisiert (Closed Term Set). Obwohl man auch zulassen kann, das Benutzer sich die Terms selber anlegen können (Open Term Set).

Die zweite Gruppe von Metadaten sind die Keywords. Diese sind für die freie Verwendung durch die Benutzer gedacht. Im Gegensatz zu den Terms haben sie keine Hierarchie sondern sind eine flache Liste (Keyword Set). In SharePoint Server 2010 haben viele Content Typs bereits als Standard Objekte mit Keywords. Im Gegensatz zu Terms können Keywords nicht übersetzt werden. Keywords werden aber bei ihrer Erstellung überprüft ob sie nicht schon vorhanden sind.

Ebenso kann man in SharePoint 2010 Server mehrere „Managed Metadata Services“ anlegen. Diese werden“ Hosts“ genannt. Im Gegenzug kann eine Web Applications mehrere „Managed Metadata Services“ als Quelle haben, dies kann lokal oder auf einer anderen Farm sein. Somit sind Szenarien möglich in denen man für das ganze Unternehmen globale Terms definiert, trotzdem kann jede Untergruppe zusätzliche eigene Terms definieren. Für den Benutzer ist die Auswahl transparent, da die beiden Termstores addiert angezeigt werden.

Nun ja, ziemlich verwirrend. Hier noch einmal eine Zusammenfassung zur Klärung:

PS: In der Deutschen Übersetzung wird das „Term Store Management Tool“ mit „Laufzeitspeicher-Verwaltungstool“ übersetzt. Wer also die Metadaten Verwaltung sucht, sollte diesen Übersetzungsfehler beachten.

Allerdings steht jede weitere Sprache im „Term Store Managment Tool“ nicht zur Verfügung.

Damit dies funktioniert, muss auf der obersten Ebene (Managed Metadata Service) ein Term Store Administrator eingetragen sein.

Und schon kann man die weitere Sprache auswählen und die Terms können übersetzt werden.

Das Artefakt „i:0#.w|“ wird vermutlich ein Beta-Ding sein, da ähnliche Artefakte (c:0(.sltrue) an anderen Orten im Zusammenhang mit authentifizierten Benutzern auftauchen.

Nina Wilhelm hat sich dazu Gedanken gemacht und uns die Vorschläge präsentiert. Um es kurz zu machen, wir sind begeistert. Trotzdem möchten wir von Euch auch ein paar Feedbacks haben. Also los, sagt uns ob Nina mit diesen Vorschlägen auch Euern Geschmack trifft und was wir sonst noch an der Seite verbessern könnten!

Home

Beitrag

Suche

Der SkyDrive Explorer verhält sich genau so wie der Windows Explorer. So kann man dann auch Operationen ausführen, die mit SkyDrive vorher gar nicht möglich gewesen sind. Wie etwa Ordner mit Unterordner hochladen, Dokumente umbenenen oder ganze Ordner mit dem gesammten Inhalt löschen. Eine weiter „coole“ Funktion findet man im Kontextmenü von SkyDrive-Objekten. Von diesen kann man die URL kopieren, um sie per Chat oder E-Mail weitergeben kann.

SkyDrive Exploer ist als Freeware in 32- und 64Bit-Versionen erhältlich

Das .thmx-Formt wurde eingeführt um Designs und Styles zwischen Office Programmen auszutauschen. Das Format kann verschiedene Aspekte exportieren:

•    Designfarben (12 Farben)
•    Designschriften (2 Schriften)
•    Designeffekte (1 von 20 auswählen)

Beim Import in SharePoint Server 2010 werden allerdings nur die 12 Designfarben und die Schriften importiert. Der Import findet über die Themes Gallery statt (servername/_catalogs/theme/Forms/allitems.aspx).

Nach dem Upload steht dann das Theme innerhalb der Site zur Verfügung.

Wer sich das Theme ganz genau anpassen möchte, kann das über den Theme Builder Beta von Microsoft machen. Das vormalige Codeplex-Projekt kann man nun unter Microsoft Connect herunterladen.