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
- SharePoint 2013 SP1 (On-Premises, 3 Tier Cluster)
- MS SQL-Server 2008 R2 Failover-Cluster
- Backup: AvePoint DocAve 6 SP5
- OWA / WAC (Zwei Server im LB, bereit für die OWA-Installation)
- Workflow-Manager
- BI
- Monitoring
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):
# Required Features Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-WCF-HTTP-Activation45 # Recommended Features Add-WindowsFeature Web-Stat-Compression,Web-Dyn-Compression
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.
Import-module OfficeWebApps New-OfficeWebAppsFarm -InternalUrl "https://owa.domain.de" -ExternalUrl "https://owa.domain.de" -SSLOffloaded -EditingEnabled
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
%systemroot%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -iru iisreset /restart /noforce
Für Windows Server 2012 oder Windows Server 2012 R2
dism /online /enable-feature /featurename:IIS-ASPNET45
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):
# Required Features Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-WCF-HTTP-Activation45 # Recommended Features Add-WindowsFeature Web-Stat-Compression,Web-Dyn-Compression
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.
Import-module OfficeWebApps New-OfficeWebAppsMachine -MachineToJoin owa-server01
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 AD–OU und/oder auf eine/mehrere Domänen einzuschränken.
Anzeigen der erlaubten Domänen kann man mit:
# Anzeigen der erlaubten Domänen get-OfficeWebAppsHost
Den Domänenzugriff kann man mit folgendem Befehl auf eine Domäne einschränken:
# Domänenzugriff einschränken New-OfficeWebAppsHost -Domain "sp.domain.de"
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 (dort sind die nötigen Module schon geladen), oder vorher die SP-Module mit dieser Zeile einmalig Laden (als Admin in der PowerShell):
# SharePoint-Module laden try {Add-PSSnapin Microsoft.SharePoint.PowerShell} catch{}
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.
# Neue SP-OWA Bindung erzeugen New-SPWopiBinding -ServerName "owa.domain.de"
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.
# Neue SP-OWA Bindung im Testsystem erzeugen New-SPWopiBinding -ServerName "owa.domain.de" -AllowHTTP
So kann man die WOPI-Bindung auch wieder entfernen
Bei Bedarf kann man die WOPI-Bindung auch wieder entfernen:
# Bei Bedarf WOPI-Bindung entfernen Remove-SPWopiBinding -All
WOPI-Zone überprüfen
Mit dem folgenden Befehl kann man die WOPI-Zone überprüfen.
# WOPI-Zone überprüfen Get-SPWOPIZone <# Beispielausgabe: external-https #>
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
# Beispiel: SharePoint-Farm anweisen, die externe URL der OWA-Farm und HTTPS zu verwenden Set-SPWopiZone -Zone "external-https"
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)
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:
# Vorhandene Lizenztypen anzeigen Get-SPUserLicense <# Beispielausgabe: License ------- Enterprise Standard Project OfficeWebAppsEdit #>
Anzeigen, welche AD-Gruppen/Personen welche „licenses“ nutzen können:
# Anzeigen, welche AD-Gruppen/Personen welche "licenses" nutzen können Get-SPUserLicenseMapping <# Beispielausgabe: License : OfficeWebAppsEdit Name : domain\domänen-admins #> # Oder die Tabellenausgabe Get-SPUserLicenseMapping | sort License | ft * -auto
Mit diesen Zeilen kann man allen Benutzern einer AD-Gruppe das Recht zum Editieren geben.
# Editieren für eine AD-Gruppe erlauben $lmap = New-SPUserLicenseMapping -SecurityGroup "DOMAIN\ad-group" -License OfficeWebAppsEdit $lmap | Add-SPUserLicenseMapping Enable-SPUserLicensing
Oder hiermit allen Benutzern einer Domäne das Editieren erlauben (Lizenzen sicherstellen)
# Jedem in der Domäne das Editieren erlauben (Gruppe "Domänen-Benutzer") $lmap = New-SPUserLicenseMapping -SecurityGroup "DOMAIN\Domänen-Benutzer" -License OfficeWebAppsEdit $lmap | Add-SPUserLicenseMapping Enable-SPUserLicensing
Prüfen, ob die Gruppe übernommen wurde:
Get-SPUserLicenseMapping | sort License | ft * -auto
Jetzt sollten auch die Buttons zum Bearbeiten vorhanden sein.
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:
<wopi-discovery> <net-zone name="internal-http"> <app name="Excel" favIconUrl="https://owa.domain.de/x/_layouts/images/FavIcon_Excel.ico" checkLicense="true"> <action name="view" ext="ods" default="true" urlsrc="https://owa.domain.de/x/_layouts/xlviewerinternal.aspx?<ui=UI_LLCC&><rs=DC_LLCC&>"/> <action name="view" ext="xls" default="true" urlsrc="https://owa.domain.de/x/_layouts/xlviewerinternal.aspx?<ui=UI_LLCC&><rs=DC_LLCC&>"/> . . .
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).
# IIS auf .svc Dateien testen Invoke-WebRequest https://owa.domain.de/m/met/participant.svc/jsonAnonymous/BroadcastPing
Die Ausgabe sollte folgenden Inhalt enthalten:
- StatusCode: 200
- StatusDescription: OK
- Content: true
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:
# HTTP Activation Feature hinzufügen Import-Module ServerManager Add-WindowsFeature NET-WCF-HTTP-Activation45
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:
Import-module OfficeWebApps # OWA-Server HealthStatus prüfen (Get-OfficeWebAppsFarm).Machines
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
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
500.21 – Internal Server Error
Lösung
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)
Name Synopsis ---- -------- Get-OfficeWebAppsFarm Gibt Details zum OfficeWebAppsFarm-Objekt zurück, zu dem der aktuelle Server gehört. Get-OfficeWebAppsHost Gibt die Liste von Hostdomänen in der Zulassungsliste einer Office Web Apps Server-Farm zurück. Get-OfficeWebAppsMachine Gibt Einzelheiten zum aktuellen Server in einer Office Web Apps Server-Farm zurück. New-OfficeWebAppsFarm Erstellt eine neue Office Web Apps Server-Farm auf dem lokalen Computer. New-OfficeWebAppsHost Fügt eine Hostdomäne der Zulassungsliste einer Office Web Apps Server-Farm hinzu. New-OfficeWebAppsMachine Fügt den aktuellen Server einer vorhandenen Office Web Apps Server-Farm hinzu. Remove-OfficeWebAppsHost Entfernt eine Hostdomäne aus der Zulassungsliste einer Office Web Apps Server-Farm. Remove-OfficeWebAppsMachine Entfernt den aktuellen Server aus der Office Web Apps Server-Farm. Repair-OfficeWebAppsFarm Entfernt alle als instabil gekennzeichneten Server aus einer Office Web Apps Server-Farm. Set-OfficeWebAppsFarm Konfiguriert die Einstellungen einer vorhandenen Office Web Apps Server-Farm. Set-OfficeWebAppsMachine Ändert die Einstellungen des aktuellen Servers in einer Office Web Apps Server-Farm. New-WebApplication New-WebApplication... New-WebAppPool New-WebAppPool... Remove-WebAppPool Remove-WebAppPool... Remove-WebApplication Remove-WebApplication... Get-WebApplication Get-WebApplication... Get-WebAppDomain Get-WebAppDomain... Get-WebAppPoolState Get-WebAppPoolState... Start-WebAppPool Start-WebAppPool... Restart-WebAppPool Restart-WebAppPool... Stop-WebAppPool Stop-WebAppPool... ConvertTo-WebApplication ConvertTo-WebApplication...
CMD-Lets (SP-Server)
Name Synopsis ---- -------- Get-SPWOPIBinding Gibt eine Liste mit Bindungen zurück, die mithilfe von New-SPWOPIBinding in der aktuellen SharePoint-Farm erstellt wurden, in der dieses Cmdlet ausgeführt wird. New-SPWOPIBinding Erstellt eine neue Bindung, um Dateinamenerweiterungen oder Anwendungen Aktionen in der aktuellen SharePoint-Farm zuzuordnen, in der dieses Cmdlet ausgeführt wird. Remove-SPWOPIBinding Entfernt Bindungen für Anwendungen, Dateinamenerweiterungen und zugehörige Aktionen in der aktuellen SharePoint-Farm, in der dieses Cmdlet ausgeführt wird. Set-SPWOPIBinding Aktualisiert die Standardklickaktion für die Bindung einer Anwendung oder Dateinamenerweiterung. Get-SPWOPIZone Gibt die Zone zurück, die in der aktuellen SharePoint-Farm konfiguriert ist, die die WOPI-Anwendung verwenden soll. Set-SPWOPIZone Konfiguriert die Zone, die von der aktuellen SharePoint-Farm verwendet wird, um im Browser zur WOPI-Anwendung zu navigieren. Get-SPWOPISuppressionSetting Gibt die Unterdrückungseinstellungen für die aktuelle SharePoint-Farm zurück, in der dieses Cmdlet ausgeführt wird. New-SPWOPISuppressionSetting Das New-SPWOPISuppressionSetting-Cmdlet deaktiviert Office Web Apps für die Aktion, Dateinamenerweiterung oder Programmkennung, die Sie in der aktuellen SharePoint-Farm angegeben haben. Remove-SPWOPISuppressionSetting Entfernt die Unterdrückungseinstellungen für eine Dateinamenerweiterung oder Programm-ID und Aktion in der aktuellen SharePoint-Farm, in der dieses Cmdlet ausgeführt wird. Update-SPWOPIProofKey Aktualisiert den öffentlichen Schlüssel, der zum Herstellen einer Verbindung mit der WOPI-Anwendung in der aktuellen SharePoint-Farm verwendet wird, in der dieses Cmdlet ausgeführt wird.