Einführung in Office Web Apps Server

Veröffentlichung des Originalartikels: 11.09.2012

Dieser Beitrag wurde von Nick Simons verfasst, einem Senior Program Manager für Office Web Apps.

Im Sommer 2010 stellten wir Ihnen Office Web Apps vor: browserbasierte Versionen von Word, PowerPoint, Excel und OneNote. Diese Produkte wurden als SharePoint-Anwendungssatz zur Verfügung gestellt. Kunden, die Office Web Apps in ihren eigenen Netzwerk bereitstellten, installierten zu diesem Zweck Office Web Apps auf SharePoint-Servern.

Damals schien eine nahtlose SharePoint-Integration die beste Vorgehensweise zu sein. SharePoint kam und kommt auch weiterhin eine wichtige Bedeutung im Zusammenhang mit Office Web Apps zu. Außerdem weist SharePoint ein klar definiertes Modell zum Integrieren von Anwendungen wie die Office Web Apps auf. Als wir jedoch mit der Planung der nächsten Version von Office Web Apps begannen, zeigte sich, dass bestimmte zentrale Ziele mit einer so eng in SharePoint integrierten Architektur nur schwer umzusetzen sein würden.

Wir wollten das Setup und die Kapazitätsplanung vereinfachen und den Partnerverbund für mehrere Serverfarmen ermöglichen. Darüber hinaus wollten wir Anfragen bezüglich der Integration von neuen Partnern wie z. B. Lync berücksichtigen. Schließlich bekamen wir von vielen Kunden zu hören, sowohl auf Office 365 als auch lokal, dass sie sich dieselben Verbesserungen wie unsere SkyDrive-Benutzer wünschen.

Zur Umsetzung dieser Ziele begannen wir von vorn und überlegten uns, wie die Office Web Apps nun und in Zukunft in andere Produkte integriert werden würden. Wir entwickelten ein neues Modell, mit dem Office Web Apps von einer spezifischen Partnertechnologie getrennt wurde. Unser Modell bedeutete letztlich einen relativ geringen Codieraufwand für Dateihosts wie etwa SharePoint, während wir Office Web Apps auf völlig separaten Servern ausführen konnten.

Dieses neue eigenständige Serverprodukt ist Office Web Apps Server.

Uns ist bewusst, dass die Idee eines weiteren Servertyps auf den ersten Blick zusätzliche Komplexität und zusätzlichen Arbeitsaufwand für den Administrator mit sich zu bringen scheint. Das eigenständige Modell bietet jedoch die folgenden Vorteile:

1.  Einfacheres Setup

2.  Upgrade und Wartung sind vollständig von SharePoint getrennt

3.  Mehrere SharePoint-Farmen werden in eine einzelne Office Web Apps Server-Farm integriert

4.  Andere Produkte wie z. B. Exchange oder Lync und Drittanbieterprodukte werden in Office Web Apps integriert

5.  Bereitstellung neuer Features und Verbesserungen für unsere webbasierten und lokalen Kunden praktisch zum selben Zeitpunkt

Beim Vergleich vorheriger Office Web Apps-Bereitstellungen in SharePoint 2010 mit neuen Bereitstellungen mithilfe von Office Web Apps Server zeigen sich die Vorteile.

Mit der vorherigen Version von Office sah eine typische Office Web Apps-Bereitstellung so oder ähnlich aus...

 

Beachten Sie, dass die vorherige Version von Office Web Apps auf jeder Serverfarm und auf jedem Computer in jeder Serverfarm installiert werden musste. Die Skalierung von Office Web Apps war an die allgemeine SharePoint-Skalierung gebunden. Darüber hinaus musste zum Aktualisieren von Office Web Apps Code auf jedem Computer in allen Ihren SharePoint-Farmen aktualisiert werden.

Mit Office Web Apps Server sieht eine Bereitstellung eher wie folgt aus...

 

