SharePoint Configuration Best Practices - Super User und Super Reader

  • Article

SharePoint Adventskalender - 15. Türchen

Performance Tuning - Performance Monitoring - Best-Practices für SP-SQL-Konfigurationen - BLOB Management - Backup & Recovery

-------------------------------------------------------------

Besondere Funktionen erfordern besondere Einstellungen. Bei einem Feature ist das besonders wichtig. Die Rede ist von dem „SharePoint Server Publishing Infrastructure“ Feature oder auf deutsch, der „SharePoint Server-Veröffentlichungsinfrastruktur“.

Was ist an dieser Funktionalität so besonders? Die Veröffentlichungsinfrastruktur ist dazu gedacht, den SharePoint auch dafür zu nutzen, um reine Intranet- oder sogar Internetseiten zu hosten. Wichtig dabei ist, dass der Inhalt stets auf dem aktuellen Stand ist. Für Aktualisierungen werden von Dateien (Seiten) Zwischenversionen erstellt. Die Änderungen werden erst nach Veröffentlich einer neuen Hauptversion für alle Nutzer sichtbar. Dies ist natürlich auch für normale Kollaborationsszenarien denkbar, aber der Hauptfokus dieses Features liegt auf dem Veröffentlichen von Intranet- oder Internetseiten.

Das wichtigste Kriterium für eine erfolgreiche Intranetpräsenz ist ein schneller Seitenaufbau. Die Veröffentlichungsinfrastruktur nutzt dafür einen dedizierten Objekt-Cache. Wenn nun jeder Besucher durch den Aufruf einer entsprechenden Seite eine Anfrage an den SQL sendet, muss dieser auch jede einzelne bedienen. Erst bei jeder zweiten Anfrage der gleichen Seite würde der Cache tatsächlich greifen. Und dies gilt nun für jeden einzelnen Nutzer. Die Last auf dem SQL ist somit hoch und die Performance dadurch nicht optimal. Außerdem wächst der Cache schnell an, weil Dateien theoretisch doppelt und dreifach zwischengespeichert werden müssten.

Die Lösung liefern der Super User und der Super Reader Account. Bei einem Seitenaufruf werden so nur zwei Anfragen im jeweiligen Kontext der beiden Nutzer an den SQL gesendet. Der Super User („Full Control“) bekommt als Ergebnis auf diese Abfrage alle Entwürfe von Dateien, also die Zwischenversionen. Der Super Reader („Full Read“) bekommt alle veröffentlichten Versionen. Die Dateien aus beiden Abfragen landen im Cache. Für den eigentlichen Endnutzer werden dann die Berechtigungen aus den Zugriffssteuerungslisten (Acces Control List - ACL) geladen und dementsprechend nur die Informationen (aus dem Cache) gerendert und angezeigt, die er mit seinen Berechtigungen sehen darf. Der Vorteil dieses Verfahrens ist der schnelle Cache und es müssen nur die Ergebnisse für zwei Anfragen darin gespeichert werden. Dies ist also eine Performance- und Cache-Speicheroptimierung.

Nun kann es aber bei der Verwendung der Standardeinstellungen, nämlich des Systemkontos einer Website als "Portal Super User" und des "NT Authority\Local Service" als "Portal Super Reader", zu Problemen kommen. Kurz: mit dem Systemkonto als "Portal Super User" kann es zu Performance-Einbußen kommen, da hierbei manche „Entwurfsdateien“ doppelt abgefragt werden müssen. Da der „Local Service“ hingegen nicht explizit auf die jeweiligen veröffentlichten Seiten berechtigt ist, bekommt auch der Endnutzer eine Zugriffsverweigerung. Eine detailliertere Beschreibung finden Sie hier: https://technet.microsoft.com/de-de/library/ff758656.aspx)

Worauf ich aber eigentlich hinaus möchte, das ist die Authentifizierungsmethode. Microsoft änderte diese von SharePoint 2010 (Classic) zu SharePoint 2013 (Claims). Nun migrieren wir in SP2013 eine Classic-WebApplication zu Claims.

Convert-SPWebApplication -Identity "https://YourWebApp:80" -To Claims -RetainPermissions -Force

Dies migriert auch alle berechtigten Benutzer dieser WebApplication zu Claims. Dennoch bekommen anschließend alle Nutzer – inklusive der Administratoren – einen „Zugang verweigert“ beim Zugriff auf die Seite. Besonders bei öffentlichen Seiten macht dies sehr viel „Spaß“.

Der Hintergrund ist einfach, dass bei der Classic zu Claims Migrations, auch inklusive der Benutzer, eben nicht der Super User und Super Reader mitgenommen werden. Diese verbleiben mit ihrem Classic Account und können sich daher nicht mehr authentifizieren. Sie müssen daher diese Konten erneut mit ihrer Claims-Nutzerkennung anlegen, um das Problem zu lösen. Bitte denken Sie auch daran, wenn Sie Farmlösungen oder ähnliche Programme nutzen, dass diese entsprechend mitgenommen werden müssen und sich in Zukunft über Claims authentifizieren.

Der Vollständigkeit halber hier noch die PowerShell Befehle, um die User mit Windows-Claims anzulegen:

$webapp = Get-SPWebApplication “https://WebAppURL”
$webapp.Properties[“portalsuperuseraccount”] = “i:0#.w|domain\SuperUser”
$webapp.Properties[“portalsuperreaderaccount”] = “i:0#.w|domain\SuperReader”
$webapp.Update()

Viel Spaß beim „SharePointen“!

-------------------------------------------------------------

Weitere Türchen: