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:
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:
- SBS 2011: WSUS Wartung #2 - Cleanup Abbruch
- SBS 2011: CertLog verkleinern
- SBS 2011: Connector für Windows 10
- Exchange 2010: Keine Verbindung zur Datenbank
- SBS 2011: Support Lösungen
- SBS 2011: Automatischer BPS Scan Fehler
- SBS 2011 und Arbeitsgruppe
- SBS 2011: Berichte anpassen
- SBS 2011: DHCP und Subnetzmaske
- SBS 2011 und Zertifikate
- SBS 2011 und Sharepoint 2010
- SBS 2011 und Datenträgerbereinigung
- Windows Update: Leere Liste bei Auswahl
- SBS 2011 Konsole: Falsche Anzeige
- Sharepoint 2010 SP1 Fehler
- Exchange 2010: OWA Fehler nach Update
- XP Mode und Netzlaufwerke
- SBS 2011 und DCOM 10009
- Keine Rechner in der Netzwerkumgebung
- ABR11, Tapes und mögliche Probleme
- AVG 2012 und SBS 2011
Zurück