Office Web Apps Installation und SharePoint Integration

Einleitung

Office Web Apps (auch OWA, WAC = Web Application Companion oder OWC = Office Web Components genannt) ermöglichen die Darstellung und Bearbeitung von MS-Office-Dokumenten und PDF-Dateien direkt im Web-Browser. Dabei ist es nicht mehr nötig, dass das MS-Office-Paket auf dem Client-PC installiert ist, um Microsoft Office Dokumente bearbeiten zu können.
Die OWA-Funktionalität kann nicht nur von SharePoint (SP) benutzt werden, sondern auch von anderen Microsoft-Diensten wie Exchange, Lync o.Ä.

In dieser Anleitung möchte ich zeigen, wie Office Web Apps Installaton und SharePoint Integration aussehen könnte.

Ist-Zustand

SharePoint Umgebung

In diesem Testszenario läuft die Kommunikation von außen (Internet) und auch von innen per https (SSL:443) über den LB (LoadBalancer), der die Anfrage terminiert und sie weiter per http (80) leitet. Die Zertifikate sind daher direkt auf dem LB hinterlegt.

Voraussetzungen

Netz und Kommunikation

  • Clients (Web-Browser) müssen Anforderungen an die OWA-Farm per http(s) auf Ports 80(443) übermitteln können.
  • Kommunikation von SP-Farm zu OWA-Farm und umgekehrt auf den Ports 80 und 443
  • 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.

Installation

Es sollten keine anderen Komponenten auf den OWA Server installiert werden (kein Exchange, kein SP etc.).

Die IIS-Einstellungen werden in regelmäßigen Abständen wieder auf OWA-Standard zurückgesetzt (spätestens nach dem Serverneustart).

Ersten OWA-Server in die Farm aufnehmen

Features installieren

Auf jedem der OWA-Server müssen die nötigen Server-Features installiert werden. Am leichtesten geht es mit PowerShell und folgendem Befehl (für Server 2012):

OWA-Setup

OfficeWebApps Installationsdateien und Sprachdateien auf jedem der OWA-Server installieren.

OWA-Farm konfigurieren

Mit dem Code im folgenden Beispiel wird eine neue Office Web Apps Server-Farm mit einem einzelnen Server erstellt.

Diesen Befehl auf dem ersten OWA-Server der Farm ausführen. Dieser Server wird der Master.

