SBS 2011, Sharepoint, Kennwörter und Probleme


Veröffentlicht von MOS-Computer GbR am 15.05.2012

 

 

Die Ausgangsbasis ist ein SBS 2011 System, das seit etlichen Monaten perfekt läuft. In den Gruppenrichtlinien, sowie in den Kontoeinstellungen aller Systemkonto ist das Ablaufen von Kennwörtern für Konten deaktiviert.

Nach einigen Monaten trat das Problem auf, dass das Systemprotokoll meldete, dass der Sharepoint Timer Dienst nicht mehr laufen würde. Dieser nutzt das Systemkonto "spfarm". Die anderen Dienste, die ebenfalls dieses Konto nutzen, liefen erstaunlicherweise aber noch. Eine kurze Analyse ergab, dass die Kontendaten nicht mehr stimmten (falsches Passwort). Dies war insofern erstaunlich, da, wie oben erwähnt, der Ablauf von Kennwörtern unterbunden wurde.

Sharepoint wird auf dem genannten System zwar nicht aktiv genutzt, dennoch ist es natürlich unschön, wenn nun alle 30 Minuten eine Fehlermeldung im Protokoll auftaucht. In aller Regel haben solche Vorkommnisse auch noch Folgeerscheinungen, weshalb man sich besser darum kümmern sollte.

 

Bei Sharepoint reicht es nicht, das Kennwort des Kontos im AD zurückzusetzen. Dies muss auch mit Sharepoint synchronisiert werden. Eine Übersicht und Anleitung gibt dazu der folgende Artikel:

HTTP Error 503 Accessing Company Web on SBS 2011 Standard - The Official SBS Blog.

 

Dieser ist insofern meist zutreffend, da in aller Regel, wenn etwas mit den Sharepoint Diensten nicht stimmt (z.B. abgelaufene Kennwörter), auch die Sharepoint Seite nicht mehr erreichbar ist.

 

Wir öffnen also die Sharepoint Powershell und geben folgenden Befehl ein:

Set-SPManagedAccount -UseExistingPassword -Identity $env:<domain>\spfarm

 

Das führte allerdings in unserem Fall nicht zum gewünschten Ergebnis, sondern zu der folgenden Fehlermeldung:

Set-SPManagedAccount : Mindestens ein Fehler beim Bereitstellen von Anmeldeinformationen für den Administrationsanwendungspool. Überprüfen Sie das Anwendungsereignisprotokoll, und beheben Sie den Fehler manuell. Dateiname: \\?\C:\Windows\system32\inetsrv\config\applicationHost.config
Fehler: Die Konfigurationsdatei kann nicht geschrieben werden.
Bei Zeile:1 Zeichen:21
+ Set-SPManagedAccount <<<< -UseExistingPassword -Identity $env:<domain>\spfarm
+ CategoryInfo : InvalidData: (Microsoft.Share...tManagedAccount:
SPCmdletSetManagedAccount) [Set-SPManagedAccount], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletSetManagedAccount

 

Was es damit auf sich hat, wird auch leider im obigen Artikel nicht abgedeckt.

 

Auch mehrmaliges Ausführen brachte keine Besserung. Daher wurde folgendes ausgeführt, um es evtl. danach noch mal zu versuchen:

IISReset /noforce

 

Das hatte allerdings zur Folge, dass im Systemprotokoll nun etliche Fehler auftauchten und eine ganze Hand voll Dienste nicht mehr liefen:

 

1)
Der Dienst "WWW-Publishingdienst" auf "Lokaler Computer" konnte nicht gestartet werden.
Fehler 1068: Der Abhängigkeitsdienst oder die Abhängigkeitsgruppe konnte nicht gestartet werden.

2)
Der Dienst "Windows-Prozessaktivierungsdienst" auf "Lokaler Computer" konnte nicht gestartet werden.
Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren.

3)
Der Dienst "Remotedesktopgateway" auf "Lokaler Computer" konnte nicht gestartet werden.
Fehler 1068: Der Abhängigkeitsdienst oder die Abhängigkeitsgruppe konnte nicht gestartet werden.

 

Ergebnis: IIS rennt nicht mehr und damit eingeschlossen OWA, WSUS, ActiveSync, Sharepoint.....

 

Bei der Suche nach einer Lösung wurden wir leider nicht wirklich fündig. Wir suchten Richtung Sharepoint, da dies ja offensichtlich Auslöser des Problems war und alles andere nur Folgeerscheinungen. Falsch gedacht.

 

Ein Supportcall bei Microsoft führte schlussendlich zum Erfolg! Die Wurzel allen übels war nicht Sharepoint, sondern liegt im "Windows-Prozessaktivierungsdienst". Da dieser Dienst nicht mehr lief, war alles andere auch zum Scheitern verurteilt.

Hilfreich in diesem Zusammenhang ist der folgende Artikel:

IIS services fail to start: "Windows could not start the Windows Process Activation Service - Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error" when WAS service is started

 

Die Ausführung des Befehls:

fsutil resource setautoreset true <systemdrive>:\

 

mit einem anschliessenden Neustart löste sofort alle Probleme! Die Dienste fuhren wieder hoch und der Server war wieder voll funktional! Das Problem war also ein korruptes Transaktionsprotokoll.

 

Danach liess sich auch mit dem oben aufgeführten Befehl das Kennwort in Sharepoint ändern, ohne dass es noch einmal zu einer Fehlermeldung kam.

Warum das Kennwort allerdings ablief, konnte auch Microsoft (trotz Überprüfung) auf die schnelle nicht klären und tippte auf eine Komplikation mit einem Update in Bezug auf Sharepoint.

Desweiteren wurde empfohlen, den fsutil Befehl grundsätzlich auf Servern zu verwenden, um Probleme mit dem Transaktionsprotokoll zu umgehen.

 

Problem gelöst!

 

 

 

Das könnte Sie vielleicht auch interessieren:

 



Zurück