SharePoint 2013: Distributed Cache aktuell halten

Der Distributed Cache Dienst (AppFabric) spielt in SharePoint 2013 eine sehr wichtige Rolle und entgegen früherer Aussagen von Microsoft, er würde zusammen mit SharePoint aktuell gehalten, ist man selbst für die Aktualität verantwortlich.

Ich beziehe mich hier auf diesen Beitrag von Wictor Wilén. Er beschreibt dort sehr ausführlich die genauen Schritte und auch warum etwas wie gemacht werden sollte. Als persönliche Referenz fasse ich hier nur in aller Kürze die notwendigen Schritte zusammen. Dabei beziehe ich mich auf das derzeit aktuelle CU5, das hier heruntergeladen werden kann.

Schritt 1: Distributed Cache anhalten. Das geht in der SharePoint Management Shell so:

Stop-SPDistributedCacheServiceInstance -Graceful

Schritt2: Das Update installieren. Dazu einfach die heruntergeladene Datei durch Doppelklick starten.

Schritt 3: Eine kleine Anpassung in der Konfigurationsdatei. Dazu Notepad (oder einen anderen Editor) als Administrator starten und diese Datei öffnen:

Program Files/AppFabric 1.1 for Windows Server/DistributedCacheService.exe.config

In diese Datei fügt man irgendwo innerhalb von <configuration> … </configuration> folgendes ein:

<appSettings>
  <add key="backgroundGC" value="true" />
</appSettings>

Schritt 4: Distributed Cache wieder starten. Das geht ebenfalls in der SharePoint Management Shell:

$svc = Get-SPServiceInstance | ? { $_.TypeName -eq "Distributed Cache" -and $_.Server.Name -eq $env:computername }
$svc.Provision()

Diese Schritte müssen nacheinander auf allen Servern der SharePoint Farm ausgeführt werden, auf denen der Distributed Cache läuft.

Eine Assembly in den GAC bringen beim Windows Server

Da ich mich immer wieder darüber ärgere, daß es seit einigen Versionen von Windows Server nicht mehr so einfach ist, eine Assembly (.dll) in den GAC zu bringen, hier eine kurze Notiz wie man das mit PowerShell erledigen kann. Früher ging das mal ganz einfach per Drag&Drop im Windows Explorer…

Eine Assembly dem GAC hinzufügen:

[System.Reflection.Assembly]::LoadWithPartialName("System.EnterpriseServices")
$publ = New-Object System.EnterpriseServices.Internal.Publish
$publ.GacInstall("C:\temp\MyAssembly.dll")

Wenn die Assembly im IIS benütigt wird, z.B. weil man es mit SharePoint zu tun hat, braucht es noch einen iisreset.

Wenn man eine Assembly wieder aus dem GAC entfernen möchte:

[System.Reflection.Assembly]::LoadWithPartialName("System.EnterpriseServices")
$publ = New-Object System.EnterpriseServices.Internal.Publish
$publ.GacRemove("C:\temp\MyAssembly.dll")

Zum Entfernen braucht es also tatsächlich die Assembly im Dateisystem. Wenn man sie dort nicht hat, kann man sie mit dieser Zeile aus dem GAC kopieren:

dir C:\Windows\Assembly –Recurse –Filter "MyAssembly.dll" | foreach { copy $_.FullName C:\temp }

Inhaltsdatenbank von SharePoint 2010 nach 2013 migrieren

Dieser Beitrag beschreibt, wie man eine Inhaltsdatenbank von SharePoint 2010 nach SharePoint 2013 migriert und welche Probleme dabei im Bezug auf die Authentifizierungsmethode auftreten können. Es geht dabei wirklich nur um die Vorgehensweise beim Migrieren einer Inhaltsdatenbank. Beim Planen und Durchführen einer kompletten Migration ist wesentlich mehr zu beachten! Hier finden sich dazu ausführliche Informationen bei TechNet.

Ich habe diesen Prozeß bereits einige Male gemacht, mußte aber immer wieder Kleinigkeiten z.B. zur genauen Syntax der PowerShell-Cmdlets nachschlagen. Es handelt sich hierbei also durchaus auch um eine Nachschlagemöglichkeit für mich selbst.

Datenbankbackup auf dem alten System

