Mein heutiges Problem: Das Erstellen von SharePoint-WebApplications mündet darin, dass der nachfolgende Aufruf mittels Browser einen Fehler wirft.
Ein unerwarteter Fehler ist aufgetreten.
Ursachen-Forschung: Das Auffinden der Fehlersuche ist nicht einfach, denn es gibt keine Windows-Event-Log-Einträge und nur den folgenden ULS-Log-Hinweis:
System.Data.SqlClient.SqlException: Die von der Anmeldung angeforderte Mss2010_ProfileDB-Datenbank kann nicht geöffnet werden. Fehler bei der Anmeldung. Fehler bei der Anmeldung für den Benutzer ‘testad\MssWebAppAdm1‘ …
Es fehlt also dem IIS-Application-Pool-Account meiner neu angelegten SharePoint WebApplication eine (oder wahrscheinlich mehrere) Berechtigungen auf Datenbank-Ebene. Der erste Ansatz ist also, die oben genannte fehlende Berechtigung zum Anmelden an einer der drei Datenbanken (Profile, Social und Sync) der User-Profile-ServiceApplication zu untersuchen.
Aber halt (einen Schritt zurück): Welche Berechtigungen benötigt eigentlich ein IIS-Application-Pool-Account einer SharePoint-WebApplication? – Die Antwort ist in Technet-Artikel “Account permission and security settings (SharePoint 2010)” zu finden. Die Quintessenz des Artikels lautet: Die lokalen Berechtigungen und die Datenbankberechtigungen werden automatisch vergeben.
Na gut – offensichtlich ist dem heute bei mir nicht so, denn ich erhalte ja den oben beschriebenen Fehler.
Ein Blick via Sql-Management-Studio auf die Datenbank-Berechtigungen des IIS-Application-Pool-Accounts zeigt, dass der Account tatsächlich keine Berechtigungen für die Profile-DB (und auch nicht auf die anderen beiden Datenbanken Social und Sync) besitzt.
Lösung / Workaround: Da die Berechtigungen von SharePoint selbst vergeben werden (s. Technet-Artikel oben), sollte das Erstellen einer neuen SharePoint-WebApplication samt SiteCollection die erforderlichen Berechtigungen “gradeziehen”.
Um ganz sicher zu gehen, dass ich eine saubere Ausgangsposition habe, habe ich
- den Configuration Wizard (PSConfig.exe) mit folgendem Befehl ausgeführt PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
- den Configuration Wizard (PSConfigUI.exe) ausgeführt
- eine neue SharePoint-WebApplication mit neuer URL, neuem IIS-ApplicationPool aber gleichen AD-Account (den, der in der ULS-Fehlermeldung oben genannt wurde) und der Angabe neuer Inhalts-Datenbanken und nachfolgend
- eine zugehörige SiteCollection erstellt.
Siehe da: Der Aufruf der beider SharePoint-WebApplications im Browser funktioniert wieder. D.h., die Datenbank-Berechtigungen wurden anscheined korrekt nachgezogen. Die für diesen zweck angelegte zweite WebApplication kann nun wieder gelöscht werden (auf Datenbank-Seite werden die Berechtigungen nicht wieder entfernt – zum Glück).
Was nun konkret die Ursache für das initiale Nicht-Setzen der Datenbank-Berechtigungen war, kann ich allerdings nicht sagen. Naja – ein Workaround ist besser als gar nichts.