Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

SharePoint 2016-Administration Grundkurs

Die Farm für Apps vorbereiten

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Bevor Sie Apps in der Farm verwenden können, müssen die Farm vorbereitet und Dienstanwendungen überprüft werden. Erfahren Sie alles Wichtige in diesem Video.

Transkript

Um eine App-Umgebung in einer SharePoint-Farm einzurichten, muss der Farm-Administrator alle Register quer durch alle Konfigurationsebenen einer Windows-Umgebung ziehen. Benötigt wird eine eigene Webanwendung, ein sogenanntes Hostweb. Benötigt wird ein Wildcard-Zertifikat. Es muss im DNS-Server ein entsprechender Wildcard-Eintrag erstellt werden, und eine Subzone erstellt werden. Anschließend müssen noch Dienstanwendungen registriert werden und der App-Katalog erstellt werden. All diese Schritte werde ich im Folgenden mit Ihnen durcharbeiten. Für die Bereitstellung eines eigenen App Webs, das nötig ist, um das Zertifikat korrekt zu hosten und sicherzustellen, dass alle Requests beim App-Managementdienst landen, der ja von der SharePoint-Farm verwaltet wird, wird eine eigene Webanwendung benötigt. Um die Webanwendung korrekt zu hosten unter SSL, ist es empfehlenswert, diese Webanwendung mit einer eigenen IP-Adresse zu versehen, sodass sie dann im DNS ordentlich aufgelöst werden kann. Daher wird hier eine zusätzliche IP-Adresse für die neue Webanwendung vergeben. Im nächsten Schritt muss für eine korrekte Namensauflösung im DNS-Server der Domäne gesorgt werden. Und Sie müssen sich für einen Namen entscheiden, unter dem diese Webanwendung später aufgerufen wird. Im Beispiel hier wird ein neuer Hosteintrag, ein A-Eintrag, im DNS-Server erstellt auf sp für SharePoint, appweb wie Web für Apps. Die eben vergebene IP-Adresse wird entsprechend hinterlegt und es wird auch ein Pointer-Eintrag in der Reverse-Lookup-Zone erstellt, sodass der Host nun auf diese IP aufgelöst werden kann. Damit Apps ordentlich funktionieren, müssen sie über eine eigene DNS-Zone aufgerufen werden. Das heißt also, für Apps gibt es keinen eigenen Hostnamen, sondern der Hostname wird immer durch einen GUID von der App selbst festgelegt. Später muss der Farmadministrator eine App Domain angeben, die letztlich jeden Aufruf an einen Host in dieser DNS-Zone an das App Web hier weiterreicht. Daher ist es nötig, im DNS-Server der Domäne eine Neue Zone einzurichten. Es handelt sich hier um eine Primäre Zone. Die Verteilung in der Domäne muss letztendlich domänenspezifisch vom Domänenadministrator bestimmt werden. Der Zonenname kann eine Subzone oder eine Zone der ersten Ebene darstellen. Eine Subzone ist in dem Fall vielleicht empfehlenswerter, weil es die Apps ordentlich separiert. So würde hier ein Zonenname sp für SharePoint, apps, unterhalb der Zone spdemo.local erstellt werden. In dieser Zone muss nun gemäß der Spezifikation von Microsoft, und auch damit das Ganze ordentlich funktioniert, ein neuer Alias erstellt werden, also nur ein Aliaseintrag, kein Hosteintrag. Der Aliasname ist ein Wildcard, ein Sternchen. Das bedeutet also, alle Anfragen an die Zone spapps.spdemo.local werden an den hier angegebenen Host weitergeleitet. Das wäre in unserem Beispiel der spappweb in der Domäne spdemo.local. Weil unter dieser Adresse ja die Webanwendung in SharePoint läuft und in der eine Instanz des App-Managementdienstes. So kann also der App-Managementdienst erkennen, hier wurde eine App aufgerufen anhand des Zonennamens spapps.spdemo.local, und kann die Anforderung an den App-Managementdienst entsprechend weitergeben. Damit sind die DNS-seitigen Voraussetzungen geschaffen. Im nächsten Schritt sollte die Webanwendung natürlich unter einem eigenen Dienstkonto laufen. Das Dienstkonto wurde hier bereits präpariert und als verwaltetes Konto in der Farm registriert. Das lautet auf den Namen SPAppWebAppPool. Im nächsten Schritt wird eine Webanwendung erstellt. In der Zentraladministration im Abschnitt Webanwendungen kann man auf Webanwendungen verwalten klicken, und dann oben links auf Neu, um eine neue Webanwendung anzulegen. Die Webanwendung hört auf den Hostnamen spappweb.spdemo.local. Das wird eine SSL-gesicherte Webanwendung sein. Dementsprechend sind SSL, Secure Socket Layers, zu aktivieren. Die Webanwendung ist auch auf Kerberos-Authentifizierungsprotokoll definiert. Der Application Pool wird ein eigener Application Pool sein und wird unter dem Konto SPAppWebAppPool ausgeführt, um das Sicherheitsmodell von SharePoint zu wahren. Dieses Konto wurde auch gehärtet und ist nur Mitglied einer Gruppe, die keine weiteren Zugriffsrechte gewährt. Die Inhaltsdatenbank ist proprietär zu betrachten. In dieser Webanwendung werden eigentlich keinerlei Inhalte gespeichert. Sie ist einzig und allein dazu da, die Anforderungen der Apps weiterzuleiten an den App-Managementdienst. Dementsprechend muss man sich um diese Datenbank hier nicht besonders kümmern. Die Member und Owner sollen hier keine Websites erstellen und sollen hier keine Dateien hochladen. Im Anschluss kann man dann die Webanwendung erstellen lassen. Nach erfolgreicher Erstellung über den Internetinformationsdienste-Manager die Site-Konfiguration im IIS anzupassen an ein passendes Zertifikat und an die eben erstellte IP-Adresse. Das Zertifikat muss zuerst angefordert werden über den Internetinformationsdienste-Manager. Wenn man den Servernamen links unter Verbindungen auswählt, erhält man im mittleren Abschnitt unten rechts den Befehl Serverzertifikate, und kann dann im rechten Abschnitt unter Aktionen den Befehl Domänenzertifikat erstellen auswählen. Und er fordert nun ein Wildcard-Zertifikat an. Das bedeutet, das wird registriert auf den Common Name *., und jetzt folgt der Name der vorhin erstellten DNS-Zone, spapps.spdemo.local. Das bedeutet, dieses Zertifikat ist gültig für alle Hostnamen, die sich in dieser DNS-Zone befinden. Die Hostnamen sind uns ja zum jetzigen Zeitpunkt noch gar nicht bekannt und werden später dynamisch über einen GUID hinzugefügt. Es müssen noch die informativen Felder für das Zertifikat ausgefüllt werden. Danach muss die Domänen- zertifizierungsstelle ausgewählt werden. Als Name empfiehlt es sich eigentlich immer den Common Name zu verwenden. Sowie eine Kennzeichnung für die Jahreszahl, damit später im Austausch zwei verschiedene Zertifikate deutlich voneinander unterschieden werden können. Für die eben erstellte Webanwendung spappweb muss nun in den Bindungen zuerst der Hostname entfernt werden. Es sollte die IP-Adresse eingetragen werden, damit es möglich wird, mehrere Webanwendungen auf dem gleichen TCP-Port zu hosten. Es muss außerdem das eben erstellte Wildcard-Zertifikat verwendet werden. Hier ist zu beachten oder etwas irritierend, dass die Webanwendung intern eigentlich auf den Hostnamen spappweb.spdemo.local hört. Von Apps später aber aufgerufen wird über guid.spapps.spdemo.local. Insofern muss hier auch im Zertifikat der Name, der Common Name, für die App stehen und nicht der Common Name der eigentlichen Webanwendung. Wir haben die Webanwendung auf Kerberos-Authentifizierung konfiguriert. Dementsprechend muss auch für das Dienstekonto noch ein Service Principal Name, ein Dienstprinzipalname, mit dem Toolset spn erstellt werden. Das kann mit -a hinzugefügt werden, auf die Dienstekennung im HTTP-Protokoll. Bitte beachten, das ist kein Backslash, sondern ein Slash über der 7. Dann folgt der Hostname. Sowie das Konto, unter dem der Dienst ausgeführt wird. Gut, damit ist die Erreichbarkeit der Webanwendung so weit abgeschlossen. Nun muss noch sichergestellt werden, dass für alle anderen Webanwendungen das eben zugewiesene Konto auch entsprechende Berechtigungen hat. Das heißt, das Application-Pool-Konto der spappweb.spdemo.local-Webanwendung sollte auch Zugriffsberechtigungen auf die anderen Webanwendungen besitzen. Das erreicht man, indem man sich zuerst in der PowerShell eine Instanz auf die gewünschte Webanwendung holt. In eine Variable, im Fallbeispiel lautet die Variable $wa für Webanwendung. Dann wird das Cmdlet Get-SPWebApplication verwendet. Hier muss man die Adresse der gewünschten Webanwendung angeben. Und bekommt anschließend in der Variable $wa ein Handle, eine Instanz auf diese Webanwendung. Und kann nun die Methode GrantAccessToProcessIdentity aufrufen. Und gibt hier das Konto an, unter dem die spappweb-Webanwendung ausgeführt wird. Anschließend muss die Webanwendung aktualisiert werden. Und nun darf auch dieses Konto mit entsprechenden Dienstzugriffsrechten auf die Webanwendung zugreifen. Nach der Spezifikation von Microsoft muss nun noch mit der PowerShell der Subscription Service eingerichtet werden. Es gibt hier in der Zentraladministration dafür keinen Befehl, nach wie vor nicht, auch nicht in SharePoint 2016. Ich habe hier bereits ein kleines Script vorbereitet. Im ersten Schritt wird mit dem Cmdlet Get-SPServiceApplicationPool eine Instanz auf den Default Service Application Pool geholt. Das heißt also, in der Variable $appPool gibt es im Anschluss daran ein Handle auf den Anwendungspool mit dem Namen SharePoint Web Services Default, der eigentlich generell für Dienstanwendungen verwendet wird. Nun muss man mit dem Cmdlet New- SPSubscriptionSettingsServiceApplication eine neue Instanz des Subscription Settings Service implementieren. Hier ist anzugeben der Name der gewünschten Instanz, der dann auch in der Zentraladminstration unter Dienstanwendungen auftaucht. Sowie der ApplicationPool, unter dem die Dienstanwendung laufen soll. Hier kann man den oben ermittelten $appPool angeben. Im letzten Schritt muss für diese Dienstanwendung noch ein Dienstanwendungs-Proxy implementiert werden. Auch dafür stellt Microsoft ein entsprechendes Cmdlet zur Verfügung, heißt New-SPSubscriptionSettings ServiceApplicationProxy. Hier muss letztlich nur die Dienstanwendung angegeben werden, die oben mit $svc in eine Variable geschrieben wurde. Nach Ausführung dieser PowerShell-Operation ist eine neue Instanz des sogenannten Subscription Settings Service implementiert. Damit sollten die Apps vollständig funktionsfähig für den SharePoint eingerichtet sein. Microsoft hat die hier gezeigten Schritte auch im Internet entsprechend dokumentiert. Diese hier gezeigte Anleitung ist noch für SharePoint 2013. Aktuell ist für SharePoint 2016 eine solche Anleitung noch nicht veröffentlicht. Die gezeigten Schritte sind aber exakt identisch, eins zu eins, mit den Schritten, die für SharePoint 2016 abzuarbeiten sind.

SharePoint 2016-Administration Grundkurs

Lernen Sie, worauf es bei der Planung, Einrichtung und Administration einer SharePoint-Farm auf Basis von SharePoint Server 2016 ankommt.

8 Std. 21 min (66 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Ihr(e) Trainer:
Erscheinungsdatum:24.10.2016
Laufzeit:8 Std. 21 min (66 Videos)

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!