Wie Sie sehen, kann eine einzelne Office Web Apps Server-Farm für mehrere SharePoint 2013-Farmen sowie Lync 2013 und Exchange 2013 (Outlook Web Access) verwendet werden. Darüber hinaus können Sie mit Ihrer Office Web Apps-Farm alle per URL oder UNC zugänglichen Word-, Excel- und PowerPoint-Dateien anzeigen.

Kurze Übersicht über das neue Integrationsmodell

Im Folgenden finden Sie eine Übersicht über die Integration von Office Web Apps in einen Dateihost wie etwa SharePoint. Diese Informationen dienen dem Verständnis der weiter unten beschriebenen Netzwerk- und Sicherheitsanforderungen.

Zunächst ein paar Definitionen:

• Office Web Apps Server – stellt Hosts Office Web Apps-Funktionalität bereit und wird in diesem Artikel behandelt.
• Host – zeigt mithilfe der Dienste von Office Web Apps Server Dateien in einem Webbrowser an. Beispielsweise handelt es sich bei SharePoint Server 2013, Lync Server 2013 und Exchange Server 2013 um Hosts.
• Client – ein Browser oder eine ähnliche Software.

Ein zentraler Bestandteil des neuen Integrationsmodells ist eine neue öffentliche Anwendungsprogrammierschnittstelle (Application Programming Interface, API), die von Office Web Apps für die Kommunikation mit Hosts verwendet wird. Diese API wird als WOPI (Web application Open Platform Interface) bezeichnet. Dateien werden von Office Web Apps Server mithilfe der WOPI-API abgerufen und bearbeitet. Office Web Apps Server wird oft auch als WOPI-App bezeichnet. Hosts müssen die WOPI-Anforderungen von WOPI-Apps verstehen.

WOPI ist eine RESTful-API, die HTTP/HTTPS verwendet. Dies bedeutet, dass unter anderem der gesamte Datenverkehr zwischen Hosts und Office Web Apps Server über standardmäßige HTTP/HTTPS-Ports übermittelt wird. Dies bedeutet auch, dass Office Web Apps Server soweit wie möglich statusfrei ist. Dadurch wird die Anfälligkeit für eine Reihe von Fehlern reduziert, die von Netzwerkausfällen bis hin zum Totalausfall von Hardware reichen kann.

Lassen Sie uns zum besseren Verständnis der Funktionsweise von WOPI ein einfaches Szenario betrachten, bei dem die Benutzerin Sally die in SharePoint gehostete Datei test.docx anzeigt. Und so sieht das Szenario im Einzelnen aus:

1.  Sally navigiert zur Dokumentbibliothek, in der test.docx gespeichert ist.

2.  Sally klickt in der Dokumentbibliothek auf den Dateinamen.

3.  SharePoint navigiert im Browser zu einer speziellen SharePoint-Seite, auf der Anforderungen für Office Web Apps Server (und andere WOPI-Apps) ausgeführt werden können. Diese SharePoint-Seite heißt in diesem Szenario WOPIFrame.aspx.

