SharePoint 2013 und die Bereitstellung von Apps

Eine der grundlegenden Neuerungen (wenn nicht DIE Grundlegendste) in SharePoint 2013 ist das App Modell. Damit können verschiedenste Apps im SharePoint Kontext ausgeführt werden. Und wie es sich für Apps gehört, gibt es natürlich auch bei SharePoint nun einen App Store, der eine zentrale Anlaufstelle für Apps darstellt.

Was sich so wunderbar einfach anhört und auch in Office 365 Out-Of-The-Box funktioniert, erfordert bei einer On-Premise Installation einiges an Konfiguration und vorausschauender Planung. Deshalb möchte ich in diesem Artikel ein paar Tipps geben und potentielle Stolperfallen aufzeigen.

SharePoint Konfiguration

Damit der SharePoint generell in der Lage ist Apps auszuführen, müssen folgende Dienste gestartet sein:

1. SharePoint Timer Service
2. SharePoint Administration Service

Weiterhin müssen die Instanzen vom „App Management Service“ und „Subscription Settings Service“ gestartet werden. Dies erfolgt durch folgenden PowerShell Befehl:

Get-SPServiceInstance | where {$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance

Danach müssen die zugehörigen Dienstanwendungen und Proxys erstellt werden. Empfehlenswert sind auch zwei separate Application Pools mit unterschiedlichen Dienstkonten.  Dies funktioniert auch über die PowerShell:

$account = Get-SPManagedAccount "domain\account"
$appPoolSub = New-SPServiceApplicationPool -Name SubSettingsServiceAppPool -Account $account
$appPoolApp = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
$subSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSub –Name "Subscription Settings Service" –DatabaseName SettingsServiceDB
$subSvcProxy = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $subSvc
$appSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolApp -Name "App Management Service" -DatabaseName AppServiceDB
$appSvcProxy = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appSvc -Name "App Management Service Proxy"

Damit sind die Grundlagen geschaffen. Was jetzt noch fehlt ist eine URL, unter der die SharePoint Apps erreichbar sind.

SharePoint Apps URL

Aus sicherheitstechnischen Gründen müssen die Apps unter einem „isolierten“ (oder einzigartigen) DNS Hostnamen zugänglich gemacht werden. Hier ist bei einem eventuellen externen Zugriff zu beachten, dass diese URL intern wie extern erreichbar sein muss. Hier ist also kein AAM (Alternate Address Mapping) möglich, wie man es aus der SharePoint Welt vielleicht kennt. Jetzt ist es wohl an der Zeit sich diese URL etwas näher anzusehen, um die generelle Funktionsweise besser zu verstehen. Am besten ist dies mit einem Beispiel möglich. Nehmen wir einfach mal an, wir haben eine SharePoint-Hosted App (Achtung: Es gibt hier auch andere Varianten) auf der Seite http://sharepoint.contoso.com/sites/eineApp ausgerollt. Diese App wäre dann zum Beispiel unter der URL http://app-4815b2d470c21.contoso-apps.com/sites/eineApp/meineApp erreichbar. Diese URL setzt sich aus folgenden Teilen zusammen: http://<AppPrefix>-<AppID>.<AppDomain>/<HostWeb>/<AppName>

• AppPrefix: Dieser Präfix ist ein String der in der Zentraladministration konfiguriert werden kann.
• AppID: Eine hexadezimale Zahl, die zufällig bei der Installation der App generiert wird.
• AppDomain: Dieser Hostname wird ebenfalls in der Zentraladministration konfiguriert. Empfehlenswert ist hier wirklich ein andere URL zu verwenden, als die eigentliche SharePoint Webanwendung nutzt.
• HostWeb: Relative URL zum zugehörigen Host Web
• AppName: Name der installieren App

Bei der oben aufgeführten Erklärung ist der Begriff vom Host Web gefallen. Bei SharePoint-Hosted Apps wird zwischen dem Host Web und dem App Web unterschieden. Die eigentliche Installation einer App erfolgt im Host Web. Die App und die ganzen notwendigen Ressourcen (z.B. Listen, Workflows, etc.) liegen im App Web. Das App Web (=Website) liegt  in der gleichen Site Collection wie das Host Web. Das App Web ist allerdings nur über die bereits beschriebene URL erreichbar.

Technische Realisierung

Die technische Realisierung erfolgt über eine entsprechende Forward Lookup Zone im DNS, die angelegt werden muss:

Danach muss die AppDomain angegeben werden:

 

Wenn die Zone erstellt wurde, muss noch ein Wildcard Record erstellt werden. Der Record muss auf einen SharePoint Frontend Server zeigen, damit alle Requests an die AppDomain richtig geroutet werden können:

Ob die Konfiguration erfolgreich war, kann man z.B. per PING testen:

ping zufaellig.contoso-apps.com

Das Ergebnis sollte eine entsprechende IP zurückliefern. Der vordere Teil kann dabei beliebig gewählt werden, weil der vorher angelegt Wildcard Record für die entsprechende Auflösung vom Hostnamen sorgt.

Zu beachten bei der Konfiguration

An diesem Punkt müssen wir wieder ein paar Dinge berücksichtigen, damit wir nicht später bei der Verwendung von Apps Probleme bekommen. Besonders bei der Nutzung von mehreren Webanwendungen die mit Host Headern arbeiten ist hier Vorsicht geboten. Das problemloseste Szenario wäre, wenn wir nur eine Webanwendung haben und z.B. mit sog. Host Named Site Collections (HNSC) arbeiten. Dort haben wir keine Host Header die einem die Konfiguration erschweren. Der Ansatz mit nur einer Webanwendung und HNSC ist mittlerweile der von Microsoft bevorzugte Methode. Allerdings sind  heute immer noch die Nutzung von mehreren Webanwendungen sehr verbreitet. Dies kann entweder technische Gründe haben oder auch einfach historisch gewachsen sein. In früheren Versionen von SharePoint gab es teilweise gar keine HNSC bzw. fristeten ein Nischendasein. Und bei einer Migration auf eine neuere Version wurde die bisherige Struktur einfach übernommen. Deshalb ist folgendes Szenario mit mehreren Webanwendungen und dem Einsatz von Host Headern weit verbreitet:

 

Solange man keine Apps nutzen möchte, stellt dieses Szenario auch gar kein Problem dar. Wie wir allerdings bereits gesehen haben, nutzten SharePoint-Hosted Apps eine teilweise zufällige URL. Und dies ist führt in Verbindung mit Host Headern zu einem Problem. Denn im IIS kann man nicht so einfach einen Host Header mit einer Wildcard angeben, wie z.b. *.contoso-apps.com. In diesem Szenario würde der Aufruf einer App mit einem HTTP Fehler 404 enden. Dies ist auch noch einmal in folgender schematischen Darstellung aufgezeigt:

 

Aufgrund des konfigurierten Host Headers fühlt sich der IIS nicht zuständig und leitet den Request auch nicht an den SharePoint weiter. In einem solchen Szenario (mehrere Webanwendungen) müssen also noch ein paar zusätzliche Konfigurationen vorgenommen werden. Das Ziel ist also, dass der Request für die App an den SharePoint weitergeleitet wird. Auf welcher Webanwendung der Request landet ist egal. Die notwendigen Änderungen sind in der folgenden Abbildung (vereinfachte Darstellung: die Requests werden nicht vom IIS zur entsprechenden Webanwendung weitergeleitet, sondern vom SharePoint) in Grün dargestellt:

Mit dieser Konfiguration funktionieren Apps auf allen bereits bestehenden Webanwendungen. Die gestrichelte Linie der neuen Webanwendung deutet an, dass diese technisch zwar existieren muss, aber nicht zugreifbar für Benutzer sein muss.

Technische Realisierung

Zur technischen Realisierung muss dem SharePoint (Frontend) Server eine weitere IP Adresse zugewiesen werden.

Die zusätzlich zugewiesene IP Adresse nutzen wir nun für den weiter oben angelegten DNS Record. Somit werden alle Aufrufe von Apps auf eine fest definierte IP geroutet. Und diese hilft uns später für die Konfiguration vom IIS. Jetzt benötigen wir noch eine Webanwendung, die wir wie gewohnt entweder über PowerShell oder die Zentraladministration anlegen. Um eine neue Webanwendung anlegen zu können, muss ggf. ein Host Header eingetragen werden. Diesen können wir später allerdings wieder bei der IIS Konfiguration entfernen. Beim Anlegen sollte ein separater Application Pool erstellt und nicht ein bereits vorhandener genutzt werden. Wenn die bereits bestehenden Webanwendungen verschiedene Dienstkonten für die Application Pools verwenden, kann es zu einem Berechtigungsproblem kommen. Wie dieser Fehler beseitigt werden kann, zeige ich euch in einem späteren Blogeintrag.

Sobald die Webanwendung angelegt ist, muss noch eine Root Site Collection erstellt werden. Bei den Parametern müssen keine speziellen Einstellungen berücksichtigt werden. Es ist nur wichtig, dass eine Root Site Collection existiert.

Im letzten Schritt müssen noch die IIS Einstellungen bzw. die Bindings angepasst werden.

Hier ist zu beachten, dass evtl. Host Header entfernt und die richtige zusätzliche IP im Binding eingetragen werden. Bei den Ports müssen alle von Webanwendungen verwendeten Ports hinzugefügt sein. Die Ports vom Host Web und App Web sind nämlich immer identisch. Das bedeutet auch, wenn das Host Web SSL Verschlüsselung nutzt, muss das App Web auch zwingend SSL Verschlüsselung nutzten.

Zusammenfassung

Hat man all diese Konfigurationen durchgeführt, ist der On-Premise SharePoint endlich für die Verwendung von Apps vorbereitet. Ich konnte hoffentlich mit dem Beitrag zeigen, dass man sich bei der Konfiguration von Apps einige Gedanken machen sollte. Viele andere Artikel im Internet zu diesem Thema verschweigen leider die Komplexität und man erlebt irgendwann eine böse Überraschung. Man sollte sich einfach merken, dass für Apps immer eine separate Webanwendung von Vorteil ist. Dies ermöglicht eine saubere Konfiguration und reduziert die Komplexität deutlich.

Happy SharePointing…