Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SharePoint 2016-Administration Grundkurs

Voraussetzungen für eine Web-Anwendung schaffen

Testen Sie unsere 2016 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Vor Einrichtung einer Web-Anwendung in der SharePoint Zentraladministration müssen serverseitige Voraussetzungen geschaffen werden. Benötigt werden eine IP-Adresse, ein DNS-Eintrag, ein SSL-Zertifikat und ein Dienstkonto.

Transkript

Vor der Einrichtung einer Webanwendung in der SharePoint-Zentraladministration müssen einige Voraussetzungen geschaffen werden. Benötigt wird eine IP-Adresse, ein DNS-Eintrag, ein SSL-Zertifikat, sowie ein Dienstkonto, und ich zeige Ihnen, wie diese Voraussetzungen geschaffen werden. Damit der Browser die Verbindung zum Server herstellen kann, wird auf dem Web Frontend, also einem SharePoint Server mit der Rolle Web Frontend, eine IP-Adresse benötigt. Grund hierfür ist, dass der Internet Information Server seine Sites an einen TCP-Port und eine IP-Adresse binden kann. Das heißt, jede Site, ist gleich jede SharePoint-Webanwendung, wird gebunden an eine IP und einen TCP-Port. Wenn man jetzt den Standard-SSL-Port oder den Standard-HTTP-Port 80, beziehungsweise SSL 443 verwenden möchte und an alle verfügbaren IP-Adressen bindet, wäre es theoretisch möglich, nur eine einzige Webanwendung an einen Standard-TCP-Port zu binden. Alle anderen wären dann abweichend. Das heißt, man hätte dann ähnlich wie bei der Zentraladministration die Portnummer explizit durch Doppelpunkt getrennt anzugeben. Das wäre zu vermeiden, das ist unschön. Gleichwohl hat man Bedarf an mehreren Web Applications, weil eine soll Content bereitstellen, die andere soll die My Sites hosten, die nächste soll gegebenenfalls für Teams bereitstehen. Das heißt, es wird wohl mehrere Webanwendung geben. Dementsprechend ist es sinnvoll, für jede Webanwendung eine eigene IP-Adresse zu definieren und die Ansteuerung des Web Frontend über DNS zu realisieren. Das macht später auch die Migration der SharePoint-Farm einfacher, weil man in Ruhe zuerst eine neue Farm installieren kann. Und wenn man produktiv geht, einfach nur im DNS die IP-Adresse der SharePoint-Webanwendung ändern muss und damit die User automatisch zum neuen SharePoint hinführt. Eine IP-Adresse kann man in Windows Server 2012 R2 im Netzwerk- und Freigabecenter auf Ebene der Adaptereinstellungen vergeben. In den Eigenschaften einer Netzwerkkarte, einer NIC, sind die Internetprotokolle abgebildet. Dort kann man in die Erweiterten Eigenschaften gehen. In den IP-Einstellungen weitere IP-Adressen Hinzufügen. Als Nächstes ist es erforderlich, für diese IP-Adresse einen neuen DNS-Eintrag anzulegen im DNS-Server der Domäne. Hier geht es um einen Eintrag in der Zone spdemo.local vom Typ Host. Wir möchten, dass der Host aufgelöst wird unter dem FQDN sharepoint.spdemo.local. Daher die Wahl für die Zone spdemo.local. Die zurückgelieferte IP-Adresse soll die eben vergebene IP-Adresse sein. Bitte achten Sie auch darauf, einen Pointer-Eintrag zu erstellen, wenn denn eine Reverse-Lookup-Zone eingerichtet ist, was sehr empfehlenswert ist. Dann kann man mit der PowerShell oder einer Kommandozeile überprüfen, ob die Auflösung funktioniert. Dazu wäre eventuell oder sicherheitshalber zuerst der DNS Cache zurückzusetzen mit ipconfig /flushdns. Anschließend kann man mit dem Kommandozeilentool nslookup die Namensauflösung auf sharepoint.spdemo.local überprüfen. Der DNS liefert die 201.10 zurück. Damit wäre ein Browser zunächst bei dieser IP-Adresse angekommen. Wenn er nun das SSL-Protokoll aufruft, https://sharepoint.spdemo.local, wäre die konkrete Adresse 192.168.201.10:443 und er wäre hier beim IIS angekommen. Im nächsten Schritt muss ein Zertifikat angefordert werden, wenn die Webanwendung SSL-gesichert werden soll. Zertifikate kann man am einfachsten über den Internetinformationsdienste- Manager erstellen lassen, indem man im IIS-Manager den Servereintrag auswählt. Also links oben im Baum auf den Servernamen klicken. Dann findet man im Abschnitt der Startseite, im Abschnitt IIS den Befehl Serverzertifikate. Hier kann man wählen, ob man ein bestehendes Zertifikat Importieren möchte, rechts im Abschnitt Aktionen, ob man Zertifikatanforderungen erstellen möchte, also eine Textdatei erstellen möchte, die man dann an eine Zertifizierungsstelle sendet, die uns eine Zertifikatantwortdatei zurückschickt, sodass wir die Anforderung abschließen können. Oder der dritte Weg: ein Zertifikat gegen eine Domänenzertifizierungsstelle zu erstellen. Das heißt, der Domänenadministrator der Windows-Domäne kann eine Domänenzertifizierungsstelle implementieren, sobald ein Windows-Server-2012-R2-Standard vorhanden ist. Rein für Webserverzertifikate ist das nicht so besonders schwierig. Heißt, man kann das also eigentlich mit wenig Aufwand treiben und ich halte es für einen sehr guten Weg, mit einer Domänenzertifizierungsstelle zu arbeiten. Dementsprechend wird hier das Domänenzertifikat für den Common Name sharepoint.spdemo.local angefordert. Der Common Name ist enorm wichtig, denn der muss mit dem übereinstimmen, was oben im Browser eingetippt wird, in der Regel also mit dem Fully Qualified Domain Name. Wenn es hier zu Unstimmigkeiten kommt, wenn zum Beispiel nur https://sharepoint eingetippt werden würde, ohne dass spdemo.local hinten dran steht, stimmt der im Zertifikat eingetragene Common Name, Gemeinsame Name, nicht mit dem überein, was im Browser angefordert wurde, und es werden Zertifikatsfehler angezeigt. Die anderen Parameter sind nicht bindend, die sind rein informativ im Zertifikat enthalten, spielen aber für die Funktionalität keine besondere Rolle. Allerdings müssen sie ausgefüllt werden. Im nächsten Dialog wird nun die Zertifizierungsstelle ausgewählt. Wie gesagt, es muss sich hier um eine Windows-Zertifizierungsstelle handeln, die in der Domäne verteilt ist. Als Anzeigename für das Zertifikat empfiehlt es sich, den Common Name zu verwenden, denn dieser ist unique, also einmalig, versehen noch mit einer Jahreszahl. Wenn das Zertifikat abgelaufen ist, dass man das von den neu erstellten besser unterscheiden kann. Um die Webanwendung ordentlich abzusichern und der exklusiven Datenbank Zugriff zu gewährleisten, das heißt also, tatsächlich nur den Konten auf die Datenbank Zugriff zu gewähren, die auch wirklich Zugriff haben sollen, ist es empfehlenswert, mit einem eigenen Application-Pool-Konto, mit einem eigenen Dienstkonto für die Webanwendung zu arbeiten. Im Active Directory existiert daher in der Domäne schon eine Organization Unit Dienstkonten. Und in der gibt es eine weitere Organization Unit SharePoint. In der sind alle bisher verwendeten Dienstkonten, also auch zum Beispiel das Installationskonto SPSetup oder das Farmkonto SPFarm drin. Hier wird nun ein weiteres neues Konto erstellt, das explizit für die neue Webanwendung verwendet wird. Es beginnt im Namen mit SP für SharePoint, dann folgt ein Hinweis auf den Fully Qualified Domain Name sharepoint.spdemo.local sowie eine Kennung für AppPool, Application Pool. Also es handelt sich hier um ein Applikationspoolkonto. Das restliche Prozedere ist wie gewohnt wenn man Konten anlegt. Das Kennwort sollte hier abweichend sein von den Kennwörtern der anderen Dienstkonten, sonst macht die ganze Operation keinen Sinn. Allerdings sollte das Kennwort nie ablaufen. Wenn ein Ablauf eintritt, kann man das später als verwaltetes Konto in SharePoint definieren. Das heißt, SharePoint kann so angesteuert werden, dass es das Kennwort regelmäßig ändert. Sinnvoll ist noch, in der Beschreibung kurz zu vermerken, welchem Zweck dieses Konto dient. Weitere Voraussetzungen sind für dieses Konto nicht zu schaffen. Die Berechtigungen am SQL-Server zum Beispiel werden später im Einrichtungsprozess von SharePoint erstellt. Was aber sehr sinnvoll ist zum Härten noch, ist, dass man das Konto aus der standardmäßig vergebenen Gruppe Domänen-Benutzer rausnimmt und stattdessen eine eigens für SharePoint-Dienstkonten erstellten Gruppe hinzugefügt und diese Gruppe auch zur primären Gruppe macht. Erst dann kann man die Mitgliedschaft in der Domänenbenutzergruppe entfernen. Jetzt hat dieses SharePoint-Dienstkonto eigentlich keinerlei Rechte. Es darf sich nirgendwo anmelden und bekommt nur Berechtigungen für die Interaktion zwischen SharePoint-Webanwendung und Datenbank. Im nächsten Schritt wäre es wichtig, dieses Konto in der SharePoint-Zentraladministration im Abschnitt Sicherheit als verwaltetes Konto anzulegen. Das heißt, man wählt hier den Befehl Verwaltete Konten konfigurieren und trägt dieses eben erstellte Konto als Managed Service Account, also als verwaltetes Konto ein. Achten Sie bitte darauf, dass Sie Konten immer mit voranstehender Domäne angeben in SharePoint. Sie müssen hier das vergebene Kennwort hinterlegen. Dieses Kennwort wird verschlüsselt auch in der Datenbank gespeichert. Es besteht die Möglichkeit, dass man hier eine automatische Kennwortänderung aktiviert, sodass SharePoint regelmäßig dafür sorgt, dass dieses Kennwort neu erstellt wird und neu vergeben wird. Sehr sinnvoll die Option. Wenn der Farmadministrator dann gar keine genaue Kenntnis über das Kennwort hat, kann er später hier unter Verwaltete Konten einsteigen und könnte das Kennwort hier ändern an dieser Stelle. Gut, im letzten Step, wenn die SharePoint-Webanwendung mit Kerberos-Authentifizierung eingerichtet werden soll, muss für das Konto noch ein sogenannter Dienstprinzipalname eingetragen werden. Das geht wieder mit dem Tool setspn. Es empfiehlt sich, zuerst kurz zu prüfen, ob für dieses Konto bereits ein Dienstprinzipalname hinterlegt wurde. Das geht über die Option -l und Angabe des Kontos. Man sieht, es wurde noch kein Dienstprinzipalname angegeben. Dementsprechend ist dieser mit setspn -a hinzuzufügen. Die Dienstkennung ist zuerst auf HTTP beschränkt. Dann folgt ein Slash, also kein Backslash, sondern der Slash über der 7. Anschließend der Fully Qualified Domain Name, der im Browser auch angegeben wird. In unserem Fall also sharepoint.spdemo.local. Anschließend das Konto, für das der Dienstprinzipalname eingetragen werden soll. Damit wurden die wesentlichen Voraussetzungen geschaffen, um dann in der Zentraladministration im Abschnitt Anwendungsverwaltung eine neue Webanwendung einzurichten und die Arbeit hier in einem Prozess durchgehen zu können.

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
Erscheinungsdatum:24.10.2016

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!