Welche SharePoint-Server-Fehlermeldung bedeutet was – und welche Dienstabhängigkeit steckt dahinter?

SharePoint-Architektur und Abhängigkeitsketten: IIS/HTTP, Service Instances, Service Applications, SQL-Datenbanken, AD und Zertifikate als Fehlerursache

SharePoint Server verhält sich im Betrieb wie ein Verbund aus Webschicht, Farmdiensten und Datenhaltung. Fehlerbilder entstehen selten isoliert: Ein HTTP-Fehler am Web-Frontend kann aus einer SQL-Blockade resultieren, eine Suchstörung kann durch fehlende Zertifikatsvertrauensstellungen ausgelöst werden, und Authentifizierungsprobleme im IIS erscheinen häufig als generische SharePoint-Ausnahmen. Das Verständnis der Abhängigkeitsketten ist deshalb entscheidend, um Meldungen korrekt der verursachenden Komponente zuzuordnen und Kaskadeneffekte zu erkennen.

Web-Frontend-Kette: Client → HTTP.sys → IIS → SharePoint (W3WP) → Service-Backends

Der Pfad einer Benutzeranfrage beginnt auf dem Web-Frontend (WFE) bei HTTP.sys und endet typischerweise im IIS-Workerprozess (w3wp.exe) des zugehörigen Application Pools. Dort übernimmt die SharePoint-Requestpipeline (u. a. ASP.NET, Claims- und Kontextaufbau, Routing in die Site/Web-Kontexte). Bereits auf dieser Strecke können identische Symptome unterschiedliche Ursachen haben: Ein HTTP 503 Service Unavailable deutet häufig auf einen gestoppten Application Pool, fehlende Ressourcen oder einen Crash des Workerprozesses hin, während HTTP 401 oft aus Authentifizierungs- oder SPN/Kerberos-Problemen entsteht. Fehler, die in SharePoint als „Unerwarteter Fehler“ erscheinen, sind häufig nur die UI-Oberfläche für tiefer liegende Exceptions im ULS-Log und in der Windows-Ereignisanzeige.

SharePoint unterscheidet Webanwendungen (IIS-Sites mit Bindings und Zonen), Content-Datenbanken (SQL) und die Farmkonfiguration (Konfigurationsdatenbank). Ein WFE bleibt zwar grundsätzlich stateless, ist aber faktisch abhängig von stabilen SQL-Verbindungen, funktionierenden Service-Anwendungs-Endpunkten und korrekter Authentifizierung gegen Active Directory. Werden diese Abhängigkeiten unterbrochen, erscheinen Fehler häufig in der Webschicht, obwohl der Ursprung in SQL, Netzwerk, DNS oder Zertifikatketten liegt.

Service Instances vs. Service Applications: lokale Ausführung und logische Bereitstellung

Eine Service Instance ist die lokale Ausprägung eines Farmdienstes auf einem konkreten Server (z. B. „Search Service“, „User Profile Service“, „Distributed Cache“). Eine Service Application ist die logisch bereitgestellte Dienstinstanz, die über Service Application Proxy Groups an Webanwendungen gekoppelt wird. Fehlersymptome wirken deshalb oft „verschoben“: Ein Web-Frontend kann korrekt laufen, aber dennoch 503– oder Timeout-Symptome zeigen, wenn ein auf Applikationsservern gehosteter Dienstendpunkt nicht erreichbar ist oder die zugehörige Datenbank blockiert.

Typische Kaskaden entstehen, wenn eine Service Application nicht nur von SQL abhängt, sondern zusätzlich von AD-Abfragen, Zertifikatsvalidierung oder Timer-Jobs. Ein gestörter Timer Job kann Konfigurationsstände nicht aktualisieren; daraus können veraltete Endpunktadressen, fehlerhafte Bereitstellungszustände oder inkonsistente Proxy-Zuordnungen resultieren. In solchen Lagen sind ULS-Korrelationen besonders wichtig, weil die Webschicht nur den finalen Fehlerzustand zeigt.

SQL-Datenbanken als Dreh- und Angelpunkt: Konfiguration, Inhalte, Service-Daten

SharePoint verteilt Zustände auf mehrere SQL-Datenbanken. Die Konfigurationsdatenbank steuert Farmobjekte, Serverrollen, Timer-Job-Definitionen und Dienstzuordnungen; Content-Datenbanken enthalten Websitestrukturen, Listeninhalte und Sicherheitsdeskriptoren; Service-Application-Datenbanken speichern dienstspezifische Indizes oder Metadaten. Fällt SQL aus oder ist nur partiell erreichbar, verschieben sich Fehlermeldungen entlang der Kette: Webanwendungen melden vermeintliche Rendering-Probleme, während die eigentliche Ursache ein Verbindungsabbruch, ein Login-Problem des Farmkontos oder ein blockierender SQL-Thread ist.

Die Schwere des Symptoms hängt davon ab, welche Datenbank betroffen ist. Bei Problemen mit der Konfigurationsdatenbank brechen Farmoperationen, Topologieermittlung und Teile der Administration aus. Bei Content-Datenbanken sind einzelne Webanwendungen oder Site Collections betroffen. Bei Service-Datenbanken wirkt der Ausfall häufig funktionsspezifisch (Suche, User Profile, Managed Metadata), kann aber wiederum in der Webschicht sichtbar werden, sobald eine Seite entsprechende Dienste konsumiert.

Active Directory, Authentifizierung und Identitäten: Kerberos/NTLM, Claims und Gruppenauflösung

SharePoint stützt sich für Identitäten auf Windows/AD und die gewählte Authentifizierung der Webanwendung. Kerberos erfordert korrekte SPNs, Delegation und DNS-Auflösung; bei Fehlern erfolgt häufig ein Fallback oder ein harter Abbruch, der sich im Browser als HTTP 401 (wiederholte Anmeldeaufforderung) oder als HTTP 403 äußert. Unabhängig vom Protokoll hängt die Autorisierung an konsistenter Gruppenauflösung. Wenn Domain Controller nicht erreichbar sind oder Namensauflösung fehlschlägt, erscheinen Berechtigungsprobleme als SharePoint-seitige „Zugriff verweigert“-Ereignisse, obwohl die Rechte im SharePoint-UI korrekt gesetzt sind.

Viele Dienstkomponenten führen zusätzlich AD-Abfragen im Hintergrund aus (z. B. Profilimporte, Crawls gegen gesicherte Quellen). Dadurch können AD-Störungen indirekt zu Diensttimeouts führen. Solche Kaskaden sind typisch: ein Profilimport hängt, der Suchcrawler bekommt keine stabilen Identitäten, und im UI werden People-Search oder Zielgruppenfunktionen inkonsistent.

Zertifikate, TLS und Vertrauensstellungen: häufige Ursache für „unerklärliche“ Dienstabbrüche

In modernen SharePoint-Topologien sind Zertifikate nicht nur für HTTPS-Webbindungen relevant, sondern auch für die Dienst-zu-Dienst-Kommunikation über WCF/HTTP(S) sowie für Token- und Vertrauensbeziehungen, abhängig von Authentifizierungsdesign und Feature-Nutzung. Fehler entstehen, wenn private Schlüssel fehlen, Zertifikate ablaufen, Zwischenzertifikate nicht verteilt sind oder die Vertrauenskette auf Servern unterschiedlich ist. Die Wirkung ist häufig nicht lokal begrenzt: Ein Applikationsserver mit gebrochener Trustchain kann Dienstendpunkte nicht bedienen; Web-Frontends melden dann Timeouts, HTTP 500 oder Authentifizierungsfehler, obwohl ihre eigenen Zertifikate gültig sind.

• Schnelle Kettenprüfung (Webschicht): Test-NetConnection -ComputerName <sqlhost> -Port 1433
iisreset /status
Get-WebAppPoolState -Name "SharePoint - 80"
• Service- und Proxy-Zuordnung (Farm): Get-SPServiceInstance | Select TypeName,Server,Status
Get-SPServiceApplication | Select DisplayName,TypeName
Get-SPServiceApplicationProxy | Select DisplayName,Status
• SQL-Verbindungsidentität (typischer Stolperstein): Get-SPDatabase | Select Name,Type,Server,Status
• Zertifikatszustand auf dem Server: Get-ChildItem Cert:\LocalMachine\My | Select Subject,Thumbprint,NotAfter
Get-ChildItem Cert:\LocalMachine\Root | Select Subject,Thumbprint

Für die Ursachenanalyse ist die Zuordnung „wo tritt der Fehler auf“ vs. „wo entsteht er“ zentral. Web-Fehlerseiten lokalisieren die Störung selten präzise. Erst die Auflösung entlang der Abhängigkeiten – IIS-Health, Service-Instanzen, Proxy-Kopplungen, SQL-Erreichbarkeit, AD-Funktion und Zertifikatvertrauen – ermöglicht eine belastbare Diagnose, ohne einzelne Symptome als Primärursache zu missdeuten.

Fehlermeldungen und Protokolle systematisch zuordnen: Web-Frontend (HTTP 401/403/404/500, 503), ULS/Correlation ID, Event Log, Health Analyzer, Timer Service und Konfigurationsdatenbank

SharePoint-Fehler wirken im Web-Frontend oft wie reine HTTP-Probleme, entstehen jedoch häufig durch Dienstabhängigkeiten (Service Applications), Identität/Claims, SQL-Verbindungen oder Konfigurationsdaten in der Farm. Eine belastbare Zuordnung beginnt daher nicht mit dem sichtbaren Browserfehler, sondern mit einer sauberen Kette aus Zeitstempel, Ziel-URL, betroffener Webanwendung, Anwendungs-/Dienstkonto und Correlation ID. Erst danach lassen sich ULS, Windows Event Log, Health Analyzer und Timer Service zielgerichtet lesen, ohne Symptome mit Ursachen zu verwechseln.

Web-Frontend: HTTP-Statuscodes präzise lesen (401/403/404/500/503)

Im SharePoint-Stack terminieren HTTP-Antworten am IIS (HTTP.SYS, Application Pool, W3WP), werden aber semantisch oft durch SharePoint-Komponenten geprägt. Ein 401 deutet auf fehlgeschlagene Authentifizierung oder fehlende Token-Ausstellung hin, ein 403 auf erfolgreiche Authentifizierung mit verweigerter Autorisierung. 404 kann sowohl eine echte Nicht-Existenz im IIS (fehlende Site/Bindings) als auch eine SharePoint-Auflösung sein (z. B. nicht gemappter Managed Path, gelöschte Datei, falscher Alternate Access Mapping). 500 steht typischerweise für ungefangene Ausnahmen im SharePoint Request Pipeline (SPRequest/SPHttpApplication), häufig ausgelöst durch Datenbank- oder Service-Abhängigkeiten. 503 wird vom IIS ausgegeben, wenn der Application Pool gestoppt ist, wiederholt crasht (Rapid-Fail Protection) oder die Warteschlange/Workerzuordnung scheitert; SharePoint selbst kann in diesem Fall bereits gar nicht mehr loggen, sodass IIS- und Systemereignisse Vorrang erhalten.

ULS und Correlation ID: vom Symptom zur Ausnahmequelle

Die SharePoint Unified Logging Service (ULS)-Logs sind die primäre Quelle für die interne Fehlerursache, sofern der Request überhaupt den SharePoint-Code erreicht. Entscheidend ist die Correlation ID aus der Fehlerseite (oder aus Developer Dashboard/Reverse Proxy Logs). Diese GUID identifiziert den Requestpfad quer über Kategorien wie SharePoint Foundation, Claims Authentication, Database, Search oder Service Application Framework. Typische Fehlerseiten zeigen den Wortlaut An unexpected error has occurred. und Correlation ID: <GUID>; die technische Bedeutung ist stets: eine Ausnahme wurde gefangen und in ULS mit genau dieser ID protokolliert, inklusive Stacktrace, SQL-Fehlercode, betroffener Farmkomponente und häufig dem exakten Datenbanknamen.

