SharePoint 2013-Administration Grundkurs

Exkurs: der IIS, ASP.NET und WCF

Testen Sie unsere 1920 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Immer wenn ein Benutzer eine SP-Seite im Browser aufruft oder Anwendungen Metadaten vom Server, startet ein Prozess, in dem viele Dienste und Komponenten miteinander kommunizieren. Für den Farmadministrator ist es wichtig, diese Abläufe genau zu kennen.

Transkript

Jedes Mal, wenn ein Benutzer eine SharePoint Seite im Browser aufruft, oder wenn Anwendungen Metadaten vom Server abrufen, wird ein Prozess gestartet, in welchem viele Dienste und Komponenten miteinander kommunizieren. Für den Farmadministrator ist es enorm wichtig, diesen Prozessablauf zu kennen und zu wissen, welcher Dienst mit welchen Komponenten kommuniziert. Aus diesem Wissen erschließt sich die Grundlage für eine Fehlersuche, sowie die gesamte Basis für die Farmverwaltung und Administration. Im folgenden Video werde ich die am Prozess beteiligten Komponenten vorstellen, und den Kommunikationsablauf mit Ihnen untersuchen. Nach Eintippen einer Adresse im Browser, wird in der Regel ein HTTP-Request ausgelöst. HTTP regelt dabei die Kommunikation, das heißt, das World Wide Web Consortium, W3C, hat hier vorgegeben, welche Kommandos an den Server geschickt werden müssen, man kann das sehr gut mit dem Anklopfen an einer Bürotür vergleichen, der, der im Büro sitzt, weiß dann genau, ah, da steht jemand draußen und möchte hinein. Der Internet Information Server wäre im Beispiel dann der, der im Büro drinsitzt, und den Request entgegennimmt, der also auf das Anklopfen mit "Herein", Protokoll gemäß antworten muss, damit der draußen Stehende eintritt, ASP.NET ist ein Compiler zur dynamischen Generierung von Browsercontent. Der Internet Information Server kann von Haus aus HTTP Anfragen abhandeln und Dokumente öffnen und deren Inhalt an den Anfragenden zustellen. Er kann jedoch nicht anhand von irgendwelchen Parametern die hereinkommen, dynamisch, Inhalt dynamisch harte Mail erzeugen, dafür wird ASP.NET benötigt. Die Windows Communication Foundation ist ganz ähnlich wie ASP.NET, eine Art Compiler, der allerdings keine harten Mail Daten, beziehungsweise Browsercontent generiert, sondern zum Beispiel in SOAP codierte Objektdaten oder Binärdaten, die dann von der anfragenden Anwendung weiter verarbeitet werden. Im HTTP-Response, verpackt dann der Internet Information Server die ermittelten Daten und schickt die an den Anfragenden, zum Beispiel eben den ganzen HTML-Code für den Browser, so das der Browser am Ende die Seite anzeigen kann. Im Internetinformationsdienste Manager unter Windows, werden die wesentlichen Parameter für die HTTP Kommunikation eingestellt, sowie ein Prozess eingestellt, in dem der ASP.NET, beziehungsweise der WCF-Compiler läuft. Der Begriff Anwendungspool, der auch in SharePoint häufig begegnet, bedeutet, dass ein Prozess unter Windows gestartet wird, mit dem Namen w3wp.exe. Das Konto unter dem dieser Prozess gestartet wird, wird im Anwendungspool im IIS eingestellt, und es können gegebenenfalls auch Leistungsbeschränkungen im Anwendungspool definiert werden. Der Anwendungspool als solches ist lediglich aber ein Windows Prozess, und eine Site-Konfiguration enthält dann die Bindung an eine IP-Adresse, die Bindung an einen TCP-Port, die Bereitstellung von SSL-Komponenten, Zertifikaten, die gesamte Anwendungskonfiguration für ASP.NET, beziehungsweise WCF, und auch die Authentifizierungs-Komponenten, sowie eine Zuordnung zu einem Anwendungspool, das bedeutet, wenn die Anfrage über eine IP-Adresse an den TCP-Port kommt, und ASP.NET zum Beispiel, etwas ausführen muss, dann wird diese Ausführung im Kontext des w3wp-Prozesses des Anwendungspools, durchgeführt, und der IIS liefert dann das Ergebnis aus. Konfliktpotential bei der Konfiguration entsteht, wenn mehrere Site-Definitionen an der gleichen IP und am gleichen Port definiert werden. Dann nämlich weiß der Internet Information Server nicht mehr, für wen jetzt der eingehende Request gedacht ist. Es muss dann entweder ein sogenannter Hostheadername angegeben werden, oder aber Server Name Indication by SSL. Ein ungültiges SSL-Zertifikat bei der Kommunikation mit einer Dienstanwendung, führt in der Regel zum Abbruch der Anforderungen, denn im Gegensatz zum Browser, kann der Dienst bei Niemandem nachfragen, er kann Niemanden aktiv darauf hinweisen, Hallo, da ist ein ungültiges Zertifikat, möchten Sie sich trotzdem verbinden, sondern er muss eigentlich die Kommunikation abbrechen, und es dann zum Beispiel im Windows Event Log in einem Ereignisprotokoll, vermerken. Wenn man nun diese Komponenten im Kommunikationsablauf betrachtet, dann sind auf dem SharePoint Server zunächst diverse Windows Dienste, in SharePoint als Dienste auf dem Server bezeichnet, aktiv, die in bestimmten Zeitabständen Daten in eine Datenbank schreiben. So geht der Suchdienst zum Beispiel hin und durchforstet regelmäßig Inhalte am Fileserver, in SharePoint, in anderen Quellen, und baut daraus in SQL Server Datenbanken einen Index auf. Das tut er völlig unabhängig vom Request- Responsekreislauf, den der Benutzer anstößt, wenn er im Browser eine Adresse eintippt, anschließend zunächst einen DNS Server kontaktiert, das tut der Browser, um eine IP-Adresse zu ermitteln, und dann die Verbindung zum Server an den TCP-Port, des Internet Information Servers herstellt, und den HTTP Request zustellt. In diesem Fall lautet der Request, Internet Information Server ich benötige den Inhalt des Dokumentes default.aspx. Der Internet Information Server erkennt anhand der Suffix der default, nämlich .aspx, dass es sich hier um eine dynamische Datei handelt, das heißt, er öffnet die Datei und gibt den Inhalt weiter an ASP.NET zur Kompilierung. Speziell in SharePoint wären wir genau jetzt bei der SharePoint Webanwendung angekommen, denn im Kontext der Webanwendung läuft ASP.NET. Die ASP.NET Webanwendung kontaktiert den Datenbank Server, gegebenenfalls mehrfach, zieht sich dort Daten die anwendungsspezifisch sind, und kontaktiert gegebenenfalls auch einen Webdienst oder auch mehrere Webdienste. Würde der Benutzer hier oben eine Suchanfrage stellen, dann würde die SharePoint Webanwendung auf dem Server mit der Suchdienstanwendung interagieren, und von der Suchdienstanwendung, die relevanten Suchergebnisse abfragen, die die Dienstanwendung wiederum vom Datenbankserver bezieht. Die Dienstanwendung liefert dann Binärdaten oder in SOAP codierte Daten, oder auch in proprietären Protokollen codierte Daten, an die ASP.NET Webanwendung, an die SharePoint Webanwendung, die in der SharePoint Webanwendung als HTML, beziehungsweise als Browsercontent, also HTML, Javascript, XML, CSS, was der Browser eben alles versteht, aufbereitet, das Ergebnis dann an den IIS liefert, und der IIS das Ergebnis von ASP.NET an den Browser zustellt, so dass der dann die Seite anzeigen kann. Je nach Fehlersituation, je nach Ablauf, muss man also immer entscheiden, wer hat gerade mit wem gesprochen, habe ich bereits eine IP-Adresse bekommen, so dass ich mich zum IIS konnektieren kann, hat der IIS mit ASP.NET kommuniziert, konnte ASP.NET auf die Datenbank zugreifen, konnte die SharePoint Webanwendung, respektive ASP.NET, mit der SharePoint Dienstanwendung kommunizieren, oder gab es da vielleicht ein Problem mit SSL, konnte die Dienstanwendung auf den Datenbankserver zugreifen, läuft der zugehörige Windows Dienst, der ja permanent Daten liefen muss, die gegebenenfalls von der SharePoint Dienstanwendung abgefragt werden. All das sind potentielle Störquellen, die es gilt zu ermitteln. Bei der Einrichtung einer SharePoint Farm, muss ja mindestens eine SharePoint Webanwendung existieren, die dann Inhalte über Websitesammlungen und Websites nach draußen gibt, so das also bei der Einrichtung, die hier gezeigten Komponenten, alle konfiguriert werden müssen. Es müssen Sites im IIS angelegt werden, es muss ein Anwendungspool angelegt werden, dem Anwendungspool muss ein Konto zugeordnet werden, die nötigen Dienstanwendungen müssen im IIS konfiguriert sein und funktionieren, die Windows Dienste müssen gestartet werden, und all das zusammengenommen bildet dann eigentlich die Webanwendung, die im Kontext einer SharePoint Farm mit verschiedenen Dienstanwendungen interagiert.

SharePoint 2013-Administration Grundkurs

Sehen Sie, worauf es bei der Planung, Einrichtung und Administration einer SharePoint-Farm auf Basis von SharePoint Foundation 2013 bzw. SharePoint Server 2013 ankommt.

6 Std. 29 min (67 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:13.06.2013

Für SharePoint Foundation 2013 und SharePoint Server 2013.

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!