IIS-AppPool-Account hat nicht genügend Berechtigungen für User-Profile-Datenbanken

Mein heutiges Problem: Das Erstellen von SharePoint-WebApplications mündet darin, dass der nachfolgende Aufruf mittels Browser einen Fehler wirft.

Nach dem Anlegen einer SharePoint-WebApplication wird dieser Fehler im Browser ausgegeben.

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

  1. den Configuration Wizard (PSConfig.exe) mit folgendem Befehl ausgeführt PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
  2. den Configuration Wizard (PSConfigUI.exe) ausgeführt
  3. 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
  4. 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.

Dieser Beitrag wurde unter Microsoft, SharePoint 2010 abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>