Bei 500-Fehlern sollte der ULS-Eintrag mit Level Unexpected oder Critical als Anker dienen; Einträge mit High in unmittelbarer zeitlicher Nähe liefern oft die vorgelagerten Ursachen (z. B. Authentifizierungswarnungen oder Datenbankverbindungsabbrüche). Für 401/403-Konstellationen sind ULS-Kategorien wie Claims Authentication, Authentication Authorization und Runtime relevanter als generische Foundation-Logs, weil dort Token-Ausstellung, Benutzerauflösung und Access Checks protokolliert werden.

• Correlation ID finden (Fehlerseite): Wortlaut Correlation ID: 1b7b7b7b-1234-4567-890a-bcdef0123456 als Suchschlüssel für ULS und Event Log.
• ULS-Logpfad (Standard): %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS bzw. ...\15\LOGS je nach Hauptversion.
• Gezieltes Filtern im ULS Viewer: Suche nach Correlation und danach Eingrenzung auf Level Unexpected, anschließend Prüfung der vorherigen Einträge mit Level High innerhalb desselben Zeitfensters.
• Typische ULS-Indikatoren für SQL-Abhängigkeiten: Fehltexte wie Timeout expired, Cannot open database, Login failed for user oder The server was unable to complete the request mit SQL Error Number im Detailfeld.

Windows Event Log: IIS, .NET Runtime, SharePoint und SQL-Signalwege

Das Windows Event Log ergänzt ULS um Infrastruktur- und Prozessereignisse, die SharePoint nicht oder nur indirekt sieht. Für 503-Fehler sind System (Service Control Manager), Application (IIS, .NET Runtime) und Microsoft-Windows-IIS-W3SVC/Operational entscheidend: Stoppt ein Application Pool, protokolliert IIS den Grund (z. B. Rapid-Fail, Identity-Startfehler). .NET Runtime-Ereignisse weisen auf W3WP-Abstürze, fehlende Assemblies oder Konfigurationsfehler hin. SharePoint-spezifische Ereignisse in Application und unter Applications and Services Logs (je nach Version/Feature) liefern ergänzende Hinweise, ersetzen jedoch nicht die ULS-Diagnose.

Eine wiederkehrende Fehlerklasse ist die Kaskade „SQL kurzzeitig nicht erreichbar → Timer Jobs/Requests bekommen Timeouts → W3WP-Überlast → App Pool Recycle → 503“. In dieser Kette zeigen Event Logs meist zuerst Netzwerk-/SQL-Indikatoren (Timeouts, Login-Fails), danach IIS- und .NET-Symptome. Deshalb sollte die Auswertung stets chronologisch erfolgen, nicht nach Komponentenzuständigkeit.

Health Analyzer: Regeln, die Dienstabhängigkeiten sichtbar machen

Der Health Analyzer bewertet Farmzustand über Regeln, die Konfiguration, Service-Instanzen, Zertifikate, Datenbanken und Patch-Level prüfen. Warnungen sind keine „Fehlermeldungen“ im Request-Sinn, sie markieren aber oft die Vorbedingungen für spätere 500– und Suchprobleme: gestoppte Dienste, nicht erreichbare Service Applications, fehlende oder schreibgeschützte Datenbanken, inkonsistente Serverrollen. Da Health Analyzer-Checks zeitgesteuert laufen, ist der Zeitbezug wichtig: eine Regel kann Minuten oder Stunden vor dem ersten sichtbaren Webfehler anschlagen.

• Regelquelle: Zentraladministration unter Überwachung sowie zugehörige Einträge in ULS (häufig Kategorie Health Analyzer).
• Typischer Befund bei Datenbankproblemen: Inhalte-/Konfigurationsdatenbanken melden Database is in compatibility range oder Erreichbarkeits-/Schreibfehler; Ursache liegt meist in SQL-Rechten, SQL-Dienstverfügbarkeit oder Storage.
• Typischer Befund bei Dienstinstanzen: Dienstinstanz auf Server A gestoppt, obwohl die zugehörige Service Application aktiv ist; Folge sind kaskadierende Timeouts in Webrequests und Timer Jobs.

Timer Service (SPTimerV4) und Konfigurationsdatenbank: wenn Jobs die Farm „mitziehen“

