SharePoint 2010 Troubleshooting – Meine Top 10 bei der Fehleranalyse

Ein SharePoint ist schon ein unheimlich komplexes Produkt. Als Paradebeispiel der Komplexität zeige ich gern den “Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization” vom SharePoint Master Spencer Harbar. (Dieses Beispiel verdeutlicht, dass bspw. das Konfigurieren der Profil-Synchronisation nicht damit getan ist, eine ServiceApplication zu starten.)

Deshalb ist es umso wichtiger, bei unerwartetem Verhalten (manche nennen es auch Fehlverhalten) einen Plan zur systematischen Analyse zu haben. Meine persönlichen Helferlein sind dabei (in systematisch wahlloser Reihenfolge):

  1. Innerhalb der Zentraladministration prüfen, ob der Patch- und Upgrade-Status aller SharePoint-Server innerhalb der SharePoint-Farm den gleichen (fehlerlosen) Stand haben. Tipp: Wer Oberflächen nicht mag, kann auch das PowerShell-Cmdlet “Get-SPServer + NeedsUpgrade” nutzen.
  2. Fehler-IDs der Windows-Event-Logs mit den bekannten Einträgen für SharePoint-Foundation und SharePoint-Server abgleichen.
  3. Fehler-IDs der Windows-Event-Logs mit öffentlichen Datenbanken abgleichen. (Hier sind die Suchergebnisse allerdings mit Vorsicht zu genießen!)
  4. ULS-Logs (also die Log-Dateien aus dem 14-Hive) analysieren. Hinweise zur Eingrenzung der Massen an Log-Inhalten sind dabei Zeitangaben und natürlich die Korrelations-ID. – Beim Filtern kann das Tool “ULS Log Viewer” helfen. (Hinweis: Es gibt mittlerweile auch schon neuere / schickere Versionen des ULS Log Viewers auf Codeplex.)
  5. Fehler und Warnungen im Health-Analyzer mit den bekannten Healt-Analyzer Regelverstößen abgleichen.
  6. Status der Service-Accounts prüfen. (Domain-Accounts werden gern deaktivert oder erhalten ein neues Passwort oder (noch wilder) Server werden aus der Domäne genommen…) Tipp: Hier hilft das PowerShell-Cmdlet “Repair-SPManagedAccountDeployment“.
  7. SharePoint- und Betriebs-Administratoren nach ihren letzten administrativen Tätigkeiten fragen (auch wenn man die Antwort “Ich habe gar nichts gemacht…” schon vorher kennt – Tipp: Erinnerungslücken verflüchtigen sich bei einer gemeinsamen Kaffeepause.).
  8. Falls es sich um komponentenspezifische Probleme handelt (also wenn bspw. das eigens erstellte WebPart Fehler anzeigt), kann das Aktivieren des Developer Dashboards oder das Anzeigen von internen Server-Fehlermeldungen weiterhelfen (web.config für Debug-Mode anpassen: CallStack auf “True”, CustomErrors auf “Off” und Compilation-Debug auf “True” setzen > Damit ist dann natürlich auch das Debuggen mit Visual Studio möglich).
  9. Meinen Blog mit dem Tag “Troubleshooting” durchsuchen. (Es sind ja meine Top 10… ;-))
  10. Mit Hilfe der zur Verfügung stehenden Informationen im Internet suchen. (Tipp: Wenn möglich immer mit englischsprachigen Worten/Fachbegriffen suchen.)
Dieser Beitrag wurde unter Microsoft, SharePoint 2010 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Eine Antwort auf SharePoint 2010 Troubleshooting – Meine Top 10 bei der Fehleranalyse

  1. Axel sagt:

    Wictor Wilen hat übrigens einen ähnlichen Beitrag geschrieben (The Rules of SharePoint Troubleshooting). Erwähnenswert finde ich dabei die Tatsache, dass er die Hilfe der Communities hervorhebt. (Ich persönlich würde dabei aber raten, Lösungsvorschläge aus der Community nicht blind zu vertrauen.)

    Sehr interessant finde ich auch den Kommentar, dass man das PowerShell-Cmdlet Merge-SPLogFile nutzen könne, um die ULS-Logs großer Farmen zusammenzutragen.

Hinterlasse einen Kommentar zu Axel Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>