Introducing Office Web Apps Server

Artykuł
09/11/2012

This post is written by Nick Simons, a Senior Program Manager for Office Web Apps.

In the summer of 2010, we introduced you to the Office Web Apps: browser-based versions of Word, PowerPoint, Excel and OneNote. We made these products available as a set of SharePoint applications. Customers deploying Office Web Apps on their own networks did so by installing Office Web Apps on SharePoint servers.

At the time, tight SharePoint integration seemed like the best approach. Clearly SharePoint was, and remains, a pillar of the Office Web Apps story. And SharePoint has a well-defined model for integrating applications like the Office Web Apps. But as we began planning the next version of Office Web Apps, it became clear that it would be hard to achieve some of our core goals with an architecture so tightly coupled to SharePoint.

We wanted to simplify setup and capacity planning, and enable federation across multiple farms. We also wanted to accommodate requests for integration from new partners such as Lync. Finally, we heard from many customers, both on Office 365 and on-premises, that they wanted the same improvements that our SkyDrive users enjoyed on a regular basis.

To achieve these goals, we went back to the beginning and rethought how the Office Web Apps would integrate with other products now and in the future. We created a new model that separated Office Web Apps from any specific partner technology. Ultimately our model placed a relatively light coding burden on file hosts such as SharePoint while allowing us to run Office Web Apps on entirely separate servers.

This new standalone server product is Office Web Apps Server.

We know, that at first, the idea of an additional type of server seems like it adds complexity and the burden on the administrator. But you'll see that by standing alone we get...

1. Simpler setup

2. Upgrade and maintenance entirely separate from SharePoint

3. Multiple SharePoint farms integrating with a single Office Web Apps Server farm

4. Other products such as Exchange, Lync and third-parties integrating with Office Web Apps

5. Delivery of new features and improvements to our web-based and on-premises customers at essentially the same time

When we compare previous Office Web Apps deployments on SharePoint 2010 to new deployments using Office Web Apps Server the advantage really begins to show.

With the previous version of Office, a typical Office Web Apps deployment looked something like this...

Note that the previous version of Office Web Apps needed to be installed on each farm and on every machine in each farm. Additionally, scaling of Office Web Apps was tied to overall SharePoint scaling. And updating Office Web Apps required updating code on every machine in all your SharePoint farms.

With Office Web Apps Server, we expect a deployment to look more like this...

As you can see, a single Office Web Apps Server farm can serve multiple SharePoint 2013 farms plus Lync 2013 and Exchange 2013 (Outlook Web Access). Additionally, you can use your Office Web Apps farm to view any URL or UNC accessible Word, Excel, and PowerPoint file.

A Brief Overview of the New Integration Model

The following describes how Office Web Apps integrates with a file host like SharePoint at a high level. The information here will help you understand the network and security requirements described later.

First, a few definitions:

Office Web Apps Server – Provides Office Web Apps functionality to hosts and is the thing that this whole article is about.
Host – Uses the services that are provided by Office Web Apps Server to display files in a web browser. For example, SharePoint Server 2013, Lync Server 2013, and Exchange Server 2013 are all hosts.
Client – This is a browser or other similar software.

A key part of the new integration model is a new public API that Office Web Apps uses to communicate with Hosts. This API is called WOPI (Web application Open Platform Interface). Office Web Apps Server fetches and manipulates files using the WOPI API. We often refer to Office Web Apps Server as a WOPI App. Hosts must understand WOPI requests from WOPI apps.

WOPI is a RESTful API that uses HTTP/HTTPS. This means that, among other things, all traffic between Hosts and Office Web Apps Server travels through standard HTTP/HTTPS ports. It also means that, as much as possible, Office Web Apps Server is stateless. This makes it more resilient to an assortment of failures ranging from network outages to complete hardware failure.

To understand how WOPI works, let's walk through a simple scenario where a user, Sally, views a file called test.docx hosted on SharePoint. Here’s how that works...