Folgende Parameter sind möglich:

  • Die URL, die Sie für -InternalURL angeben, ist der Name des Servers, auf dem Office Web Apps Server ausgeführt wird (Beispiel: http://owa-server).
  • Mit dem Parameter –AllowHttp wird die Farm für die Verwendung von HTTP konfiguriert.
  • Die Option -SSLOffloaded ermöglicht die HTTPS-Terminierung im LB
  • Der Parameter -EditingEnabled ermöglicht die Bearbeitung der Office-Dokumente in Office Web Apps, wenn diese Anwendung zusammen mit SharePoint 2013 verwendet wird. Bitte achten Sie auf die zum Editieren vorhandene Lizenz.
    Der Parameter -EditingEnabled wird von Lync Server 2013 oder Exchange Server 2013 nicht verwendet, da von diesen Hosts keine Bearbeitung unterstützt wird.

Falls .NET Framework 3.5-Komponenten installiert und später wieder entfernt wurden, erscheint beim Ausführen von Office Web Apps Cmdlets unter Umständen die Meldung „500 Web Service Exceptions“ oder „500.21 – Internal Server Error„.

Führen Sie zum Beheben dieses Fehlers an einer Eingabeaufforderung mit erhöhten Rechten folgende Beispielbefehle aus, um die Einstellungen zu bereinigen, die möglicherweise dazu führen würden, dass Office Web Apps Server nicht ordnungsgemäß funktioniert:

Für Windows Server 2008 R2

Für Windows Server 2012 oder Windows Server 2012 R2

Weiteren Server zur OWA-Farm hinzufügen

Features installieren

Auf jedem der OWA-Server müssen die nötigen Server-Features installiert werden. Am leichtesten geht es mit PowerShell und folgendem Befehl (für Server 2012):

OWA-Setup

OfficeWebApps Installationsdateien und Sprachdateien auf jedem der OWA-Server installieren.

Server aufnehmen

Folgender Befehl muss auf jedem OWA-Server ausgeführt werden, der zusätzlich zum Server01 in die Farm aufgenommen werden soll. In diesem Fall wird der Befehl auf dem Server owa-server02 ausgeführt.

Hinweis:
owa-server01 ist der Server, der bereits (als aller erster) in die leere Farm aufgenommen wurde, und Master-Server darstellt.

Zugriff auf eine Domäne einschränken

Damit die Funktionen der OWA-Farm nicht von überall und jedem benutzt werden können, gibt es die Möglichkeit den Zugriff auf eine ADOU und/oder auf eine/mehrere Domänen einzuschränken.

Anzeigen der erlaubten Domänen kann man mit:

Den Domänenzugriff kann man mit folgendem Befehl auf eine Domäne einschränken:

Wobei sp.domain.de die SharePoint-Webadresse ist, und somit die Nutzung der OWA-Funktionen nur durch SharePoint erlaubt wird.

SharePoint-Farm anbinden (WOPI-Binding)

Damit SharePoint die OWA-Funktionen nutzen kann, muss die SP-Farm an die OWA-Farm angebunden (WOPI-Binding konfiguriert) werden.

Die ab jetzt kommenden Befehle müssen in der SP-Farm auf einem der SP-Server ausgeführt werden (nicht auf den OWA-Servern).

Entweder die SharePoint Management Shell benutzen SharePoint 2013 Management Shell - Icon 1 (dort sind die nötigen Module schon geladen), oder vorher die SP-Module mit dieser Zeile einmalig Laden (als Admin in der PowerShell):

SharePoint Anbindung hinzufügen

Mit dem Befehl wird ein neues WOPI-Binding angelegt und somit die Verbindung von SharePoint zu OWA konfiguriert.
Wobei „owa.domain.de“ der FQDN der URL ist, die Sie für die interne URL festlegen. Dies ist der Einstiegspunkt für den Datenverkehr von Office Web Apps Server.

Für das Testsystem kann man auch den Schalter -AllowHTTP verwenden, damit SharePoint 2013 Ermittlungsinformationen aus der Office Web Apps Server-Farm per HTTP empfangen kann. Ohne den Parameter „-AllowHTTP“ wird von SharePoint 2013 versucht, per HTTPS mit der Office Web Apps Server-Farm zu kommunizieren.

So kann man die WOPI-Bindung auch wieder entfernen

Bei Bedarf kann man die WOPI-Bindung auch wieder entfernen:

WOPI-Zone überprüfen

Mit dem folgenden Befehl kann man die WOPI-Zone überprüfen.

Geben Sie „external“ an, wenn es sich bei Ihrer SharePoint-Farm sowohl um eine interne als auch um eine externe Farm handelt. Handelt es sich bei Ihrer SharePoint-Farm um eine rein interne Farm, geben Sie „internal“ an.

Ändern der WOPI-Zone (sofern erforderlich)

Abhängig von Ihrer Umgebung ist unter Umständen eine Änderung der WOPI-Zone erforderlich. Geben Sie „external“ an, wenn es sich bei Ihrer SharePoint-Farm sowohl um eine interne als auch um eine externe Farm handelt. Handelt es sich bei Ihrer SharePoint-Farm um eine rein interne Farm, geben Sie „internal“ an.

Falls Sie vorhin das Ergebnis internal-https erhalten und es sich bei der SharePoint-Farm um eine rein interne Farm handelt, können Sie diesen Schritt überspringen. Falls es sich bei Ihrer SharePoint-Farm sowohl um eine interne als auch um eine externe Farm handelt, müssen Sie den folgenden Befehl ausführen, um die Zone in external-https zu ändern

Sie müssen 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

Nun ist die grundsätzliche Konfiguration beendet.

Dokumentenbearbeitung auf andere Benutzerkreise erweitern

Alle im SharePoint berechtigten Benutzer können nun Dokumente auch ohne auf ihrem Computer installiertes MS-Office anzeigen (die Menüs zum Bearbeiten werden nicht angezeigt)

Office Web Apps - Dokument Vorschau - Im Browser anzeigen - Button
Das Menü zum Bearbeiten wird nicht angezeigt
Office Web Apps - Dokument Anzeige - Button zum Bearbeiten nicht vorhanden - OWA
Button zum Bearbeiten nicht vorhanden

Die administrativen Accounts können Dokumente im Browser auch editieren.

Man kann nun zusätzlich für bestimmte AD-Sicherheitsgruppen das Editieren aktivieren (falls die Lizenzierung dies erlaubt).

Vorhandene Lizenztypen anzeigen lassen (zum Editieren muss auch „OfficeWebAppsEdit“ dabei sein:

Anzeigen, welche AD-Gruppen/Personen welche „licenses“ nutzen können:

Mit diesen Zeilen kann man allen Benutzern einer AD-Gruppe das Recht zum Editieren geben.

Oder hiermit allen Benutzern einer Domäne das Editieren erlauben (Lizenzen sicherstellen)

Prüfen, ob die Gruppe übernommen wurde:

Jetzt sollten auch die Buttons zum Bearbeiten vorhanden sein.

Office Web Apps - Dokument Vorschau - Im Browser bearbeiten - Button - OWA

Office Web Apps - Dokument Anzeige - In Word Web App bearbeiten - Button - OWA

Tests

WOPI-Schnittstelle testen

Ob die Server auf Anfragen reagieren (WOPI-Schnittstelle), kann man mit folgenden Adressen im Browser auf dem Server prüfen:

http://owa-server01.domain.de/hosting/discovery 
http://owa-server02.domain.de/hosting/discovery

Mit folgender Adresse kann man die Erreichbarkeit der OWA-Farm, von der SP-Farm oder Internet aus, über den LB prüfen:

https://owa.domain.de/hosting/discovery

Die XML-Ausgabe im Browser sollte so ähnlich aussehen:

IIS auf .svc-Dateien testen

Hiermit wollen wir testen, ob der IIS mit .svc Dateien umgehen kann. Dabei darf kein 404-Fehler auftreten.

Im Browser folgende Adresse aufrufen. Die Antwort im Browser sollte „true“ sein.
https://owa.domain.de/m/met/participant.svc/jsonAnonymous/BroadcastPing

Diese URL ist optimal, um die Serverereichbarkeit per LB zu testen.

In PS folgende Zeile ausführen (vorher natürlich den Namen anpassen).

Die Ausgabe sollte folgenden Inhalt enthalten:

  • StatusCode: 200
  • StatusDescription: OK
  • Content: true

Office Web Apps - PowerShell Invoke-WebRequest - participant.svc-jsonAnonymous - StatusCode 200 - Content OK

Falls der Test scheitert, so wurde das Feature „NET-WCF-HTTP-Activation45“ vermutlich nicht installiert.

Dazu im Server-Manager unter „Verwalten“ > Rollen und Features hinzufügen, das Feature „HTTP Activation“ unter .NET Framework 4.5 > WCF Services installieren.

Oder per PowerShell:

Zehn Minuten warten (oder den Server rebooten) und dann erneut testen.

OWA-Server „HealthStatus“ prüfen

Mit diesem Kommando kann man den Status der Office-Web-Apps-Server prüfen. Bei allen Maschinen in der OWA-Farm sollte der Status „Healthy“ sein.

In der PowerShell-Konsole auf einem der OWA-Server ausführen:

OWA-Server HealthStatus - Get-OfficeWebAppsFarm.Machines - Healthy

Rendering Test

Mit diesem Test kann man ein Test-Dokument im Browser rendern lassen.

Die Syntax für den Aufruf ist: http://name_of_your_server/op/generate.aspx
In diesem Fall: https://owa.domain.de/op/generate.aspx

Office Web Apps - OWA - Rendering Test - Provide a link that opens Word, Excel, or PowerPoint files in a web browser

Die Voraussetzungen für diesen Test sind:

  • Domäneneinschränkung ist nicht aktiv
    (Remove-OfficeWebAppsHost -domain "sp.domain.de")
  • Öffnen von URLs ist erlaubt
    (Set-OfficeWebAppsFarm -OpenFromUrlEnabled:$true)
  • Das Dokument liegt im öffentlichen Raum (im SP)

Fehler und Lösungen

500 Web Service Exceptions

Lösung

OWA 500 Error

500.21 – Internal Server Error

Lösung

OWA 500 Error

New-OfficeWebAppsMachine : Machine not found in farm topology

Lösung

New-OfficeWebAppsMachine : Machine not found in farm topology

Seite nicht gefunden.

Seite nicht gefunden. Die Seite, nach der Sie suchen, ist nicht vorhanden.

Lösung

ID: 1004, ID: 2004 – OfficeWebApps Machine health is Unhealthy

ID: 1004, ID: 2004 – OfficeWebApps Machine health is Unhealthy

Lösung

ID: 1004, ID: 2004 – OfficeWebApps Machine health is Unhealthy

 

 

CMD-Lets Liste

CMD-Lets (OWA-Server)

CMD-Lets (SP-Server)

Links

  1. technet.microsoft.com: Bereitstellen von Office Web Apps Server
  2. www.wictorwilen.se: Office Web Apps Server 2013 – machines are always reported as Unhealthy

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.