Der SharePoint Timer Service (SPTimerV4) führt Farmaufgaben asynchron aus: Health Analyzer Jobs, Service-Application-Aufgaben, Cache-Invaliderungen, Suchkomponenten-Aufrufe und viele Betriebsprozesse. Fehler in Timer Jobs tauchen primär in ULS auf und korrelieren oft mit Problemen in der Konfigurationsdatenbank. Die Konfigurationsdatenbank ist die zentrale Quelle für Farm-Topologie, Server, Dienste, Service Applications und deren Zuordnungen; wenn sie nicht erreichbar ist oder inkonsistente Einträge liefert, wirken sich Störungen nicht nur auf Administration, sondern auch auf Webrequests aus (z. B. wenn Proxy-Gruppen oder Service-Endpunkte nicht aufgelöst werden können).

Typische Anzeichen für Konfigurationsdatenbank-Abhängigkeiten sind ULS-Einträge, die beim Laden von Farmobjekten scheitern oder wiederkehrende SQL-Timeouts beim Lesen von Konfigurationsdaten zeigen. In der Praxis äußert sich das als gemischtes Fehlerbild: Zentraladministration reagiert langsam oder liefert 500, Webanwendungen zeigen sporadische Fehler, und Health Analyzer meldet parallel mehrere scheinbar unabhängige Probleme. In solchen Fällen ist die „gemeinsame Klammer“ fast immer die Erreichbarkeit von SQL, die Stabilität der Authentifizierung des Farmkontos gegenüber SQL und die Fähigkeit der Server, konsistent auf Konfigurationsobjekte zuzugreifen.

• Dienststatus prüfen (Windows): services.msc bzw. Get-Service SPTimerV4 zur Verifikation, ob der Timer Service läuft und nicht wiederholt startet/stoppt.
• Timer-Job-Fehlerbild (ULS): Einträge mit Bezug zu OWSTIMER.EXE und Level Unexpected sowie SQL-Indikatoren wie Timeout expired oder Login failed.
• Konfigurationsdatenbank als Ursache klassifizieren: Wiederholte Fehler bei der Auflösung von Farm-/Service-Objekten, häufig mit Hinweisen auf SharePoint_Config (Name variabel) und fehlgeschlagene SQL-Verbindungen.

Typische Störungscluster mit exakten Meldungen: Suche (Crawl/Query/Topology), Authentifizierung und Berechtigungen, Service-Application- und Timer-Job-Fehler, SQL- und Patch-/Upgrade-Probleme samt Kaskadeneffekten

SharePoint-Störungen treten selten isoliert auf. Ein Ausfall in SQL Server, ein falsch konfigurierter Dienstaccount oder ein unvollständig angewendetes Update erzeugt häufig Folgemeldungen in ULS, der Windows-Ereignisanzeige, in Service-Application-Health-Reports und im SharePoint Health Analyzer. Besonders aussagekräftig sind Meldungen, die eine konkrete Komponente benennen (z. B. Suchkomponente, Service Application, Datenbank oder IIS-AppPool) und einen stabilen Fehlercode tragen. Die folgenden Cluster zeigen typische Kaskaden, jeweils mit exakten Wortlauten/IDs und einer eindeutigen Zuordnung zur verursachenden Ebene.

Suche: Crawl-, Query- und Topology-Fehler (häufige Kaskaden über Host Controller, Index und SQL)

Der Suchdienst besteht aus mehreren getrennten Prozessen und Komponenten (Crawl, Content Processing, Analytics Processing, Index, Query Processing, Admin) sowie dem SharePoint Search Host Controller als Prozessstarter. Fehler eskalieren schnell: Fällt der Host Controller aus, starten Suchkomponenten nicht; fehlen Zertifikate/ACLs, scheitert die Kommunikation; bei SQL-Latenzen brechen Crawl- und Admin-Aufgaben ab und die Topologie wird „degraded“. Besonders kritisch sind Meldungen, die auf einen nicht erreichbaren Search Service Application-Endpunkt, einen defekten Index oder eine nicht mehr konsistente Topologie hindeuten.