4.  WOPIFrame.aspx enthält einen iFrame (https://dev.w3.org/html5/spec/the-iframe-element.html), in dem zu einer Seite auf dem Office Web Apps Server navigiert wird. Diese Seite heißt in diesem Szenario WordViewer.aspx. Die HTTP-Anforderung für WordViewer.aspx enthält einige wichtige Informationen:

• • Die URL, mit der Office Web Apps Server test.docx abrufen wird. Dies wird als WOPI-Endpunkt bezeichnet.
  • Den Namen der Datei. Wir fassen den WOPI-Endpunkt und den Dateinamen zu einem einzigen Parameter zusammen, den wir als WOPI-Quelle bezeichnen.
  • Eine Zeichenfolge, die von Office Web Apps an den WOPI-Endpunkt übergeben werden kann und die Anmeldeinformationen von Sally repräsentiert. Diese Zeichenfolge bezeichnen wir als Zugriffstoken.
    Aus Sicherheitsgründen hat Sally mit dem Zugriffstoken nur Zugriff auf eine ganz bestimmte Datei. Falls ein Benutzer mit böswilligen Absichten das Zugriffstoken entwendet, könnte er die Identität von Sally nur im Kontext dieser einzigen Datei annehmen. Das ist natürlich auch schlimm, weshalb dieses Zugriffstoken mit SSL geschützt werden sollte.

5.  Office Web Apps Server verwendet die WOPI-Quelle und das Zugriffstoken zum Abrufen von test.docx von SharePoint.

6.  WordViewer.aspx zeigt test.docx im iFrame in WOPIFrame.aspx an.

In der folgenden Abbildung ist der Datenfluss zwischen Browser, SharePoint und Office Web Apps Server dargestellt...

Einrichten der Office Web Apps Server-Farm

Bei einer Serverfarm kann es sich in diesem Szenario um eine einzelne virtuelle Maschine, die auf einem freigegebenen Server ausgeführt wird, bis hin zu einer Farm mit Dutzenden von Rechenzentrumsservern handeln. Setup und Wartung sind im Prinzip in allen Fällen identisch. Die genauen Voraussetzungen und Schritte zum Erstellen einer Farm sind natürlich im Lieferumfang des Produkts enthalten. Diese Dokumentation soll an dieser Stelle nicht reproduziert werden. Ich werde die Anforderungen grob skizzieren.

Hardware

Zunächst benötigen Sie einige Server. Angenommen, Sie richten eine Farm für 80.000 Benutzer mehrerer SharePoint-Farmen ein. Sie benötigen wahrscheinlich 4 Server mit...

• Windows Server 2008 R2 oder Windows Server 2012 mit allen Voraussetzungen
• 8 Kerne
• 8 GB RAM
• einer Festplatte entsprechender Größe (mind. 60 GB)

Darüber hinaus benötigen Sie ein Lastenausgleichsmodul. Wir bei Microsoft verwenden eine Farmkonfiguration mit 10 Servern, die ein F5 BIG-IP-Hardwarelastenausgleichsmodul gemeinsam mit einer Reihe weiterer Serverprodukte verwendet. Diese Konfiguration funktioniert hervorragend, aber jede geeignete Lastenausgleichslösung erfüllt denselben Zweck. Wir empfehlen jedoch dringend, dass die Lastenausgleichslösung die Affinität unterstützt. Bezüglich der Leistung ist es äußerst hilfreich, wenn alle Anforderungen für eine bestimmte Sitzung vom selben Server verarbeitet werden.

Netzwerk

Ich gehe davon aus, dass Ihre Benutzer Zugriff auf Office Web Apps sowohl vom internen Netzwerk aus als auch über das Internet haben sollen. In diesem Fall müssen Sie internes und externes DNS für Ihre Farm einrichten. Sie könnten aber auch nur externes DNS einrichten und interne DNS-Regeln für interne Anforderungen in Ihrem privaten Netzwerk verwenden. Ich würde jedenfalls so vorgehen.
Sie müssen aber Ihr Netzwerk entsprechend Ihren Anforderungen einrichten. Folgendes muss jedoch erfüllt sein:

• Clients (in der Regel Webbrowser) müssen Anforderungen an die Farm übermitteln können. Hierbei handelt es sich um übliche HTTP/HTTPS-Anforderungen auf Port 80 bzw. 443.
• Server in der Office Web Apps-Farm führen Anforderungen für einen Dienst auf dem Dateihost aus (z. B. SharePoint). Bei diesen Anforderungen handelt es sich ebenfalls um HTTP/HTTPS-Anforderungen auf Port 80 oder 443. Auf diese Weise verarbeiten Office Web Apps-Server die Dateien, die sie rendern oder bearbeiten.
• Dateihosts müssen gelegentlich Informationen direkt von der Office Web Apps Server-Farm über das Lastenausgleichsmodul anfordern. Bei diesen Anforderungen handelt es sich ebenfalls um HTTP/HTTPS-Anforderungen auf Port 80 oder 443.
• Alle Server in der Office Web Apps Server-Farm müssen miteinander über Port 809 kommunizieren. Idealerweise befinden sich diese Server in einem privaten Subnetz, sodass kein anderer Server der Farm beitreten oder Datenverkehr lauschen kann. Andernfalls gibt es integrierte Features in Office Web Apps Server, um eine Farm in einem offeneren Netzwerk zu schützen. Diese Features sollen hier jedoch nicht behandelt werden. Weitere Informationen hierzu finden Sie unter Sicherheitsplanung für Office Web Apps Server Preview.

Sie müssen unbedingt sicherstellen, dass diese Netzwerkrouten ordnungsgemäß eingerichtet sind. Die Office Web Apps sind relativ einfach, sind aber nur funktionsfähig, wenn die Kommunikationskanäle offen sind.

Sicherheit

Wie bereits im vorherigen Abschnitt beschrieben, beinhaltet die Anforderung zum Rendern oder Bearbeiten einer Datei Benutzeranmeldeinformationen in Form eines Zugriffstokens. Dieses Zugriffstoken ist wiederum in allen Anforderungen von Office Web Apps bei Hosts enthalten. Der gesamte Datenverkehr muss mit SSL geschützt werden, außer Sie befinden sich in einem privaten Netzwerk und vertrauen allen Benutzern, die Zugriff auf dieses Netzwerk haben. Selbst in diesem Fall sollten Sie unbedingt SSL verwenden.
Zum Einrichten von SSL müssen Sie Zertifikate erstellen und auf jeden Office Web Apps Server-Computer oder auf das Lastenausgleichsmodul kopieren. Falls Sie SSL auf dem Lastenausgleichsmodul beenden, können Sie spezielle Einstellungen in Office Web Apps Server verwenden, die ich gleich behandeln werde.

Konfiguration von Office Web Apps Server

Nachdem Sie nun über die gesamte Hardware und Netzwerkinfrastruktur verfügen, ist es an der Zeit, Ihre Office Web Apps Server-Farm zu erstellen. Zunächst installieren Sie Office Web Apps Server und die zugehörigen Sprachpakete auf allen Servern. Versuchen Sie nicht, irgendeine andere Software auf den Servern zu installieren. Kein SharePoint. Kein Exchange. Nichts. Verwenden Sie virtuelle Maschinen, falls Sie Hardware gemeinsam nutzen möchten.

Anschließend führen Sie den folgenden Windows PowerShell-Befehl auf dem ersten Server in der Farm aus (wir bezeichnen ihn als Server1). Dabei wird von Folgendem ausgegangen:

• Sie richten nur externes DNS unter der URL https://officewebapps.contoso.com ein. Hierbei kann es sich um eine beliebige URL handeln, die Sie einrichten möchten.
• Sie richten eine Office Web Apps Server-Farm ein, um das Bearbeiten sowie das Anzeigen zu unterstützen.
  Führen Sie diesen Schritt nur aus, wenn Ihre Organisation über die entsprechenden Lizenzen zum Bearbeiten verfügt. Die Lizenzierung soll hier nicht behandelt werden. Ich möchte lediglich darauf hinweisen, dass das Anzeigen in Office Web Apps im Gegensatz zum Bearbeiten kostenlos ist. Weitere Informationen finden Sie unter Planen von Office Web Apps Preview (verwendet mit SharePoint 2013 Preview-Produkten).
• Sie beenden SSL auf dem Lastenausgleichsmodul.

Und so sieht der Windows PowerShell-Befehl aus:

New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded

Damit verfügen Sie über eine Office Web Apps Server-Farm mit einem einzelnen Server.

Anschließend fahren Sie mit Server2 fort. Führen Sie auf diesem Server folgenden Befehl aus:

New-OfficeWebAppsMachine -MachineToJoin "Server1"

Damit verfügen Sie über eine Farm mit zwei Servern. Wiederholen Sie den vorherigen Schritt für Server3 und Server4.

Herstellen einer Verbindung mit SharePoint

Ihre Office Web Apps-Farm ist zu diesem Zeitpunkt einsatzbereit. Allerdings ist sie noch nicht mit Hosts verbunden. Um eine Verbindung zwischen einer SharePoint-Farm und dieser Office Web Apps Server-Farm herzustellen, öffnen Sie eine Windows PowerShell-Eingabeaufforderung auf einem beliebigen Server in der SharePoint-Farm, und führen Sie den folgenden Befehl aus:

New-SPWopiBinding -ServerName "officewebapps.contoso.com"

Darüber hinaus müssen Sie folgenden Befehl ausführen, um die SharePoint-Farm anzuweisen, dass Sie die externe URL der Office Web Apps Server-Farm verwenden möchten und dass HTTPS verwendet wird.

Set-SPWopiZone -Zone "external-https"

Das wäre schon alles. Navigieren Sie zu einer Dokumentbibliothek in der SharePoint-Farm, um wie gewünscht Office-Dateien zu erstellen, anzuzeigen und zu bearbeiten. Es ist keine weitere Konfiguration erforderlich.

Führen Sie schließlich den folgenden Befehl aus, wenn Sie die Office Web Apps Server-Farm von SharePoint trennen möchten:

Remove-SPWopiBinding -All

Wenn Sie nun zu einer Dokumentbibliothek in der SharePoint-Farm navigieren, ist keine Spur der Office Web Apps vorhanden.

Sie können beliebig viele SharePoint-Farmen mit einer einzelnen Office Web Apps-Farm verbinden. Dasselbe gilt, wenn Sie eine Verbindung von Exchange und Lync mit einer Office Web Apps-Farm herstellen. Weitere Informationen finden Sie unter Exchange Server 2013: Office Web Apps Server-Integration und Bereitstellen von Office Web Apps Server und Lync Server 2013.

Abrufen von Updates für Office Web Apps Server

Von Anfang an haben wir uns um häufige Updates für die Office Web Apps bemüht. Die Updates haben wir aber nur lokalen Kunden in Form von Service Packs geliefert. Nach der Veröffentlichung von Office Web Apps Server 2013 möchten wir Updates wesentlich häufiger zur Verfügung stellen. Wir sind der Meinung, dass dies für Administratoren machbar ist, da das Aktualisieren von Office Web Apps Server sehr einfach ist.

Zum Aktualisieren der Server in einer Office Web Apps Server-Farm müssen Sie die Server aus dem Lastenausgleichsmodul und der Farm entfernen. Dieser Vorgang kann jedoch so gehandhabt werden, dass die Benutzer praktisch nicht beeinträchtigt werden.
Wenn Sie z. B. über eine Farm mit vier Servern verfügen, schalten Sie zwei Server ab und upgraden sie. Anschließend erstellen Sie eine neue Farm mit diesen beiden Servern und verweisen das Lastenausgleichsmodul nicht auf die beiden Server in der ursprünglichen Farm, sondern auf diese beiden Server. Nun upgraden Sie die anderen beiden Server, fügen sie der neuen Farm hinzu und verweisen das Lastenausgleichsmodul ebenfalls auf diese Server.

Wenn Server aus der Farm entfernt werden, können bei manchen Benutzern kleinere Probleme auftreten, aber die Office Web Apps werden wiederhergestellt. Diese Vorgehensweise eignet sich aus offensichtlichen Gründen für alle Fälle außer einem Szenario mit einem einzelnen Server.

Weitere Informationen zu Office Web Apps Server

Zusätzliche Ressourcen für Office Web Apps Server finden Sie hier:
• Office Web Apps Preview-Bibliothek auf der TechNet-Website
• Exchange Server 2013: Office Web Apps Server-Integration
• Bereitstellen von Office Web Apps Server und Lync Server 2013
• Forum für das Setup und die Bereitstellung von Office Web Apps

Nick Simons
Senior Program Manager, Office Web Apps

 

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Introducing Office Web Apps Server.