Office Web Apps 2013 – Install and Configuration Gotchas!

​Office Web Applications Server offers great enhancements to your SharePoint environment. However, there are some common gotchas that tend to pop up during the installation and configuration of the service. In this article, we will take a look at some of the most common items that I have seen in the past year.

External URL Needs to be published

Now this may seem like common sense to many of you, but you would be surprised at how often I see this get missed. For public facing sites or for any site using Office Web Apps, you need to ensure that the URL for Office Web Apps can be reached by the end users. This differs from the way it worked in SharePoint 2010 with office web apps mainly because Office Web Apps is now its own server. Here is the communication goes: 

  1. User browses the SharePoint site
  2. User Clicks on a document on the site
  3. SharePoint returns a page to the user with a WOPIFrame in it. (You can think of this like an iFrame).
  4. When the page loads for the user, the WOPIFrame connects to the Office Web Apps server to render the document.

This means that the page the user is seeing has content coming from two sources, SharePoint and Office Web Apps. For further information on the actual communication flow between Office Web Apps, SharePoint 2013 and the end user you can refer to the following Microsoft document: Office Web Apps Overview This can mean you need to make special considerations depending on how many layers of security you have on your network or where users are actually accessing the site from (Internal, External, etc..) If the Office Web Applications URL is not exposed/published in a way that allows your users to connect to it, they will not be able to render documents in the browser. 

Office Web Apps and SharePoint Servers must be able to communicate with each other

Another one that may seem like common sense but can be confusing or complicated depending on the configuration of your network. Previously I gave a rough overview of the communication between the end user and the SharePoint and Office Web Apps servers. This was a very simplified view, and there are some additional communications that take place. When the user clicks the document (Step 2 in the previous scenario) there is additional communication that happens between the Office Web Apps server and SharePoint. Office web apps server connects to SharePoint to get the actual document that is being rendered. It may seem like a small thing, but if the Office Web Apps server cannot connect to SharePoint using the URL that the user is connected to, then the document will not render. So let’s expand on our earlier scenario:

  1. User Browses to SharePoint site
  2. User Clicks on a document
  3. SharePoint sends a request to the office web apps server to render the document
  4. Office Web Apps server connects to SharePoint to retrieve the document
  5. SharePoint returns a page to the user with the WOPIFrame in it
  6. The page loads and the WOPIFrame connects to the office web apps server and renders the document.

It’s step 4 that can cause the whole thing to fail if the Office Web Apps server cannot find the SharePoint site. This means that the Office Web Apps server needs to either be able to find the SharePoint site URL either through DNS or though hosts file entries. This is especially important if you have multiple URLs, AAMs or multiple web applications.

Image of the blog title "Install and Configuration Gotchas"

Office Web Apps SSL Cert must be named

This is one I have seen trip up many administrators. The SSL Certificate issues to the Office Web Apps server must have a name associated with it. It is actually very easy to create an SSL cert and not associate a name with it. The URL and Subject of the Certificate is not the same as the name of the certificate. The reason for this requirement is that when you configure the Office Web Apps farm, you must specify the name of the certificate in your PowerShell.

For example here is our PowerShell to create the office web apps farm:

New-OfficeWebAppsFarm –InternalURL https://office.company.local –ExternalURL https://office.company.com –EditingEnabled -CertificateName “OfficeSSLCert”

In the above line the -CertificateName parameter will fail if the certificate does not actually have a name assigned to it.

SPWOPIZone and SPWPOPIBinding Settings 

The SPWOPIZone tells SharePoint weather it should use the internal or external URL for Office Web Apps Server (as seen in the previous scenario PowerShell command). It also sets which protocol (http or https) is to be used. After installing and configuring the SharePoint integration with Office Web Apps server it is usually good to run the Get-SPWOPIZone command to see what the current setting is. You can then run the Get-SPWOPIBinding command and see what the settings are for each document type. In most cases they should all be set the same. If you see any that look odd, you can use the Set-SPWOPIZone command to update the settings for your office documents. If you SPWOPIZone and SPWOPIBinding do not match you may find that documents do not render in the browser. The best solution is to use either the Set-SPWOPIBinding or Set-SPWOPIZone command to ensure that the zone and bindings match in your SharePoint farm. For further information, you can review the following links:

You should ensure that your zone and binding match the setting you want for your end users in terms of Internal/External and HTTP/HTTPS. 

Excel Services and Office Web Apps

When using both Excel Services and Office Web Applications together in a farm, you need to understand the differences between them. Office Web Applications does not support all the same external data source connections that Excel Services does. In cases where you have Excel content that utilizes data connections and has requirements like data refresh, etc… you will want to ensure that users are viewing the excel files using excel services instead of Office Web Applications. To do this you must use the New-SPWOPISuppressionSetting command to change how SharePoint handles excel files. The command will look like the below:

New-SPWOPISuppressionSetting -extension xlsx -action view

After you have changed the setting via the above command, an IIS Reset is recommended on the SharePoint servers. The above setting tells SharePoint that when users are viewing excel documents in the browser to use excel services to render them instead of Office Web Apps. Since we have specified the action as view, this means that office web apps can still be used to edit the excel file in the browser allowing you to still take advantage of Office Web Apps for your excel content.

Testing with the Farm Account

The Microsoft documentation for Office Web Applications mentions this but I still see it happen quite often. When you are testing the Office Web Apps integration with SharePoint, do not use the SharePoint farm Account or any of the Service Accounts that are used in your SharePoint farm. You will not be able to open documents and you will get errors that will not tell you what the actual issue is. Simply log into the SharePoint site as a standard user account and test your documents open correctly that way. This also holds true for creating new documents in the browser using office web apps. If you create a new document as the Farm account, you will find that the document does not open for you regardless of who you log in as. 

Summary

Hopefully this will help you avoid some common pitfalls in your Office Web Application Server installations. If you need help with installation and configuration, contact the Kiefer team. Our number is (916) 932-7220. We can also be reached via e-Mail at info@kieferconsulting.com

Archives

Follow Us

Leave a Comment

Your email address will not be published. Required fields are marked *