1. Sally navigates to a document library where test.docx is stored.

2. Sally clicks the file name in the document library.

3. SharePoint navigates the browser to a special SharePoint page that knows how to initiate requests to Office Web Apps Server (and other WOPI Apps). We'll call that SharePoint page WOPIFrame.aspx.

4. WOPIFrame.aspx contains an iframe (https://dev.w3.org/html5/spec/the-iframe-element.html) which it navigates to a page on the Office Web Apps Server. We'll call that page WordViewer.aspx. The HTTP request to WordViewer.aspx includes some important information:

- The URL that Office Web Apps Server will use to get test.docx. We call this the WOPI Endpoint.
- The name of the file. We actually combine the WOPI Endpoint and the file name in a single parameter that we call the WOPI Source.
- A string that Office Web Apps can pass to the WOPI Endpoint that represents Sally's credentials. We call this the Access Token.
  For security purposes, the Access Token only gives Sally access to one specific file. If a bad person managed to steal the Access Token, it would only allow them to impersonate Sally in the context of that single file. Of course, that is still bad so it's important to protect that Access Token with SSL.

5. Office Web Apps Server uses the WOPI Source and the Access Token to get test.docx from SharePoint.

6. WordViewer.aspx displays test.docx in the iframe on WOPIFrame.aspx.

Here is a picture that shows the data flow between the browser, SharePoint, and Office Web Apps Server...

Setting Up Office Web Apps Server Farm

A server farm in this case can be anything from one virtual machine running on a shared server to a farm of dozens of datacenter-class servers. The basic setup and maintenance is the same in all cases. The precise prerequisites and steps for creating a farm are, of course, included with the product. I won't reproduce that documentation here. What I will do is describe what's involved at a reasonable level of detail.

Hardware

First, you'll need some machines. Let’s assume you’re setting up a farm to serve the needs of 80,000 users of multiple SharePoint farms. We think you'll probably need 4 servers with...

Windows Server 2008 R2 or Windows Server 2012 with all prerequisites
8 cores
8 GB of RAM
a decent-sized hard drive (60 GB or more)

You'll also need a load balancer. We have a 10 machine farm set up at Microsoft that shares an F5 BIG-IP hardware load balancer with a number of other server products. That arrangement works extremely well but any decent load balancing solution will do the trick. The only strong recommendation we make is that your load balancing solution support affinity. For performance, it is very valuable if the same server handles all requests for a specific session.

Network

I'm going to assume that you'll want users to have access to Office Web Apps from both your internal network and the internet. If so, you'll need to set up both internal and external DNS for your farm. Or, you could opt to just setup external DNS and use internal DNS rules to keep internal requests on your private network. That's what I would do.
It’s your network so set it up how you see fit. All we require is...

Clients (usually web browsers) need to be able to make requests to the farm. These are normal HTTP/HTTPS requests on port 80 or 443 respectively.
Machines in the Office Web Apps farm initiate requests to a service on the file host (e.g., SharePoint). These requests are also HTTP/HTTPS on port 80 or 443. This is how the Office Web Apps machines operate on the files they are rendering or editing.
File hosts occasionally need to request information directly from the Office Web Apps Server farm through the load balancer. These requests are also HTTP/HTTPS requests on port 80 or 443.
All the machines in the Office Web Apps Server farm need to communicate with each other via port 809. Ideally, these machines are on a private subnet such that no other machines can join the farm or listen in on traffic. If not, there are some features built in to Office Web Apps Server to help secure a farm on a more open network, I'm not going to discuss those features here. For more information, see Security planning for Office Web Apps Server Preview.

Making sure these network routes are set up correctly is critical. The Office Web Apps are relatively simple but they only work when the channels of communication are open.

Security

As I noted in the previous section, the initial request to render or edit a file includes user credentials in the form of an Access Token. In turn, this Access Token is included in all requests from Office Web Apps to Hosts. All this traffic must be protected with SSL unless you are on a private network and you trust everyone who has access to that network. And then you should still use SSL. Really.
Setting up SSL requires creating certificates and putting them on each Office Web Apps Server machine or on the load balancer. If you choose to terminate SSL at the load balancer, there are specific settings in Office Web Apps Server you can use. I'll cover that in a moment.

Office Web Apps Server Configuration

Now you have all your hardware and network infrastructure in place, it's time to actually create your Office Web Apps Server farm. First, install Office Web Apps Server and its language packs on all the machines. Don't try to install any other software on the machines. No SharePoint. No Exchange. Nothing else. If you want to share hardware, use virtual machines.

Once that's done, run the following Windows PowerShell on the first machine in your farm (we'll call it Server1). This Windows PowerShell assumes that...

