SharePoint Multiclient Anwenderstudie 2016

Die Hochschule der Medien Stuttgart führt wieder eine Online-Befragung durch und auch dieses Mal auch von mir der Aufruf mitzumachen. Es gibt wieder etwas zu gewinnen!

Auf der Seite heißt es dazu:

die Verbreitung der Portalsoftware Microsoft SharePoint ist in den letzten Jahren enorm gestiegen.

Die Frage ist: Wie zufrieden sind die Kunden? Dieser Thematik geht die Hochschule der Medien unter der Leitung von Prof. Dr. Thorsten Riemke-Gurzki und Prof. Dr. Arno Hitzges in der vorliegenden Befragung nach.

Ziel ist es, die Meinung der tatsächlichen Anwender zu erfragen, um auf Grundlage der Aussagen Rückschlüsse auf den Prozess der Nutzung von Intranet und Unternehmensportalen und der Integration von Microsoft SharePoint vornehmen zu können.

SPWeb.EnsureUser und Claims

Jeder SharePoint-Entwickler kennt wahrscheinlich die EnsureUser-Methode der SPWeb-Klasse (Beschreibung bei MSDN). Der Methode übergibt man einen Benutzer in der Form Domäne\Login und bekommt eine gültige SPUser-Instanz und zwar unabhängig davon, ob der Benutzer in der Website bereits bekannt ist oder nicht.

Das war jedenfalls "früher" der Fall, d.h. vor der Benutzung von Claims-Authentifizierung. Wird die betreffende Webanwendung mit Claims betrieben, was bei SharePoint 2013 Standard ist, muß man etwas anders vorgehen. Dasselbe gilt für SharePoint 2010 wenn Claims benutzt wird.

Die Angabe von Domäne\Login reicht alleine nicht mehr aus und man muß zusätzlich angeben um welche Art von Benutzer es sich handelt. Mit Claims-Authentifizierung können schließlich auch andere Arten von Benutzerquellen als nur Active Directory verwendet werden. Hier die grundsätzliche Vorgehensweise:

string account = @"domain\login";
SPClaimProviderManager cpm = SPClaimProviderManager.Local;
SPClaim userClaim = cpm.ConvertIdentifierToClaim(account, SPIdentifierTypes.WindowsSamAccountName);
SPUser user = web.EnsureUser(userClaim.ToEncodedString());

Der Code benötigt folgendes using-Statement:

using Microsoft.SharePoint.Administration.Claims;

Der gezeigte SPIdentifierTypes.WindowsSamAccountName gilt für AD-Benutzer. Je nach Herkunft des gesuchten Benutzers muß hier ein anderer Typ angegeben werden.

Anwenderstudie SharePoint 2014/2015

Die Hochschule der Medien in Stuttgart führt eine Online-Befragung zur Kundenzufriedenheit durch und hat mich gebeten, mit zur Verbreitung beizutragen. Deshalb hier der Aufruf: bitte nehmt an der Befragung teil! Es gibt auch etwas zu gewinnen!

Auf der Seite heißt es dazu:

die Verbreitung der Portalsoftware Microsoft SharePoint ist in den letzten Jahren enorm gestiegen.

Die Frage ist – wie zufrieden sind die Kunden? Dieser Frage geht die Hochschule der Medien unter der Leitung von Prof. Dr. Thorsten Riemke-Gurzki und Prof. Dr. Arno Hitzges in der vorliegenden Befragung nach.

Ziel ist es, die Meinung der tatsächlichen Anwender zu erfragen, um auf Grundlage der Aussagen Rückschlüsse auf den Prozess der Nutzung von Intranet und Unternehmensportalen und der Integration von Microsoft SharePoint vornehmen zu können.

Und hier nochmal der Link zur Befragung.

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.

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 🙂

DateTimeControl und Zugriff verweigert

Wenn man das SharePoint-DateTimeControl in einem eigenen Webpart oder in einer eigenen Anwendungsseite verwendet, kann es passieren, daß man beim Aufklappen des Kalenders eine Zugriff verweigert / Access Denied Meldung bekommt. Das passiert, wenn man sich in einer Unterwebsite befindet und wenn der Benutzer auf die Root-Websitesammlung keine Zugriffsrechte hat.

Man sollte dieses Szenario ohnehin vermeiden und immer dafür sorgen, daß alle Benutzer auf die Root-Websitesammlung zumindest minimale Berechtigungen besitzen. Es kann sonst zu weiteren unerwarteten Fehlern kommen, weil innerhalb von SharePoint immer wieder Dateien Server-relativ von dort referenziert werden.

