Ab und zu läuft nicht immer alles reibungslos.

Welche Möglichkeiten bietet SharePoint mir zu erkennen, dass etwas nicht stimmt? Wie erhalte ich Einblick in die Arbeitsweise und Abläufe?

Alles innerhalb und rundum SharePoint im Blick zu haben ist ein anspruchsvolles Ziel – gerade wenn die Nutzerzahl der SharePoint-Farm stetig wächst und in regelmäßigen Abständen neue Funktionalitäten und Änderungen dazukommen.

Schauen wir uns also an, welche Werkzeuge der Administrator Out oft he Box zur Verfügung stehen, welchen Zweck diese erfüllen und wie wir unser Set an Möglichkeiten selbst erweitern können.

Um den Administrator zu unterstützen, wartet Microsoft mit in SharePoint integrierten Werkzeugen und Berichten auf. Diese Werkzeuge lassen sich in drei Kategorien einordnen:

• Gesundheitszustand (Health)
• Nutzerverhalten (Usage)
• Diagnose (Diagnostic)

Gesundheit und Integritätszustand

Fangen wir mit dem Gesundheitszustand an. Es gibt eine ganze Reihe von Microsoft Best Practices, die dem Administrator als Wegweiser für den erfolgreichen Betrieb einer SharePoint-Server-Farm dienen. Um dem Administrator das Anwenden dieser Richtlinien und Praktiken so einfach wie möglich zu machen, wurde mit dem SharePoint Server 2010 erstmals der Health Analyzer eingeführt.

Um wichtige Erkenntnisse im Umgang mit einer vorhandenen Farm zu erhalten, gab es zuvor lediglich die Möglichkeit, ein externes Tool, den Microsoft Best Practices Analyzer, herunterzuladen und auszuführen. Glücklicherweise hat Microsoft damals schnell erkannt, dass uns mehr damit geholfen ist wenn dieser Baustein gleich Out of the Box zur Verfügung steht.

Der Health Analyzer ist eine in SharePoint integrierte Komponente (SharePoint Maintenance Manager), die den Bereich Health Monitoring abdeckt. Gleich auf der Startseite in der Zentraladministration ist sie zu sehen. Sie tritt meist als roter oder gelber Balken in Erscheinung und dient dem Zweck den Administrator auf potenzielle Probleme und Fehlkonfigurationen hinzuweisen (Abb. 1). Ganz besonders spannend finde ich, dass dem Administrator auch gleich Lösungsvorschläge unterbreitet werden.

Der Health Analyzer

Das Herzstück des Health-Analyzer-Konzepts ist der SharePoint Maintenance Manager. Dieser prüft in festgelegten Abständen mit sogenannten „Integritätsregeln“ die Server und Services der Farm. Je nach dem um welche Integritätsregel es sich handelt, wird ein spezifischer Test durchgeführt. Jede Integritätsregel „besitzt“ einen eigenen Zeitgeberauftrag, mit diesem wird das zeitgesteuerte Ausführen einer Integritätsregel (HealthAnalyzerRule) realisiert.

• Tw1tt3r
• L1nk3dIn

SharePoint 2013 bringt 88 dieser Integritätsregeln, die periodisch ausgeführt werden, mit. Mit diesem vorhandenen Set an Integritätsregeln werden die Bereiche Verfügbarkeit, Konfiguration, Performance und Sicherheit abgedeckt (Abb. 2). Die Integritätsregeln verfolgen das Ziel, nicht nur auf mögliche Probleme hinzuweisen, sondern auch Vorschläge ihrer Lösung aufzuzeigen.

Mancher dieser Regeldefinitionen bzw. Integritätsregeln bieten sogar die Möglichkeit einer automatischen Reparatur.

Konfigurationsmöglichkeiten einer Integritätsregel

Die Integritätsregel

Jede Integritätsregel ist in der Zentraladministration im Bereich Monitoring unter „Review rule definitions“ zu finden und enthält ausführbaren Code, der in Form einer Bibliothek in der Farm installiert wurde. Obendrein kümmert sich ein dazugehöriger Zeitgeberauftrag darum, dass diese Regel ausgeführt wird.