Zunächst wird die Inhaltsdatenbank vom alten zum neuen System verschoben. Es gibt dazu mehrere Möglichkeiten, aber die einfachste dürfte in den meisten Fällen Backup und Restore sein. Dazu verwendet man z.B. das SQL Management Studio. Weil es in diesem Blog in erster Linie um SharePoint und nicht um SQL Server geht, werden die einzelnen Schritte hier nur kurz erläutert.

Wenn man ein Backup einer Inhaltsdatenbank erstellen möchte, sollte man verhindern, daß ein SharePoint-Prozeß während des Backups in die Datenbank schreibt. Dazu kann man entweder die Verbindung zwischen SharePoint und SQL Server kappen oder den oder die SharePoint-Server herunterfahren oder ganz einfach die Datenbank auf read-only setzen. Natürlich kann in dieser Zeit kein SharePoint-Benutzer mit den Daten dieser Datenbank arbeiten.

Um eine Datenbank read-only zu machen, klickt man im SQL Management Studio mit der rechten Maustaste darauf und dann auf Properties. Die entsprechende Einstellung findet sich hier unter Options:

Jetzt kann man durch Rechtsklick > Tasks > Back Up… ein Backup der Datenbank erstellen. Dabei ist im Grunde nichts Besonderes zu beachten. Der Dialog kann z.B. so aussehen:

Falls die Benutzer mit dem alten System weiterarbeiten sollen, z.B. weil es sich nur um eine Testmigration handelt, kann jetzt die read-only Einstellung wieder von der Datenbank entfernt werden.

Datenbank auf dem neuen System wiederherstellen

Man kopiert sich jetzt die oben erstellte Backupdatei auf den neuen SQL Server (nur lokal abgelegte Dateien können wiederhergestellt werden). Über das SQL Management Studio legt man eine neue Datenbank an. Die Einstellungen sind dabei völlig egal. Über Rechtsklick auf die neue Datenbank und dann Tasks > Restore > Database stellt man jetzt das oben erstellte Backup auf dieser Datenbank wieder her.

Man wählt dazu unter Device die Datei aus und prüft unter Destination, daß die korrekte Datenbank überschrieben wird:

Unter Files kann man prüfen, daß die zugehörigen Datenbankdateien (mdf und ldf) auch an der gewünschten Stelle landen. Wichtig ist noch, daß unter Options der Haken bei Overwrite the existing database gesetzt wird:

 

Nach dem Wiederherstellen der Datenbank nicht vergessen, die read-only Einstellung wieder zu entfernen!

Datenbank prüfen

Zum Test, ob die Datenbank auf dem neuen System verwendet werden kann, gibt es ein PowerShell-Cmdlet. Man öffnet dazu eine SharePoint Management Shell als Administrator und gibt diesen Befehl ein:

Test-SPContentDatabase –Name <NameDerDatenbank> -WebApplication http://sharepoint

Das Cmdlet Test-SPContentDatabase ist hier beschrieben.

Falls das Cmdlet Warnungen betreffs fehlender Feature ausgibt, sollten die entsprechenden Solutions (WSPs) auf dem Zielsystem bereitgestellt werden. Man kann die Datenbank zwar trotzdem einbinden, aber die enthaltenen Sites werden dann höchstwahrscheinlich nicht (korrekt) funktionieren.

Classic und Claims Authentifizierung

Sehr häufig wird man bei einer Migration von 2010 nach 2013 von Test-SPContentDatabase aber folgende Meldung erhalten:

The web application is configured with claims authentication mode however the content database you are trying to attach is intended to be used against a windows classic authentication mode.

Bei SharePoint 2010 war die Verwendung der Claims Authentifizierung optional, während sie bei SharePoint 2013 Standard ist und genau das macht uns jetzt Probleme. Im Web findet man viele Anleitungen dazu, wie man mit der Problematik umgeht. Es werden jeweils zwei Möglichkeiten beschrieben:

Möglichkeit 1: Upgrade der Datenbank auf Claims im alten System vor dem Backup. Wie man das macht, ist hier beschrieben. Dabei werden allerdings Änderungen an einem bestehenden und eventuell produktiv genutzten System gemacht. Wenn z.B. die Migration erstmal nur getestet werden soll, ist das nicht unbedingt erwünscht.