You are only setting up external DNS at the URL https://officewebapps.contoso.com. This could be any URL you care to set up.
You are setting up an Office Web Apps Server farm to support editing as well as viewing.
Only do this if your organization has the appropriate licenses for editing. I won't be covering licensing details here except to say that Office Web Apps viewing is free but editing functionality is not. For more information, see Plan Office Web Apps Preview (Used with SharePoint 2013 Preview Products).
You are terminating SSL at the load balancer.

Here's the Windows PowerShell:

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

You now have a single-machine Office Web Apps Server farm.

With that done, move on to Server2. On that server run the following...

New-OfficeWebAppsMachine -MachineToJoin "Server1"

Now you have a two-machine farm. Repeat the previous step on Server3 and Server4.

Connecting to SharePoint

At this point your Office Web Apps Farm is good to go. But it's not connected to any Hosts yet. To connect a SharePoint farm to this Office Web Apps Server farm, open up a Windows PowerShell command prompt on any server in the SharePoint farm and run the following...

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

You will also need to run the following command to tell the SharePoint farm that you want to use the Office Web Apps Server farm's external URL and that it uses HTTPS.

Set-SPWopiZone -Zone "external-https"

Now you really are done. Navigate to a document library in the SharePoint farm and create, view, and edit Office files to your heart's content. No further configuration is required.

Finally, if you want to disconnect the Office Web Apps Server Farm from SharePoint, run the following...

Remove-SPWopiBinding -All

If you go to a document library in the SharePoint farm now, there will be no trace of the Office Web Apps.

You can connect as many SharePoint farms as you want to a single Office Web Apps farm. And the same is true when connecting Exchange and Lync to an Office Web Apps farm. For more information, see Exchange Server 2013: Office Web Apps Server Integration and Deploying Office Web Apps Server and Lync Server 2013.

Getting Updates to Office Web Apps Server

From the beginning we've been committed to frequent updates to the Office Web Apps. However, we only delivered our updates to on-premises customers via Service Packs. After we release Office Web Apps Server 2013 we plan on making updates available much more frequently. We believe this will be manageable for admins because updating Office Web Apps Server is very easy.

To update machines in an Office Web Apps Server farm you will need to remove machines from the load balancer and the farm. However, that process can be managed such that there is virtually no impact on users.
Essentially, if you have a 4 machine farm, you take out two machines and upgrade them. Then you create a new farm with those 2 machines and point the load balancer at those 2 machines instead of the 2 from the original farm. Now upgrade the remaining two machines and join them to the new farm and point the load balancer at these machines as well.

When machines are taken out of the farm some users may encounter hiccups but the Office Web Apps will recover. This works for all cases except the single machine case (for obvious reasons).

Learn more about Office Web Apps Server

You can find additional resources for Office Web Apps Server here:
• Office Web Apps Preview library on TechNet
• Exchange Server 2013: Office Web Apps Server Integration
• Deploying Office Web Apps Server and Lync Server 2013
• Office Web Apps Setup and Deployment Forum

Nick Simons
Senior Program Manager - Office Web Apps

Comments