Es gibt zwei unterschiedliche Arten von Integritätsregeln, die sich darin unterscheiden, ob neben dem Prüfvorgang auch eine Reparaturfunktion enthalten ist. Wenn dem so ist, kann der Administrator der Farm diese Funktionalität über die UI explizit ausführen lassen oder diese entsprechend konfigurieren, die Reparatur zu veranlassen, sobald der Check fehlschlägt.

Der Administrator kann das Ausführen dieser Regeln wie gerade erwähnt, selbst anpassen. Diese Regeln können deaktiviert und aktiviert werden, ebenso kann neben dem periodischen Ausführen auch die sofortige Prüfung durch diese Regel erfolgen. Möchte man nicht, dass ein identifiziertes, potenzielles Problem behoben wird, so kann dies für die betroffene Integritätsregel ebenfalls deaktiviert werden. Eine Liste der Integritätsregeln ist hier zu finden.

The sky is the limit – Unsere eigenen Integritätsregel

Die vorhandenen Integritätsregeln decken bereits ein Breites Spektrum der Microsoft Best Practices für die Konfiguration und den Betrieb einer SharePoint 2013 Farm ab. Für all diejenigen, denen dies nicht ausreicht, gibt es eine gute Nachricht: Wir haben die Möglichkeit, eigene Integritätsregeln zu entwickeln und zwar gilt es hierbei

ein paar wichtige Punkte beim Design der eigenen Integritätsregel zu beachten :

• Weniger ist mehr – monatliches oder wöchentliches Ausführen eines Checks
• Fokussierung auf Sicherheit, Verfügbarkeit, Performance oder Konfiguration
• Prävention statt Diagnose
• Die Integritätsregel erkennt ein potenzielles Problem in der Farm.
• Abhängigkeiten vermeiden
• Möglichst wenig Ressourcen beanspruchen, lieber kleine und einfache Checks bzw. Integritätsregeln

Ganz bewusst gehe ich hier nicht ins Detail, da dies den Rahmen des Artikels sprengen würde, aber um eine eigene Integritätsregel zu kreieren, wird Visual Studio 2012 benötigt, sowie Kenntnisse im Bereich der SharePoint Entwicklung wären da die Voraussetzung.  Der Hauptbestandteil einer Integritätsregel besteht  entweder aus der Klasse SPRepairableHealthAnalysisRule oder SPHealthAnalysisRule. Wie der Name schon sagt, kann der Entwickler hier entscheiden, welche Art von Integritätsregel er gerne realisieren möchte – eine mit self-repair Funktionalität oder ohne.

Eigentlich ist das Grundgerüst recht einfach gehalten. Mit dem überschreiben der Methoden Summary, Explanation, Remedy, Category, ErrorLevel und Check, statten wir unsere Integritätsregel mit den gewünschten Merkmalen aus. Ebenso sollten wir die Eigenschaft AutomaticExecutionParameters überschreiben. Verwenden wir SPRepairableHealthAnalysisRule, so muss die Repair-Methode in jedem Falle ebenfalls überschrieben und verwendet werden, den diese realisiert die Reparaturfunktionalität.

Ist die erste eigene Integritätsregel „geschrieben“, so empfiehlt es sich vor deren Bereitstellung einen Durchlauf außerhalb der Farm durchzuführen. Von der Herangehensweise können wir uns aussuchen, ob wir alles über die PowerShell lösen oder uns eine eigene kleine Konsolenanwendung bauen. In beiden Fällen läuft es ziemlich ähnlich ab, nur die Syntax unterscheidet sich, denn man bindet bzw. lädt zuerst die dll, instanziiert sie und kann dann auf die Check-Methode zugreifen, um diese auszuführen. Funktioniert alles wie geplant, so kann die Bibliothek, verpackt in einer Solution die Farm eingespielt werden.

Wer sich dem Thema widmen möchte, sollte hier vorbei schauen.

Berichte über das Nutzverhalten

Mit SharePoint 2010 wurde damals eine neue Komponente eingeführt und in SharePoint 2013 erweitert. Es handelt sich um die „Usage and Health data collection“ Dienstanwendung.