Möglichkeit 2: Erstellen einer Classic Webanwendung in SharePoint 2013 per PowerShell, anhängen der Datenbank an diese Webanwendung und danach Upgrade auf Claims. Wie man das macht, ist hier beschrieben (weiter unten auf der Seite). Auch diese Vorgehensweise ist nicht immer praktikabel, well man dabei eine neue Webanwendung im Zielsystem benötigt. Wenn bereits eine Webanwendung mit Inhalt besteht und die Datenbank dort angehängt werden soll, ist dieser Weg nicht direkt gangbar.

Es gibt aber eine dritte Möglichkeit, bei der die Meldung ignoriert werden und die Datenbank trotzdem an die Webanwendung angehängt werden kann.

Datenbank anhängen

Die Datenbank wird mit Hilfe von PowerShell einer SharePoint-Webanwendung angehängt:

Mount-SPContentDatabase <NameDerDatenbank> -DatabaseServer <Servername> -WebApplication http://sharepoint

Das Cmdlet Mount-SPContentDatabase ist hier beschrieben.

Nach dem Anhängen der Datenbank kann ein Farmadministrator die in der Datenbank enthaltenen Websites im Browser aufrufen. Alle anderen Benutzer erhalten aber eine Zugriff verweigert Fehlermeldung. Um das zu reparieren, muß jetzt noch die Authentifizierung angepaßt und die Benutzer migriert werden. Das geht jetzt mit

Möglichkeit 3: per PowerShell nachträglich auf Claims umstellen. Dazu führt man in der SharePoint Management Shell folgendes aus:

$wa = Get-SPWebApplication http://sharepoint
$wa.MigrateUsers($true)
$wa.ProvisionGlobally()

Und schon sind alle Websitesammlungen der Datenbank migriert und können von allen Benutzern verwendet werden.

Vorsicht mit KB2817630

Und schon wieder die Warnung vor einem aktuellen Microsoft-Update. Nachdem erst vor Kurzem ein Update veröffentlich wurde, das Datenansichten in SharePoint unbenutzbar machen konnte, gibt es jetzt schon wieder ein Problem mit einem aktuellen Update vom 10.09.2013. KB2817630 sorgt dafür, daß die Ordneransicht in Outlook 2013 leer bleibt.

Einzige Abhilfe schafft nach derzeitigem Kenntnisstand einzig die Deinstallation dieses Updates. Achtung: bei mir erschien dieses Update zweimal unter den installierten Updates und ich mußte auch beide einzeln deinstallieren bis das Problem behoben war. Selbstverständlich mit einem Neustart zwischendurch…

SharePoint Designer 2013 stürzt beim Website öffnen ab

Das Problem: SharePoint Designer 2013 stürzt beim Klick auf Website öffnen ab. Dieses Problem hatte ich bereits vor längerer Zeit und konnte es nach einer relativ kurzen Suche im Web auch beseitigen. Jetzt trat es hier erneut auf und ich mußte wieder nach der Lösung suchen. Deshalb dieser Beitrag in der Hoffnung beim nächsten Mal schneller zur Lösung zu gelangen.

Der Fehler tritt nur auf, wenn auf einer Maschine mehrere Versionen von SharePoint Designer installiert sind. Da ich leider immer noch alle möglichen Versionen supporten muß, habe ich hier also SharePoint Designer 2007, 2010 und 2013, was normalerweise auch problemlos funktioniert. Die kürzliche Installation von SP2 für SharePoint Designer 2010 hat dann diesen Fehler wieder zutage gefördert. Die Lösung hatte ich hier bei Marc D Anderson gefunden, aber es gibt inzwischen viele Beiträge dazu.

Die Lösung besteht darin, zwei Werte aus der Windows Registry zu löschen. Es handelt sich dabei um

HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Website öffnen\ClientGUID

und

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Open Find\Microsoft SharePoint Designer\Settings\Website öffnen\ClientGUID

Einfach die beiden Werte löschen (Rechtsklick – Löschen), SharePoint Designer neu starten und alles funktioniert wieder 🙂

Vorsicht mit KB2844286 bzw KB2844287

Achtung: ein beim letzten Patchday am 09.07.2013 veröffentlichtes Update KB2844286 bzw. KB2844287 Sicherheitsupdate für Microsoft .NET Framework 3.5.1 verursacht Probleme in SharePoint.

