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…

10 Kommentare

  1. Hallo,

    danke für diesen ausführlichen Blogbeitrag für die Bereitstellung von Apps bei Sharepoint 2013.

    Sind alle Schritte so auch bei einem Einzelserver mit integrierter Datenbank (SQL Server Express) notwendig?

    Es wurde die Installationsart Einzelserver verwendet da nicht mehr als 20 Personen damit arbeiten werden.
    Die Sharepoint 2013 Seite hat keine SSL-Verschlüsselung.

    Muss hier auch eine neue Webanwendung erstellt werden und eine neue Root Site Collection?
    Oder kann die bestehende Root Site Collection von der bestehenden Webanwendung verwendet werden?

    Weiter ist unsere Sharepoint-Seite die erste Root Site Collection und direkt unter dem Servernamen erreichbar, also z. B. http://meinsharepointportal/ und der Server heißt meinsharepointportal unter der Domäne domain.local, d.h. meinsharepointportal.domain.local.

    Würde hier ein Subdomäne ausreichen, oder sollte hier trotzdem eine neue Domäne verwendet werden?
    Und wenn eine neue Domäne verwendet wird z. B. sharepoint-apps.com, gibt es dann Probleme mit der Sharepoint Seite, die unter der .local Domäne aufrufbar ist?

    Danke im Voraus!

    MfG

    • Hallo,

      wenn Deine Webanwendung keine Host Header nutzt, musst Du keine neue Webanwendung anlegen.
      Bei der Wahl einer komplett neuen Domäne oder einer Subdomäne hast Du die freie Wahl. Es würde auch „nur“ eine Subdomäne ausreichen.
      Wenn Du die eine neue Domäne für die Apps nutzt bekommst Du keine Probleme mit der SharePoint Seite, die unter der .local Domäne läuft.
      Die Anleitung ist auch für einen Einzelserver gültig.

      Hoffe ich konnte Dir damit helfen. Wenn Du noch weitere Fragen hast, einfach fragen. 🙂

      Frank

  2. Hallo Frank,

    danke für die schnelle Antwort.

    Bei meinem Einzelserver ist die Webanwendung (Sharepoint – 80) ohne Hostheader angelegt, also die Standardinstallation von Microsoft bei einer Sharepoint 2013 Einzelserverinstallation.

    1) D. h. ich benötige eigentlich für meine Zwecke auf meinem Einzelserver keine zweite IP-Adresse.
    Somit kann ich eine neue Domäne z. B. examplespapps.local für die Sharepoint Apps-Domäne anlegen, dieser einen CNAME Alias mit dem Platzhalter-Sternchen * hinzufügen und als Ziel den Einzelserver von Sharepoint 2013 angeben, also meinsharepointportal.domain.local?
    Somit würden ja die Apps als Subdomäne zu examplespapps.local auf die IP-Adresse des Sharepoint-Einzelservers zeigen..

    2) Diesen Satz verstehe ich nicht ganz: „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.“

    Wieso kann dies zu Berechtigungsproblemen führen? Und gibt es diesen Blogeintrag für die Fehlerbehebung bereits? 🙂

    3) Wozu benötige ich den App Management bzw. den App Management Service?
    Dieser ist bei Ihren PowerShell Befehlen dabei.
    Die anderen Dienste verstehe ich..
    Und wo wir schon bei den PowerShell Befehlen sind, dort ist ein kleiner Fehler enthalten, die Variable $appPoolApp in Zeile 6 ist falsch geschrieben, dort fehlt ein „p“. Im Code auf der Seite steht $apPoolApp 🙂

    4) Dann frage ich mich warum Sie nicht auf das Thema App Catalog erstellen kurz eingegangen sind.
    Man muss doch zwingend einen App Catalog in der Zentraladministration anlegen, oder?
    Sonst können Anwender doch nicht auf Apps im Microsoft Sharepoint App Store zugreifen, oder?

    Sorry für die vielen Fragen, aber ich möchte sicher gehen, dass ich das Thema korrekt verstanden habe.

    MfG

    PSchuetz

    • Hallo,

      zu 1: Solange Sie keine Host Header nutzen, benötigen Sie nicht zwingend eine zweite IP-Adresse, korrekt.
      zu 2: Wenn Sie mehrere Webanwendungen haben, die jeweils unterschiedliche Dienstkonten (Web Application Pool) nutzen, kommt es zu Problemen. Für mich sieht es eher nach einem Bug von Microsoft aus. Mehr Informationen zu diesem Problem gibt es hier: https://frankeisel.de/sharepoint-2013-apps-konfiguration-bug/. Bei einer Webanwendung tritt das Problem nicht auf.
      zu 3: Vielen Dank für den Hinweis, habe den Tippfehler korrigiert. Der App Management Service wird unter anderem dafür genutzt,um die App Berechtigungen bereitzustellen und die entsprechenden Unterdomänen für die Apps zu erstellen.
      zu 4: In dem Beitrag lag der Fokus auf dem Szenario mit mehreren Webanwendungen. Aber Sie haben natürlich Recht, man benötigt zwingend einen App Catalog.

      Der Managed Account kann ein x-beliebiger Domänenaccount sein. Spezielle Berechtigungen werden nicht benötigt. Damit der Account genutzt werden kann, muss dieser nur vorher im SharePoint hinterlegt werden. Das geht entweder über die Zentraladministration oder über die Powershell mit dem Befehl New-SPManagedAccount.

      Viele Grüße und ich hoffe, dass ich nichts vergessen habe. 🙂
      Frank

  3. Noch eine ergänzende Frage, die ich oben vergessen hatte.

    Kann man für den SPManagedAccount einen x-beliebigen Domänenaccount verwenden, oder muss dies ein bestimmter Account sein?
    Welche Rechte benötigt dieser?
    Und muss man diesen Account noch vorher irgendwo bei Sharepoint hinterlegen?

    Danke im Voraus!

    MfG

    PSchuetz

  4. Hallo Frank,

    danke für die ausführliche Ausführung.

    Jetzt ist alles soweit klar.

    Ich würde trotzdem noch der Vollständigkeit halber im Blogeintrag erwähnen, dass man die App Catalog anlegen und die App URLs konfigurieren muss, nachdem diese im DNS angelegt hat.

    Bei meinem Server funktioniert es jetzt soweit, vielen Dank für die Unterstützung.

    Leider kann man aber nur sehr wenige Apps aus dem Microsoft Sharepoint Store hinzufügen.
    Dies wird wohl daran liegen, dass ich die deutsche Sprachversion von Sharepoint 2013 verwende.

    MfG

    PSchuetz

  5. Hallo Frank,

    beim Start einer SharePoint Hosted App bekomme ich folgenden Fehler: The endpoint /_layouts/15/exs/signin.aspx is not accessible in the context of a SharePoint App.

    Ich benutzte für die FBA Authentifizierung eine Solution bei der die Login Page im _layouts Ordner liegt.

    VG
    ssalko

Schreibe einen Kommentar