Sie besteht aus einer Datenbank, einer Dienstanwendung, UsageProvidern, HealthProvidern und Zeitgeberaufträgen. Installiert man eine neue Farm, so wird diese Komponente vor allen anderen Dienstanwendungen durch den Konfigurationsassistenten installiert.

Die „Usage and Health data collection“  Dienstanwendung kümmert sich um die Beschaffung und Verarbeitung zweier ganz unterschiedlicher Arten von Informationen und zwar werden diese durch sogenannte Health- und Usage Provider gesammelt und verarbeitet, wobei mit „Health“ alle Daten, wie zum Beispiel Prozessorauslastung, gemeint sind – also z.B. das Sammeln der Performance-Counter-Daten. Noch eine kleine Brücke: Health-Daten werden gesammelt, unabhängig davon, ob und wie viele Benutzer aktiv sind. Dann gibt es die Usage Provider, die sich darum kümmern, nutzerspezifische Daten zu sammeln. Der „Request Usage“-Provider z.B. zeichnet jeden einzelnen Request auf. Je mehr Benutzer die Farm verwenden, umso mehr Daten werden von den Usage Data Providern verarbeitet.

Besonders interessant ist das Thema Suche im Zusammenhang mit der aus der Analyse gewonnen „Usage and Health“ Daten. Die Story rund um die Analytics Komponente wurde in SharePoint 2013 komplett neu konzipiert. Diese ist nun Bestandteil der Suche, was bedeutet dass es die „Web Analytics“ Dienstanwendung als solche nicht mehr gibt.  Der Fokus liegt nun viel stärker auf den Inhalten, um zum Beispiel die Relevanz von Dokumenten und Suchabfragen zu verbessern.

In der Zentraladministration haben wir die Möglichkeit über die Dienstanwendung der Suche mit einem Klick auf „Usage Reports“ einen detaillierten Einblick zu erhalten. Ebenso erhalten auch Website-Besitzer tiefere Einblicke – in Form von Excel Berichten, denn diese können sich nun über die Beliebtheit/Popularität von Inhalten im Kontext der Website oder aber auch im Kontext der Dokumentenbibliothek erkundigen. Auch der Webseitensammlungsadministrator kommt nicht zu kurz. Er erhält mit einem Klick auf „Popularity and Search Reports“  zusätzlich einen Einblick in das Suchverhalten auf Webseitensammlungs-Ebene.

• Tw1tt3r
• L1nk3dIn

Wenn wir uns den Request Usage Provider ansehen, ist dieser auch gleich der interessanteste: Jeder Request durch einen Browser eines Benutzers an die Farm wird mit zusätzlichen Informationen wie: 

WebApplicationId, FarmId, KorrelationId, MaschineName, LogTime, UserLogin, ServerUrl, SiteId, SiteUrl, DocumentPath, QueryString, HttpStatus, RequestType, UserAdress, Duration(ms), QueryDurationSum(ms)

versehen und nach der Verarbeitung schlussendlich in der Datenbank abgelegt.

Allein mit den Daten des Request Usage Provider können wir bereits einen tiefen Einblick erhalten.

Beispielsweise erfahren wir, wie lange es dauert, um einen Request zu beantworten und mit einem order by Duration am Ende der Abfrage von [dbo].[RequestUsage] finden wir unsere „langsamsten“ SharePoint-Seiten. Berücksichtigen wir die Spalte UserAgent, so erfahren wir, welche Browser im Einsatz sind (mehr dazu im Kasten „Usage and Health“)

Schauen wir etwas genauer hin, legen sämtliche OOB (Out of the box) Datenprovider ihre Daten in den für sie bestimmten Tabellen innerhalb der WSS_loggin-Datenbank ab.

Insgesamt sind dies pro Datenprovider gleich 32 Stück. Jeder Tag stellt eine Tabelle dar, dies erklärt warum die Daten maximal 31 Tage alt werden.

Abgelegt werden die Daten gemäß der UTC-Zeitzone. Jede Tabelle stellt einen Tag dar. Zum Glück steht uns pro Provider eine View zur Verfügung, die alle Tabellen zusammenfasst, denn dies spart uns die Arbeit wenn wir alle Daten abfragen möchten

