Wie man Apps in SharePoint 2013 konfiguriert und was dabei zu beachten ist, habe ich bereits in einem vorherigen Artikel beschrieben. Dort habe ich bereits angesprochen, dass es bei der Konfiguration ein Problem auftreten kann. Für mich ist es eigentlich kein Problem, sondern ein Bug von SharePoint. Leider ist dieser Bug bisher immer noch nicht behoben (Stand: März 2015 CU). Das Problem tritt auf, wenn man man sich an die Best Practices hält und mehrere Webanwendungen mit unterschiedlichen Dienstkonten für die Application Pools nutzt. Dann sieht beim Aufruf der App (App Web) die Seite plötzlich so aus:
Teilweise kommt beim ersten Aufruf der App auch gar kein Ergebnis zurück, sondern nur ein HTTP 403 Fehler. Das Fehlerbild kann also unterschiedlich sein, das eigentliche Problem ist allerdings ein Berechtigungsproblem wie auch der HTTP 403 Fehler vermuten lässt. Weiterhin findet man auch entsprechende Fehler im ULS:
defaultcss.ashx: using elevated codepath to get css file or other resource because the non-elevated code path failed to get it. System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex) at Microsoft.SharePoint.Library.SPRequest.SetWebMetainfo(String bstrUrl, Object varMetainfo) at Microsoft.SharePoint.SPWeb.UpdateProperties(StringDictionary data) at Microsoft.SharePoint.SPWeb.set_MasterDefaultCss(String value) at Microsoft.SharePoint.SPWeb.get_MasterDefaultCss() at Microsoft.SharePoint.ApplicationPages.DefaultCss.GetResourceUrl(SPWeb web, Boolean getResource) at Microsoft.SharePoint.ApplicationPages.DefaultCss.ProcessRequest(HttpContext context)
Application error when access /_layouts/15/defaultcss.ashx, Error=Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex) at Microsoft.SharePoint.Library.SPRequest.OpenWeb(String bstrUrl, String& pbstrServerRelativeUrl, String& pbstrTitle, String& pbstrDescription, String& pbstrTitleResourceId, String& pbstrDescriptionResourceId, Guid& pguidID, DateTime& pdtTimeCreated, String& … at Microsoft.SharePoint.SPWeb.InitWeb() at Microsoft.SharePoint.SPWeb.get_Title() System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Lösungsversuche mit zusätzlichen Berechtigungen (Datenbank, „GrantAccessToProcessIdentity“, etc.) für das Dienstkonto waren alle erfolglos.
Die einfachste Lösung wäre, dass alle Applications Pools der Webanwendungen (nur die auch Apps unterstützen sollen) das gleiche Dienstkonto verwenden, wie auch die Webanwendung für die Apps. Dies widerspricht allerdings jeden Best Practices für SharePoint. Ein anderer Lösungsweg der bisher bei mir funktioniert hat, ist das Dienstkonto vom Application Pool der Apps-Webanwendung zu ändern und dann jeweils eine beliebige App in der Webanwendung mit dem gleichen Dienstkonto aufzurufen. Danach trat der Fehler nicht mehr auf, auch wenn ich das Dienstkonto wieder geändert habe.
- Application Pool Dienstkonto der Apps-Webanwendung entsprechend des Application Pools der Webanwendung setzten, wo der Fehler auftritt.
- Einen
IISRESET
durchführen - Die App wo der Fehler auftrat noch einmal aufrufen
- Diese sollte nun fehlerfrei geöffnet werden
- Für weitere Dienstkonten die Schritte wiederholen
Sollte jemand noch andere Lösungswege gefunden haben, würde ich mich über Feedback freuen.
Happy SharePointing…