Anonymous
January 01, 2003
Hi Catherine, I’m revising the oficial documentation of Microsoft about Office Web Apps, but I’m not able to find a flow between Sharepoint and Office Web Apps, I have found this flow about Sharepoint that helped me a lot blogs.msdn.com/.../sharepoint-2013-ports-proxies-and-protocols-an-overview-of-farm-communications.aspx but now I’m trying to find a flow like that but between this two farms. Currently there is any document like that? Thanks
Anonymous
January 01, 2003
There is some documentation here: msdn.microsoft.com/.../hh622722(v=office.12).aspx. More developer content is in the works.
Anonymous
January 01, 2003
Also have a look at the blog series by Wictor Wilen on building a WOPI client: www.wictorwilen.se/.../WOPI
Anonymous
January 01, 2003
Please post to the TechNet forums if you need help. social.technet.microsoft.com/.../threads
Anonymous
January 01, 2003
Nice write up on Office Web Apps. I have configured everything correctly and enabled editing features, but when I open the documents it says that i dont have license. We are a Microsoft partner and have downloaded the software using partner ID. Please through some light what wrong I might be doing.
Anonymous
January 01, 2003
Catherine - thank you so much - one of the best articles I've ever read on TechNet!!!
Anonymous
January 03, 2013
Best write up I have found on Office Web Apps Server. I got more understanding in the time it took to read this than trying to figure out the technet stuff. Thank you.
Anonymous
January 07, 2013
The comment has been removed
Anonymous
January 17, 2013
Catherine, thank you for the great article! I'm thinking about integrating Office Web Apps with our Content Management system, e.g. creating WOPI Server that we will use instead of Sharepoint to show list of documents/retrieve/save etc. It looks like If I implement all REST interfaces on this custom WOPI server & register it properly with Web Apps Server that should work. Am I missing anything here?
Anonymous
February 07, 2013
The comment has been removed
Anonymous
February 18, 2013
Hi, I have my office web application installed and I realized Network Service was defaulted for all the Office Web App Application Pool Identity. Do you know if there is a way if the identity can be change (like the SharePoint Web App identity)? Thanks in advanced. Regards, Angeline
Anonymous
August 30, 2013
The comment has been removed
Anonymous
December 02, 2013
sorry for this question,,, is it mean that in order to use Office Web Apps I should have a Sharepoint Server?
Anonymous
December 03, 2013
Hi Jeffrey, you can try out the Office Web Apps themselves by just getting a Microsoft ID and signing up for SkyDrive. The process is detailed at office.microsoft.com/.../web-apps. You won't need to install any servers because that's all handled in the cloud by SkyDrive. The Office Web Apps are also available to Office 365 subscribers. Office Web Apps Server, which this blog post is about, provides Office Web Apps in an on-premises setting (as opposed to cloud-based) and is typically used with on-premises hosts such as SharePoint, Exchange Server, or Lync Server to provide the features of Office Web Apps. Hope this helps. -Chris
Anonymous
December 16, 2013
Pingback from Microsoft Office Web Apps Server 2013 ????????????.. | MCSONG??? ????????????
Anonymous
January 24, 2014
it says office web apps can display files from a file share who would handle authentication than the other part is... since the filepath are "random" (the article doesn't say random, just unique) who sets those paths? office web apps... or sharepoint/exchange
Anonymous
February 20, 2014
Can we build our own WOPI client without SharePoint 2013 and Office Web Apps (OWA) server? Please suggest what options we have. - Taps
Anonymous
May 13, 2014
I have a Microsoft Office Web Apps set up. For the OWA host, I am using my own WOPI server and have implemented the WOPI protocol.

The way OWA works is it calls OWA host to get the File Info. It caches this info locally only for 5 mis.
After every 5 mins it calls OWA host to get the file info.

Is there any way I can increase this 5-min time window in OWA?
Anonymous
September 12, 2014
The comment has been removed
Anonymous
March 11, 2015
This article demonstrates how to use Microsoft Message Analyzer to capture MS-WOPI protocol traffic and

Udostępnij za pośrednictwem