Heute an den TechDays 2010 in Basel habe ich meinen Kollegen Stefan Gohr wieder einmal gesehen. Wir diskutierten über die diversen Probleme der SharePoint Server 2010 Beta und der MySite. Stefan erzählte mir von einem Problem, bei dem der User Profile Synchronization Service nicht zum Laufen gekommen ist. Obwohl er all hier gebloggten Tipps beachtet hat. Ich hatte dieses Problem in einem Fall ebenfalls. Ich hatte aber zufällig einen Workaround gefunden. Da mich bisher niemand auf dieses Problem darauf angesprochen hat, bin ich davon ausgegangen, dass dieses Problem nur bei mir aufgetreten ist. O.K. ein bisschen blauäugig. Hier aber mein Vorgehen:

1: Der User Profile Synchronization Service muss natürlich aktiviert sein. Dies passiert in der Central Administration (Central Administration System Settings -> Manage Services on Server -> User Profile Synchronization Service).

2: In einer Cmd-Shell löscht man dann die bestehende Datenbank:

stsadm -o sync -deleteolddatabases 1

Danach sollte der Profile Service starten.

Wir hatten das Problem, mit einem älteren Server auf welchem wir Citrix Xen Server installiert hatten und dort diverse VMs. Da wir aber nun auf ESXi umstellen wollten, kam die Frage auf, wie wir diese VM’s auf den ESXi kriegen.

Logischerweise testete ich dies mit dem VmWare vCenter Converter und dem VizionCore Free – vConverter SC. Bei beiden Produkten funktionierte dies leider nicht “Out-of-the-Box”, da Windows 2008 R2 wie auch Windows 7 eine 100MB grosse versteckte Partition erstellen und diese nicht migriert wird. Nach einigen Recherchen im Internet habe ich Anleitungen gefunden wie dies gehen soll. Nur sind die meines erachtens ziemlich kompliziert und es werden diverse Tools und Vorarbeiten benötigt.

Nach einigen Tests habe ich nun eine relativ einfache und effiziente Methode gefunden um eine Hot-Migration durchzuführen.

Die Tools welche ich eingesetzt habe sind folgende:

• VizionCore Free – vConverter SC
• VizionCore VA Appliance
• Windows 7 Recovery Disk 64-Bit welche von Neosmart bereitgestellt wird

Das Vorgehen:

Vorbereiten des ESXi

1. Installation und Konfiguration des ESXi
2. Importieren der VA “http://www.vizioncore.com/downloads/vConverter/VA/Esx VA 1.0.17.ovf”  über den vSphere Client
3. Konfigurieren der Appliance gemäss der Anleitung von VizionCore

Vorbereitung des Quellservers:

1. Zuerst habe ich die Xen Tools deinstalliert
2. Danach den Server welchen ich migrieren wollte mal sauber neu gestartet.
3. Der versteckten 100MB Partition vom Server einen Laufwerksbuchstaben zugeordnet (F:)
4. Danach Dienste heruntergefahren welche zu einer Inkonsistenz führen könnten (SQL, Exchange, etc.)

Migration des Servers

1. Starten des vConverters
2. Auswahl des Servers welchen ich migrieren und eine Konvertierungsaufgabe erstellt
3. Alle Volumen ausgewählt, bei den erweiterten Einstellungen den Adaptertyp auf LSI gestellt und natürlich, dass er den Quellserver nach der Konvertierung herunterfahren soll.
4. Migration starten und warten…..

Hochfahren auf dem ESXi und Patchen des migrierten Servers

1. Nachdem die Konvertierung fertiggestellt ist, muss man die VA von Vizioncore auf dem ESXi herunterfahren, da diese sich die Festplattendateien anhängt und sich die neue VM so nicht starten lässt.
2. Einstellungen der VM anpassen:
   - die Standardeinstellungen überprüfen (Servername, Arbeitsspeicher, etc.)
   - den SCSI Controller auf LSI Logic SAS umstellen
   - den Netzwerkadapter auf E1000 stellen (löschen und neu hinzufügen)
   - bei den “Allgemeinen Optionen” das Gastbetriebssystem auf “Microsoft Windows Server 2008 R2 (64-Bit)” umstellen
   - Zum Schluss die Windows 7 Recovery Disk 64-Bit in das CD-Rom einlegen oder mounten (Häckchen “Beim Einschalten verbinden” nicht vergessen)
3. Die VM hochfahren und ab der DVD starten.
4. Die Recovery Disc erkennt nun, dass etwas mit dem Boot-Record nicht stimmt und will dies korrigieren.
5. Reparatur des Boot-Records und neustarten.
6. Nochmals ab CD starten, da nun zwar der Server starten will aber im berüchtigten 7B Bluescreen endet. Daher nochmals ab der CD-starten.
7. Das Windows 7 Recovery System will nun noch mehr reparieren, kann dies aber nicht durchführen und bringt eine Auswahl mit diversen Reparatur möglichkeiten. An diesem Punkt “Command Prompt” auswählen.
8. Regedit eintippen
9. HKEY_Local_Machine auswählen und auf “File –> Load Hive” gehen
10. Dort auf die System Partition (D:) gehen, Windows\System32\Config und dort System auswählen.
11. Bei der Frage nach dem Namen habe ich p2v eingetragen
12. Nun den Eintrag p2v suchen unter HKLM und zu ControlSet001\Services\LSI_SAS navigieren und den REG_DWORD Wert von Start von 3 auf 0 setzen
13. wieder auf p2v klicken und auf “File –> unload Hive”
14. nun die VM nochmals neu starten und hochfahren lassen
15. VmWare Tools installieren neu starten
16. Testen, ob alles funktioniert und Windows erneut aktivieren