Beim DateTimeControl wird der aufklappende Kalender ebenfalls Server-relativ als <iframe> gerendert und deshalb bekommen Benutzer ohne Berechtigungen auf die Root-Websitesammlung eben die Zugriff verweigert Meldung. Als Entwickler kann man das umgehen, indem man die Eigenschaft DatePickerFrameUrl mit dem richtigen Pfad innerhalb der aktuellen Website belegt.

Wenn das Control z.B. innerhalb eines Webparts per Code generiert wird, fügt man einfach folgende zusätzliche Codezeile ein:

myDateTimeControl.DatePickerFrameUrl = SPUrlUtility.CombineUrl(SPContext.Current.Web.ServerRelativeUrl, "_layouts/iframe.aspx");

Wenn das Control z.B. innerhalb einer Anwendungseite deklarativ generiert wird, kann man es ebenfalls wie oben im Code-behind der Seite erledigen oder auch gleich deklarativ beim Erzeugen des Controls:

<SharePoint:DateTimeControl DatePickerFrameUrl="<% $SPUrl:~Site/_layouts/iframe.aspx %>" ID="myDateTimeControl" runat="server" />

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.

XML Rohdaten im IE anzeigen

Wenn man mit dem Internet Explorer die Daten eines Webdienstes, z.B. eines WCF-Dienstes von SharePoint 2010 oder der REST-API von SharePoint 2013 anzeigen möchte, erkennt der IE das als Feed und stellt es ungefähr so dar:

Als Entwickler ist man natürlich mehr an den rohen Daten interessiert, weil man sie wie auch immer weiterverarbeiten möchte. Die Einstellung dazu findet man in den Internetoptionen im Reiter Inhalte

Unter Feeds und Web Slices klickt man auf Einstellungen

Dort den Haken bei Feedleseanzeige entfernen und der IE stellt dieselben Daten so dar:

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).

Gültigkeitsprüfungen mit mehreren Bedingungen

Die Syntax der Formeln für Gültigkeitsprüfungen ist manchmal etwas verwirrend. Deshalb dieser kurze Beitrag zur Erklärung (und als Gedankenstütze für mich selbst).

Eine einfache Gültigkeitsprüfung mit nur einer Bedingung sieht z.B. so aus:

=[Zahlenfeld]>0

In einer Liste oder Bibliothek mit dieser Gültigkeitsprüfung kann ein Element nur gespeichert werden, wenn in der Spalte Zahlenfeld ein Wert größer als Null eingegeben wurde. Die Prüfung gilt also immer dann als bestanden, wenn die angegebene Formel wahr zurückliefert.

Das von Microsoft direkt auf der Seite der Gültigkeitsprüfungseinstellungen angegeben Beispiel zeigt, wie man ganz einfach zwei Spalten in die Prüfung einbeziehen kann:

=[Rabatt]<[Kosten]

Dadurch können Elemente nur gespeichert werden, wenn in die Spalte Rabatt ein kleinerer Wert als in die Spalte Kosten eingegeben wurde.

Schwieriger wird es, wenn die Formel mehrere Bedingungen enthalten soll, die entweder mit UND oder mit ODER verknüpft werden sollen. Die allgemeine Syntax dafür sieht so aus:

=AND(<Bedingung1>;<Bedingung2>)

<Bedingung1> und <Bedingung2> können dabei irgendwelche Ausdrücke sein, die entweder wahr oder falsch liefern, wie die beiden Beispiele oben. Statt AND kann natürlich auch OR verwendet werden.

Ein Beispiel: eine Liste enthält ein Zahlenfeld und eine Auswahlspalte mit den Optionen Auswahl1, Auswahl2 und Auswahl3. Wenn Auswahl1 gewählt wird, soll das Zahlenfeld eine Zahl größer Null enthalten. Bei jeder anderen Auswahl ist die Zahl egal. Die Formel dafür sieht so aus:

=OR([Auswahlfeld]<>"Auswahl1";[Zahlenfeld]>0)

Selbstverständlich können auch mehrere dieser Konstrukte geschachtelt werden, was dann z.B. so aussehen kann:

=AND(OR(<Bedingung1>;<Bedingung2>);OR(<Bedingung3>;<Bedingung4>))

Diese Prüfung gilt nur dann als bestanden, wenn <Bedingung1> oder <Bedingung2> wahr ist und gleichzeitig <Bedingung3> oder <Bedingung4> wahr ist. Natürlich können auch drei oder alle vier Bedingungen wahr sein.