Wenn eine Ansicht mit SharePoint Designer bearbeitet wurde, verursacht diese Ansicht nach der Installation des Updates die bekannt lapidare Fehlermeldung "Dieses Webpart kann nicht angezeigt werden. Öffnen Sie diese Webseite in einem mit Microsoft SharePoint Foundation kompatiblen HTML-Editor, z.B. in Microsoft SharePoint Designer, um dieses Problem zu behandeln". Natürlich zeigt sich das Problem innerhalb von SharePoint Designer nicht. Die Seite wird dort ganz normal dargestellt.

In den SharePoint-Logs finden sich unterschiedliche NullReferenceException, die alle auf Probleme bei der XSL-Transformation hindeuten.

Nach derzeitigem Kenntnisstand kann man also nur empfehlen dieses Update nicht auf SharePoint Servern zu installieren. Falls es bereits installiert wurde und der Fehler auftritt, kann man das Update deinstallieren und der Fehler ist verschwunden.

Update 06.08.2013: es gibt inzwischen auch einen Fix zum Download, der das Problem offenbar ebenfalls behebt. Ich habe es aber noch nicht selbst getestet. Der Fix kann hier heruntergeladen werden. Danke an Markus Hiller, der das hier gepostet hat.

Versionen / Patchlevel in SharePoint 2010

Ein kurzer Beitrag zum Versionsstand in SharePoint 2010, der (einmal mehr) als Erinnerungshilfe für mich selbst dienen soll.

Die aktuelle Version einer SharePoint Farm kann man in der Zentraladministration auf der Seite System Settings Servers in Farm sehen:

Dieselbe Versionsnummer kann man auch per PowerShell ermitteln:

$farm = Get-SPFarm
$farm.BuildVersion

Eine detaillierte Übersicht findet man in der Zentraladministration unter Upgrade and Migration Check product and patch installation status.

Und hier noch ein Link, der eine Übersicht der Versionsnummern und der zugehörigen CUs bietet (auch für SharePoint 2007).

MachineKeys in der web.config von SharePoint

Wenn man SharePoint mit FBA (Formularbasierter Authentifizierung / Forms Based Authentication) arbeitet, braucht man in vielen Fällen einen sogenannten MachineKey (Computerschlüssel) wenn man Benutzerpasswörter nicht im Klartext ablegen möchte. Sobald man eine Webanwendung für FBA konfiguriert, erzeugt SharePoint einen solchen Schlüssel und trägt ihn in die web.config der Webanwendung ein.

Wenn man mehrere Webanwendungen gegen dieselbe Benutzerdatenbank fahren möchte oder auch nach einer Migration, ist es notwendig hier einzugreifen und eigene Schlüssel zu verwenden. In diesem Fall wird man sich wahrscheinlich sehr schnell wundern, weil sich am nächsten Tag kein Benutzer mehr anmelden kann. Verantwortlich dafür ist ein Timerjob, der regelmäßig jede Nacht ausgeführt wird und der den ursprünglichen Schlüssel wieder in die web.config einträgt.

Man sollte jetzt aber nicht einfach den gesamten Timerjob deaktivieren, weil dieser mehrere Integritätsanalysen (Health Analysis) ausführt. Allerdings kann man die verantwortliche Regel der Integritätsanalyse deaktivieren. Für das Zurücksetzen des Computerschlüssels ist die Regel ViewStateKeysAreOutOfSync zuständig und man kann sie mit folgenden PowerShell-Befehlen deaktivieren:

Get-SPHealthAnalysisRule ViewStateKeysAreOutOfSync | Disable-SPHealthAnalysisRule

SharePoint 2013 – Als anderer Benutzer anmelden

Jedem, der bereits SharePoint 2013 ausprobiert hat, ist wahrscheinlich aufgefallen, daß dort der Menüpunkt Als anderer Benutzer anmelden fehlt. Offenbar wurde er von Microsoft entfernt, weil er in der Vergangenheit im Produktivbetrieb öfter zu Problemen geführt hat (man meldet sich zwar im Browser als anderer Benutzer an, aber Dokumente werden in Office trotzdem mit den gespeicherten Anmeldedaten geöffnet).