• Tw1tt3r
• L1nk3dIn

So gelangen die Daten in die Datenbank

Bei der Handhabe der Health- und Usage-Daten wird unterschiedlich vorgegangen.

Die Health-Daten, wie zum Beispiel Windows Event Logs, Performance Counter oder die SharePoint-ULS-Informationen, werden direkt in die Datenbank geschrieben, nicht aber die Usage-Daten, da deren Volumen von der Nutzerzahl abhängig ist, sind sie sozusagen entkoppelt und Zeitgeberaufträge sorgen für die Verarbeitung und das übertragen der Daten.

Steigt die Nutzerzahl, erhöht sich auch die Last der Farm und das zu verarbeitende Volumen der Daten, daher werden die Usage-Daten zuerst im Dateisystem abgelegt.

Ob, was und wohin protokolliert wird, ist in der Zentraladministration im Tab-Monitoring unter Configure web analytics and health data collection durch den Farm-Administrator konfigurierbar.

Die Daten werden am gewünschten Ort und lokal auf dem Server mit der Dateiendung *.usage abgelegt.

Gefüllt werden diese durch den SPUsageManager. Dieser seralisiert die SPUsageEntry-Objekte und füllt somit die Usage-Dateien mit Inhalt. Das Einsammeln der Daten übernehmen spezielle Zeitgeberaufträge. Alle 30 Minuten startet ein Zeitgeberauftrag, Microsoft SharePoint Foundation Usage Data Import, und importiert die Daten. Anschließend ruft jeder registrierte Usage Receiver seine angelieferten Daten ab, so wie der Postbote die Zeitung auf die Fußmatte eines jeden Haushaltes ablegt und diese durch den jeweiligen Besitzer des Hauses abgeholt werden.

Einmal pro Tag sorgt ein weiterer Zeitgeberauftrag, Microsoft SharePoint Foundation Usage Data Processing, dafür, dass die Daten weiterverarbeitet werden, in dem die Metoden ProcessData() und TruncateData() aufgerufen werden.

Wem die OOB-Daten und Berichte nicht ausreichen, der kann eigene Health und Usage Provider entwickeln. Ein wirklich exzellenter Blog beschreibt dies im Detail [2].

Das interessanteste ist, dass auch die gesammelten Daten in der Usage-Datenbank landen und diese die einzige Datenbank ist, die wir abfragen und erweitern dürfen. Mit Erweitern ist gemeint, dass wir das Schema verändern (Tabellen, gespeicherte Prozeduren, Views), sobald wir einen eigenen Provider einspielen.

Diagnose

Keine Seltenheit sind SharePoint-Fehlermeldungen, welche wir direkt in der Mitte des Browser angezeigt bekommen. Entdecken wir eine solche Meldung, immer mit einem roten X gekennzeichnet, findet sich auch eine dazugehörige Korrelations-ID. Glücklicherweise hat Microsoft dafür gesorgt, dass die Korrelations-ID in jedem Request enthalten ist und jeder Benutzeranfrage diesen mit sich herumträgt. Die Korrelations-ID taucht sogar auch auf der Datenbankebene auf.

Im Tab Monitoring unter Configure diagnostic looging kann das Protokollierungsverhalten an die entsprechenden Anforderungen und Schwerpunktthemen der jeweiligen Farm angepasst werden.

• Tw1tt3r
• L1nk3dIn

Beim Anpassen der entsprechenden Event- oder Trace-Level einer Kategorie sollte darauf geachtet werden, dass nicht zu viel geloggt wird, da dies die Performance negativ beeinträchtigt. Gehen sie also sparsam mit dem Verbose-Level um und setzten sie es wieder etwas herauf, sobald sie einen Fehler dingfest machen konnten.

Um den ULS abzufragen, kann auch die PowerShell-Konsole verwendet werden. Verwenden sie beispielsweise folgendes Kommando, um einer typischen SharePoint Fehlermeldung auf die Schliche zukommen:

