Ja ich weiß, eigentlich ist das ein alter Hut und ein übliches Problem wenn versucht wird die Benutzerprofildienstanwendung zu starten. Es gibt hierzu auch unzählige Blogbeiträge, die sich genau mit diesem Problem beschäftigen und in 99% der Fälle auch helfen sollten.
Die erste Anlaufstelle ist wohl immer http://www.harbar.net/articles/sp2010ups2.aspx. Hier werden unzählige Möglichkeiten aufgezählt, was alles schiefgegangen sein könnte, wenn die Benutzerprofildienstanwendung nicht starten möchte. Was passiert aber, wenn diese Lösungsvorschläge nicht helfen? Genau: Man bemüht eine Suchmaschine seiner Wahl und versucht so dem „Stuck on starting“ Problem auf die Spur zu kommen. In meinem Fall war es nun leider so, dass mich sämtliche Suchergebnisse der ersten beiden Seiten (egal ob Bing oder Google) der Lösung kein Stück näher gebracht haben. Ich musste zudem ein Szenario beobachten, dass ich so noch nicht gesehen habe – aber der Reihe nach.
Zuerst ein paar Details zu meiner Infrastruktur:
– SharePoint 2010 inkl. April 2012 CU
– Windows Server 2008 R2
– SQL Server 2012 RC0
– Entwicklungsmaschine (alles auf einem Server)
Geplant war eine frische Installation, die man zu jeder Zeit problemlos erweitern kann. Dementsprechend wurde nur die Suchdienstanwendung konfiguriert (keine Probleme) und danach die Benutzerprofildienstanwendung (Probleme…). Alles andere soll weggelassen werden.
Initiales Vorgehen:
Schritt 1: Start des User Profile Service in der Zentraladministration (Ergebnis: Erfolg)
Schritt 2: Anlegen der Profildienstanwendung (Ergebnis: Erfolg & Seite aufrufbar)
Schritt 3: Start des des User Profile Synchronization Services (Ergebnis: „Starting„)
Schritt 4: Eine Stunde warten -> kein Erfolg. Der Synchronisierungsdienst verweilt im Status „Starting“
Initiale Namen der Datenbanken (wird später nochmal wichtig):
Profile: SharePoint2010_Profile_DB
Sync: SharePoint2010_ Sync_DB
Social: SharePoint2010_Social_DB
Troubleshooting:
Alle Angaben hier wurden mehrfach in verschiedensten Reihenfolgen wiederholt. Nur um einen kleinen Einblick in meine Versuche zu geben:
– Rechte prüfen (ging schnell, da alles auf einem Account lief…)
– dedizierte Accounts anlegen und damit versuchen
– Profildienstzertifikate löschen
– SharePoint Dienste stoppen und neu starten
– Windows Dienste stoppen und neu starten (soll man nicht tun… hat mir aber geholfen das Problem zu lösen)
– Server neu starten
– Profildienst neu anlegen (inkl. neuer DBs mit neuen Namen: „SocialDB“, „SyncDB“, „ProfileDB“ <- das wird nochmal wichtig)
Das alles hat leider nicht geholfen und sehr viel Zeit in Anspruch genommen. Mir ist dann ein interessantes Phänomen in meiner Infrastrukutur aufgefallen, was mich der Lösung ein gutes Stück näher gebracht hat. Es werden, wie bereits weiter oben erwähnt, zwei verschiedene Dienste in der SharePoint Zentraladministration für die Benutzerprofildienstanwendung verwendet:
1. „User Profile Service“
2. „User Profile Synchronization Service“
Zu diesen beiden Diensten gibt es korrespondierende Windows Dienste
1. „Forefront Identity Manager Service“ („User Profile Service“)
2. „Forefront Identity Manager Synchronization Service“ („User Profile Synchronization Service“)
Nun trat folgendes Szenario auf:
Dienst SharePoint Status Windows Status
User Profile Service Started Stopped
User Profile Synchonization Service Starting Started
Die Frage die sich mir nun stellte: „Warum wurde der Windows Dienst für den User Profile Service nicht gestartet“? Das manuelle Starten führte lediglich dazu, dass der Dienst sofort wieder disabled wurde. Nach mehreren Server Neustarts habe ich mich dann mal intensiver mit den Windows Log Dateien beschäftigt und dort ist mir die folgende Fehlermeldung ins Auge gefallen, die immer dann auftrat wenn ich den Windows Dienst „User Profile Service“ manuell starten wollte:
Die rote Box zeigt, dass der Dienst Probleme hat die Datenbank „SharePoint2010_Sync_DB“ aufzurufen. Natürlich geht das nicht, die Datenbank existiert ja auch nicht mehr. Diesen Datenbanknamen habe ich beim ersten Versuch die Profildienst Anwendung anzulegen verwendet. Danach wurde die Profildienst Anwendung aber mehrfach neu erstellt und auch die Datenbanknamen haben sich geändert. Warum versucht der Windows Dienst also immernoch den alten Namen der DB zu verwenden, bzw. wo hat der Dienst diesen Namen her?
Die einfach Antwort: In der Windows-Registry!
Ich habe diese also geöffnet und eine Suche nach dem Datenbanknamen gestartet. Fündig bin ich unter dem Pfad HKLM -> System -> ControlSet001 -> services -> FIMService geworden. Hier gibt es einen Schlüssel mit dem Namen „DatabaseName“ in der noch der alte, inital verwendete, Datenbankname gespeichert wurde. Der folgende Screenshot zeigt den Schlüssel mit dem geänderten Eintrag:
Nachdem dieser auf den Namen der neuen Datenbank geändert wurde, konnten über die Zentraladministration beide Dienste problemslos gestartet und die Profildienstanwendung verwendet werden.