• Query-Kanal (Ursache: Suchkomponenten/Topology): „The search service is not available.“ – typischer Frontend-Fehler bei Query-Requests; häufig Folge einer nicht gestarteten Query Processing-Komponente oder eines nicht erreichbaren Search Service Application-Endpunkts.
• Host Controller (Ursache: Windows-Dienst/Serverzustand): „The SharePoint Search Host Controller service is not running.“ – blockiert das Hochfahren der Suchkomponenten; häufig kombiniert mit Ereignisanzeige-Einträgen zum Dienst OSearch15/OSearch16 (versionsabhängig) und nachgelagerten Topology-Fehlern.
• Topology (Ursache: Suchverwaltung/Config-Store): „The search topology is in a degraded state.“ – signalisiert, dass mindestens eine Komponente fehlt, down ist oder nicht konsistent provisioniert wurde; führt oft zu intermittierenden Query-Timeouts und Crawl-Stillstand.
• Index (Ursache: I/O, Rechte, Index-Dateien): „Index is corrupt.“ bzw. sinngemäß korruptionsbezogene ULS-Meldungen – erzwingt meist Rebuild/Neuprovisionierung der Index-Komponente; Folgefehler sind 0 Treffer, hohe Query-Latenzen oder „Search service not available“.
• Crawl/Content Sources (Ursache: Auth/HTTP/Timeout): „Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))“ – häufig beim Abruf von Inhalten; Ursache liegt oft in fehlenden Rechten des Crawl-Accounts auf Zielsystemen oder in Kerberos/NTLM-Problemen.

Authentifizierung und Berechtigungen: Claims, Kerberos/NTLM, Token- und Gruppenauflösung

Authentifizierungsprobleme zeigen sich oft zuerst als scheinbar generische Web-Frontend-Fehler, obwohl die Ursache in AD, SPNs, fehlenden Rechten auf SQL oder in fehlerhaften Token-Transformationen liegt. SharePoint nutzt Claims-basiertes Authentifizieren; der Security Token Service (STS) stellt Tokens aus, IIS und die Webanwendung setzen die gewählte Authentifizierung (Windows, SAML/OIDC über ADFS/Entra ID, FBA) durch. Fällt ein Bindeglied aus, entstehen häufig 401/403-Ketten, Login-Schleifen oder „Zugriff verweigert“-Meldungen in UI und ULS.

• IIS/HTTP (Ursache: Auth-Modus/Provider): 401 Unauthorized bzw. HTTP Error 401.2 - Unauthorized – typisch bei falscher IIS-Authentifizierung (z. B. deaktiviertes Windows Authentication), fehlenden SPNs bei Kerberos oder ungeeigneter Providerreihenfolge.
• SharePoint UI (Ursache: Autorisierung): „Access denied.“ – entsteht nach erfolgreicher Authentifizierung bei fehlenden SharePoint-Rechten; häufig korreliert mit ULS-Einträgen aus Authorization/Claims Authentication.
• HRESULT (Ursache: Rechte/Token/COM): „Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))“ – tritt in vielen Kontexten auf (Crawl, Timer Jobs, Service Apps) und weist auf fehlende Berechtigungen des ausführenden Kontos (Farmkonto, Dienstkonto, AppPool-Identität) oder DCOM/Dateisystem-ACLs hin.
• SQL-Anmeldung (Ursache: Dienstkonto/Delegation): „Login failed for user 'DOMAIN\user'.“ – SQL Server meldet fehlgeschlagene Authentifizierung; Folge sind Web-Frontend-Ausfälle, Service-Application-Fehler und oft Health-Analyzer-Warnungen zu Datenbankverbindungen.

Service Applications und Timer Jobs: Provisioning, Berechtigungen, Konfigurationsdrift

Service Applications kapseln Funktionen (z. B. User Profile, Managed Metadata, Search, BCS) und hängen von Anwendungs-Pools, Zertifikaten, SQL-Datenbanken und dem Farm-Konfigurationszustand ab. Timer Jobs orchestrieren wiederkehrende Aufgaben über den SharePoint Timer Service (OWSTIMER). Fällt OWSTIMER aus oder besitzt das Farmkonto nicht die erwarteten Rechte, häufen sich „Job failed“-Ereignisse. Häufig verstärken sich Fehler: Ein Service-Application-Ausfall erzeugt Timer-Job-Fehler; die Timer-Job-Fehler verhindern Reparaturläufe; der Health Analyzer meldet daraufhin Sekundärwarnungen.