Get-SPLogEvent -StartTime (get-date).addminutes(-15) | ? { $_.correlation -eq “34cd235-2355-1367-cde32-21432ca3cb2a” } | fl message

Dieses Kommando fragt den ULS ab und filtert alle Einträge heraus, die jünger als 15 Minuten sind und die Korrelations-ID 34cd235-2355-1367-cde32-21432ca3cb2a besitzen.

Es gibt noch ein paar weitere Schalter und Parameter. Schauen sie unter [4] nach, um mehr zu erfahren.

Möchte man noch etwas mehr über eine SharePoint-Seite erfahren, weil diese zum Beispiel besonders langsam ist, so kann das sogenannte „Developer Dashboard“ aktiviert werden. Dies lässt sich mit der PowerShell realisieren sobald der unten stehende code-schnipsel ausgeführt wird.

Der Schalter OnDemand bedeutet, dass wir die Funktionalität freigeschaltet haben und jeder Webseitensammlungsadministrator nun selbst entscheiden kann, ob er auf das Dashboard zugreifen möchte. Tut er dies, so sieht er oben rechts ein Icon und sobald er darauf klickt, werden die einzelnen Komponenten, die zum Laden der Seite verwendet werden, detailliert aufgelistet. Das Developer Dashboard ist wirklich sehr interessant, weiterhin kann auch festgelegt werden, welche Berechtigungen erforderlich sind, um es nutzen zu dürfen.

Berichte

Berichte finden sich in der Zentraladministration sowie auf der Ebene der Webseitensammlung und Website.

Im Bereich der Webseitensammlung gelangen wir über die Seiteneigenschaften  mit einem Klick auf „Storage Metrics“ zu einer übersichtlichen Darstellung des Speicherplatzverbrauches einer Webseitensammlung. Diese Funktionalität wurde mit SharePoint 2010 SP1 erstmals eingeführt und ist auch im SharePoint Server 2013 vorhanden.

• Tw1tt3r
• L1nk3dIn

Ganz neu ist die Funktionalität  „Ausführen von Integrationsprüfungen“ auf der Webseitensammlungs-Ebene.

Jeder SharePoint Administrator oder am Upgrade Projekt beteiligter, der ein Upgrade von SharePoint 2010 nach SharePoint2013 plant, sollte sich mit diesen Checks beschäftigen. Beim upgrade werden diese Integritätsregeln so oder so automatisch im Reparaturmodus ausgeführt, daher sollte man sichergehen, dass hier alles im Vorfeld glatt läuft, um nicht in einen Blocker hineinzulaufen. Folgende Prüfungen werden durchgeführt:

• Nicht unterstützte MUI-Verweise (Multi-User Interface)
• Nicht unterstützte Sprachpaketverweise
• Fehlende Websitevorlagen
• Fehlende Kataloge
• Benutzerdefinierte Dateien

• Tw1tt3r
• L1nk3dIn

Diese Funktionalität steht auch als PowerShell Cmdlet zur Verfügung.

Test-SPSite -Identity http://sample.intranet.intra –Rule ee967197-ccbe-4c00-88e4-e6fab81145e1

Dieses Cmdlet prüft die angegebene Webseitensammlung und deren Unterwebsites auf Fehlende Standardkataloge und –berichte.

Repair-SPSite -Identity http://sample.intranet.intra [-Rule <RuleID>]

Dieses Cmdlet führt für eine Regel die angegebene Webseitensammlung im Reparaturmodus aus.

Wer sich mehr mit diesem Thema beschäftigen möchte, sollte diesen Link besuchen.

In der Zentraladministration, im Tab Monitoring, unter „View Health Report“ erfährt der Administrator nun noch wie viele Nutzer täglich/monatlich zu Besuch kommen.

Fazit

Out oft he Box bringt SharePoint 2013 bereits sehr viel Monitoring und Reporting mit.  Bei größeren Bereitstellungen sollte man sich unbedingt mit den Erweiterungsmöglichkeiten intensiv auseinandersetzen und den Einsatz von Enterprise Lösungen wie zum Beispiel dem System Center Operations Manager 2012 mit dem SP1 in Betracht ziehen.