Beim Entwickeln und Testen einer Anwendung ist dieser Menüpunkt aber enorm wichtig und deshalb soll hier gezeigt werden, wie man ihn auf einem Entwicklungssystem wiederbekommt. Die Lösung dafür läßt sich inzwischen sehr schnell im Web finden, weshalb dieser Beitrag mehr als Referenz für mich selbst dient.

Die eigentliche Funktion hinter dem Menüpunkt ist im Code immer noch vorhanden, einzig der Menüpunkt selbst wurde entfernt, so daß man ihn lediglich im Menücontrol wieder einfügen muß. Man öffnet dazu die Datei Welcome.ascx im Ordner 15\TEMPLATE\CONTROLTEMPLATES mit einem beliebigen Editor und fügt vor dem Menüpunkt mit der ID ID_RequestAccess folgendes ein:

<SharePoint:MenuItemTemplate runat="server" ID="ID_LoginAsDifferentUser"
  Text="<%$Resources:wss,personalactions_loginasdifferentuser%>"
  Description="<%$Resources:wss,personalactions_loginasdifferentuserdescription%>"
  MenuGroupId="100"
  Sequence="100"
  UseShortId="true"
  />

Nach dem Speichern und Neuladen einer Seite im Browser steht der Menüpunkt wieder zur Verfügung. Wenn es mehrere Server in der Farm gibt, muß die Änderung auf allen Webfrontend-Servern gemacht werden.

Achtung: die Änderungen können von Microsoft bei einem Update (Hotfix oder Service Pack) ohne weiteres überschrieben werden.

Nachtrag: Fabian Moritz hat hier eine bessere Methode beschrieben, die das Problem mit der Änderung einer SharePoint-eigenen Datei umgeht.

Fehler 5586 im EventLog nach SP1

Nach der Installation von Service Pack 1 haben wir haben auf mehreren Servern einen regelmäßig wiederkehrenden Fehler 5586 "Could not find stored procedure ‚proc_UpdateStatisticsNVP‘." in der Windows Ereignisanzeige. Eine Suche im Web ergab, daß zwar viele dasselbe Problem haben, daß es aber offenbar keine offizielle Lösung dafür gibt.

Wenn man im Datenbankserver nachschaut, stellt man fest, daß es die Stored Procedure proc_UpdateStatisticsNVP zwar in allen Inhaltsdatenbanken (auch in der Admin_Content_<GUID>) gibt, aber nicht in der Konfigurationsdatenbank. Kopiert man diese Stored Procedure in die Konfigurationsdatenbank erscheint der Fehler nicht mehr.

Ich möchte hier ausdrücklich darauf hinweisen, daß diese Lösung Änderungen an der Konfigurationsdatenbank erfordert. Derartige Änderungen werden von Microsoft nicht unterstützt und können deshalb zum Verlust von Supportansprüchen führen. Eine offizielle Lösung für das Problem habe ich allerdings nicht gefunden. Der Fehler scheint auch keine Auswirkungen zu haben – zumindest habe ich nichts gefunden, dessen Funktion dadurch beeinträchtigt werden würde. Es gibt also auch die Möglichkeit, mit der regelmäßig erscheinenden Fehlermeldung zu leben und auf eine offizielle Lösung von Microsoft zu warten.

Für alle, die die Fehlermeldung stört und die Änderungen an der Datenbank machen wollen, hier die Vorgehensweise:

Man öffnet mit dem SQL Server Management Studio den SharePoint-Datenbankserver. In einer beliebigen Inhaltsdatenbank (Standardname WSS_Content) findet man unter Programmability Stored Procedures die Prozedur proc_UpdateStatisticsNVP. Mit Rechtsklick Script Stored Procedure asCREATE to New Query Editor window läßt man sich ein Script zur Erstellung der Prozedur erzeugen. Im Erzeugten Script gibt es ganz oben eine Zeile Use <Name der Inhaltsdatenbank>. In dieser Zeile ändert man den Namen der Inhaltsdatenbank in den Namen der Konfigurationsdatenbank (Standard ist SharePoint_Config) und führt das Script aus, z.B. durch Drücken von F5. Dadurch wird die Stored Procedure auch in der Konfigurationsdatenbank angelegt und die Fehlermeldungen erscheinen in Zukunft nicht mehr.