• Timer Service (Ursache: Windows-Dienst/Serverressourcen): „The SharePoint Timer Service is not running.“ – zentrale Ursache für breite Funktionsstörungen; Folge sind ausbleibende Wartungsjobs, nicht ausgeführte Synchronisationen und verzögertes Provisioning.
• Timer Job History (Ursache: Job/Dependency): „Job failed.“ – generischer Status in der Job-Historie; zur Auflösung ist der korrelierende ULS-Eintrag entscheidend (Correlation ID) und die Zuordnung zu Service Application, Webanwendung oder Farm-Aufgabe.
• Konfiguration/Provisioning (Ursache: fehlende Objekte/Berechtigungen): „File Not Found.“ im Kontext von Service-Endpoints oder „Cannot open database ... requested by the login.“ – typisch, wenn eine Service-DB offline/umbenannt ist oder Berechtigungen nach Restore/Failover fehlen; häufig gefolgt von UI-Fehlern in Zentraladministration.
• Diagnose (Zuordnung über Korrelation): Get-SPLogEvent -Correlation "GUID"
Merge-SPLogFile -Correlation "GUID" -Path "C:\Temp\uls.txt" – grenzt den verursachenden Job/Thread ein und zeigt die erste Ausnahme („first failure“) vor den Folgefehlern.

SQL- und Patch-/Upgrade-Probleme: Datenbankabhängigkeiten, Build-Mismatch, Konfigurationsdatenbank

SQL-Probleme wirken in SharePoint selten nur als „Datenbank nicht erreichbar“. Bereits kurze Verbindungsabbrüche oder Loginsperren führen zu Authentifizierungsfehlern, Service-Application-Ausfällen und schließlich zu Web-Frontend-Fehlerseiten. Patch- und Upgrade-Störungen entstehen häufig durch Build-Mismatch zwischen Servern, nicht vollständig ausgeführte Konfigurationsassistentenläufe oder blockierende Timer Jobs. Charakteristisch sind Meldungen, die auf ein Versionierungsproblem der Farm oder auf fehlende Schema-/Feature-Upgrades von Content-Datenbanken hinweisen. In solchen Situationen erscheinen kaskadierend „Service not available“, „File Not Found“ und 500-Fehler, obwohl die Primärursache im Datenbank- oder Patchzustand liegt.

• SQL-Verbindung (Ursache: Netzwerk/SQL/Firewall): „A network-related or instance-specific error occurred while establishing a connection to SQL Server.“ – typischer SQL Client-Fehler (Provider/Netzwerk); nachgelagert schlagen nahezu alle Service-Calls fehl, einschließlich Authentifizierung gegen Konfigurations- und Inhaltsdatenbanken.
• SQL Timeout (Ursache: Last/Blocking): „Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.“ – führt zu sporadischen 500-Fehlern, abgebrochenen Timer Jobs und instabiler Zentraladministration; häufig gekoppelt an Blocking in tempdb oder auf SharePoint-DBs.
• Build-/Patchzustand (Ursache: Upgrade unvollständig): „Database schema is too old and needs to be upgraded.“ – Content- oder Service-Datenbank passt nicht zum Farm-Build; typische Folge sind Feature-Aktivierungsfehler, nicht ladende Websites oder deaktivierte Dienste bis zum erfolgreichen Upgrade-Prozess.
• Konfigurationsassistent/Upgrade (Ursache: fehlerhafte Ausführung): „Configuration failed.“ (im Kontext des Products Configuration Wizard) – steht häufig für eine zugrunde liegende Ausnahme (z. B. SQL-Rechte, Timer Service, gesperrte Dateien), die in ULS und Ereignisanzeige detailliert protokolliert ist.
• SQL-Berechtigungen nach Restore/Failover (Ursache: fehlendes Mapping): „The server principal "DOMAIN\account" is not able to access the database ... under the current security context.“ – weist auf fehlende Datenbank-Benutzerzuordnung oder falsche Eigentümer hin; Folge ist ein breites Spektrum an Service- und UI-Fehlern, oft mit 0x80131904 als .NET SQL Exception.