Die neuesten Beta Bits auf Microsoft Connect lassen sich zwar auf einem Domänen Controller installieren. Allerdings ist die Farm Option nicht mehr verfügbar. Das heisst, man kann den SharePoint 2010 Server nur noch in der Standalone Version installieren. Für Test- und Demoumgebungen wäre genau das aber wünschenswert. Mit einem kleinen Umweg geht es aber trotzdem:

1: Zuerst das von Connect heruntergeladene Installationsfile (.exe) auf dem Domänencontroller extrahieren. Dies geschieht durch den Befehl:

OfficeServer_none_ship_x64_de-de.exe /extract:c:\Install

2: Im erstellten Ordner befindet sich die Applikation „PrerequisiteInstaller.exe“. Mit diesem kann man die für SharePoint Server 2010 nötigen Bits auf dem Domänencontroller installieren.

3: Wenn das geschehen ist, sucht man ebenfalls in dem erstellten Ordner, den Ordner „Files“ und dort den Ordner „SetupFarm“. Darin befindet sich die Datei config.xml. Dieser Datei fügt man die eigene SharePoint 2010 Server Seriennummer hinzu.

4: Nun kann man den extrahierten Installer mit dieser Config-Datei ausführen:
setup.exe /config \Install\files\setupfarm\config.xml

Der Installer läuft nun durch bis man zum SharePoint Configuration Wizard kommt. Dabei wurde SharePoint Server 2010 Beta im Farmmodus installiert und konfiguriert.

Wer Groove und/oder SharePoint Workspace 2010 kennt, kennt auch das Problem das in der Kommunikation immer wieder Datenpakete hängen bleiben.

Bei der Groove 2007 Version gab es das Tool grooveclean.exe. In der aktuellen Beta-Version ist dieses Tool direkt in der Groove.exe untergebracht. Um das 2010 Pendant von grooveclean.exe zu haben geht man folgendermassen vor:

1: In der cmd-Box navigiert man zu C:\program files\microsoft office\office14

2: groove.exe /clean

Der frühere Befehl “grooveclean –all” heisst nun neu „groove.exe /clean /all“. Aber Achtung, dieser Befehl löscht nebenbei das eigene Konto wie auch alle Workspaces komplett!!!

PS: In der Groove 2007 liegt das Tool unter: C:\Program Files\Microsoft Office\OFFICE12\GrooveClean\

Die Integration von Cloud Speicher in das lokale OS ist immer wieder ein Problem. Jeder Anbieter bringt entweder eigene Software, oder ist nur über ein Webinterface zu erreichen. Zum Thema Skydrive habe ich vor ein paar Monaten das Tool SkyDrive Explorer entdeckt. Jetzt hat mich jemand auf ein noch intelligenteres Tool aufmerksam gemacht. Cloud Desktop 2 von Gladinet verzahnt diverses Cloudservices direkt in den Windows Explorer. Unterstützt wird nicht nur SkyDrive sondern eine Vielzahl von Anbietern. Diese können via vordefinierte Module in das OS integriert werden.

Die so integrierten Anbieter werden unter einem Netzwerklaufwerk als separate Ordner angezeigt. So kann man verschiedene Cloudservices parallel gemounted haben. Die Cloudservices können so in jeder Applikation durch den Speichern- oder Öffnen-Dialog angesprochen werden.

Zusätzlich bietet das Tool aber auch die Möglichkeit Backupszenarien auf die Cloudspeicher einzurichten. Dazu bietet das Cloud Desktop ein eignes Interface. In diesem können die notwendigen Schritte vorgenommen werden.

Cloud Desktop 2 ist in der Basisversion gratis. Eine Pro Version muss bezahlt werden. Diese unterstützt diverse Cache-Mechanismen, Komprimierungen und für gewisse Anbieter ACL-Unterstützung.

Diese Woche haben wir uns ganz dem Thema SharePoint Migration gewidmet, da dieses Thema schon jetzt aktuell bei unseren Kunden ist. Migriert haben wir eine Office SharePoint Server 2007 Umgebung nach SharePoint Server 2010 (Beta). In diesem Artikel beschreiben wir die Ausgangslage und unser Vorgehen sowie ein Fazit über den gesamten Migrationsprozess. 

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.

 

Eine der neuen Funktion in SharePoint 2010 Server ist die Möglichkeit innerhalb von Dokumentenbibliotheken nach vordefinierten Metadaten zu filtern.  Wenn man sich ein neues Term Set und Terms erstellt hat, sind die Metadaten Terms nicht  in den Metadaten-Navigationseinstellungen vorhanden.

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.

Beim Aufsetzten einer neuen SharePoint Server 2010 Farm, ist mir ein aufgefallen, dass einige der Benutzer statt des Preferred Name den Account Name eingetragen haben. Dies manifestiert sich insbesondere beim Benutzermenü oben rechts:

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.

In der nächsten Woche werde ich mich mit meinen MVP-Kollegen in Redmond, am MVP-Summit, austauschen. Danach geht es aber direkt zurück nach München an die SharePoint Konferenz 2010. Ich hoffe ich werde einige von Euch dort treffen und hoffentlich in meinen zwei Sessions sehen.

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.

Nun, da ich jetzt auch einer von denen bin die Outlook 2010 Beta bei der täglichen Arbeit einsetzen, stolpere ich immer wieder über Rätsel. Eines dieser Rätsel war wie man die SharePoint Meeting Workspace Site in Outlook 2010 Beta einrichtet.
Hier meine Erkenntnisse.

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.