Installing Office Online Server and Hooking it up with SharePoint 2013 (or 16)

On a test machine up in Azure I recently installed Office Online Server (OOS) and successfully hooked it up with a SharePoint 2016 server, also in Azure. As far as I can remember the process went fairly smoothly but I do faintly remember that getting the Windows 2012 R2 server that hosts OOS up and running was a bit tricky with some missing dependencies and the like. Of course I was in a rush and didn’t take any notes at the time.

Anyway, I now have reason to install OOS in an on-prem test environment and hook it up to SharePoint 2013. The Microsoft blurb says that this is a supported deployment scenario but I could find nothing more on how to actually do it as everything was aimed at SP2016.

So this time around, I thought I’d actually document the process and follow the SP2016 guidance as best as I could to get this baby up and running for SP2013.

What is Office Online Server?

For those of you who don’t know what OOS is then why are you reading this article? Just kidding, OOS is the new shiny replacement for Office Web Apps (OWA) which is that really cool thing you see in SharePoint Online/O365 whereby when you click on an Office format document (or web page, or if you’ve set it up a PDF) it opens up a sort of in-page dialog viewer thingy called a Callout.

Or at least that’s what happens with the so called “Classic Experience” of a document library. They seem to have done away with this in the “New Experience” in O365 – why?

I digress, this post is about getting OOS up and running with SP2013 where, thankfully, we don’t have to deal with the inadequacies of the new experience (do I sound cynical)!

What use is OOS?

Apart from being just cool, OOS is actually useful. It allows users to peer into a document and check that it’s the right one before loading it up into a client application for editing. This is a really neat feature, especially when reviewing search results.

It’s also useful for readers, as by default, when a compatible format document is clicked in the UI it will open in the user’s web browser. So why is that useful? Well, not only does the content generally load quicker but it removes the reliance on having an appropriate client application installed on the device used to access the document.

When SharePoint was conceived, user devices were exclusively workstations and laptops both of which, it was reasonable to assume, would have a suitable suite of client applications (usually MS Office) all ready to receive and interpret the bits and bytes pulled down from SharePoint. Of course today, everyone loves their smart phones and tablets and it is no longer a given that these devices will be able to receive and render an Office format document, However, they can all handle web pages – hence there is a justified need for OOS.

When hooked up to SharePoint 2016, OOS also has another potential use which is to provide the new perma-link capability. That’s right to use perma-links in SP2016 you need OOS. Now, what exactly perma-links are and how to use them, I will leave for another day, as they don’t apply to SP2013 in any case.

Key Steps

The principle steps to getting OOS up and running are conceptually simple:

Download the OOS software.
Prepare a Windows 2012 R2 machine to run OOS
Install OSS
Configure OOS
Hook it up to a SP2013 farm.

Looking at each in turn.

Downloading OOS

Getting the software is fairly easy, go to your Volume Licensing Service Centre and download the ISO image. Here, I’m downloading it from MSDN.

Now, OOS is a fairly new product and it seems that Microsoft are updating it quite frequently so make sure you download the latest copy. Originally I downloaded the May 2016 release but later noticed that this had been superseded, with a November 2016 release (at the time of writing).

Server Preparation

OOS is a server based product and for now the only operating system that appears to be supported is Windows 2012 Server R2. I’m sure that in due course there will be a release for Windows 2016 Server but for now your stuck with hosting it on the older platform.

Microsoft provide some fairly detailed installation guidance at:

https://technet.microsoft.com/en-us/library/jj219455(v=office.16).aspx

There seems little point duplicating what they have already provide but there are a few things to note.

You can’t co-host OOS with something else like AD, SharePoint or Exchange – it needs its own server (physical or virtual).
The server must be in a domain and have trusted access to the other server products that are going to tap in to the service.
The reason Microsoft stand OOS up as a separate server is that it can be used by Exchange/Outlook and Skype for Business (SfB) as well as SharePoint.
If you are going to hook it up to SharePoint you must be using Claims Based Authentication (which is the default in Sp2013/16). If your SharePoint deployment used Forms Based Authentication or classic pre-SP2013 mode authentication, then you’re out of luck!

Once you’ve prepared a suitable server and added it to your domain then installation should be a breeze. But its not, as there are a whole bunch of pre-requisites that need to be applied and easiest way to apply most of them is simply to run the PowerShell script that is provide in the above linked TechNet Article.

After installing the pre-requisites I ran the installer and found I still had a couple of things missing. A bit of research on the web suggested I need to install a couple of KB updates but they proved exceeding difficult to actually apply, stating that the download didn’t apply to my OS (when they clearly stated that they were for Windows Server 2012 R2 -grrr).

So, next came a round of Windows Updates, and more Update and yet more Updates until my server was patched to the very latest and greatest. I suppose I should do that anyway but my logic was that this my cure the installers failure – it didn’t.

After much trial and error of installing everything that the world suggested, that would actually be accepted by my machine, I was still getting the following blockage:

Now I tracked down the above referenced KB but this one steadfastly refused to install on my OS!

It was then that I realised I was installing was May 2016 release and not the latest November 2016 release and the TechNet article is dated November 2016 so that strongly suggested that I should download the newest version and try that. So I did that but to no avail – same issues.

Back to re-reading the TechNet article and it does explicitly state that I need to install the following as well as the PowerShell deposited pre-requisites:

Now, I was fairly confident that the .Net Framework 4.5.2 and the Identity Model Extention were already there but I downloaded and installed them anyway just in case.

As for the C++ Redistributables. The download links actually included multiple files depending on chipset x86, x64 and in the case of the VS2013 Arm as well. Of course you only need to download the x64 versions. I installed the 2013 redistributables followed by the 2015 version.

With everything installed as per the TechNet article I ran the installer again. And guess what? This time I got past the checker and actually made it to the installer.

Now, I really think that Microsoft could do a much better job of this but I got there (or to first base at least) in the end and moral of the story is – RTFM!

Install Office Online Server

Now assuming you get this far the installer will present you with a standard looking license dialog.

Check the box and click Continue.

Next you need specify the install location. For a production deployment you would probably want this on a separate disk partition from the OS but as this is for a dev environment I just accepted the default here.

Notice how the default path is “Microsoft Office Web Apps” come on Microsoft, this sort of stuff just causes confusion! Click Install Now.

Next, the installer does its business.

As installers go this one doesn’t take too long, mine was done in 5 minutes and at the end you get left at the installer complete page:

Next, the TechNet article invites you to install the language packs for OOS. Now I couldn’t find any clear guidance on what this is for. Language packs are usually to provide a UI in a target language and you usually select the languages you need. They basically deploy resource files. But OOS doesn’t really have a UI does it? It’s a backend service that just serves up web consumable versions of documents.

Mmm, there is just a glimmer of a possibility that Microsoft offer integrated machine translation via the Bing Translate API. Now how cool would that be, integrated machine translation.

It this point I am in danger of being distracted like a child at Christmas looking at the next present to unwrap before the current one is even out of the box. So, I’m going to park this one for now and not install the language pack and then report back later when I’ve had a chance to take a look.

Configuring Office Online Server

Installing OOS was infinitely simpler than getting the installer to actually run but we’re not done yet. We now need to configure OOS. The TechNet article calls this step Deploying the OOS Server Farm and offers up 3 deployment scenarios:

Single Server on HTTP
Single Server on HTTPS
Load Balanced Multi-Server on HTTPS

Now for production environments it is strongly recommended to use a deployment scenario that supports HTTPS but I’m actually building a test environment and my SP2013 farm uses plain old http so I’m going to take the easy route today and run through the first option. If I get enough positive feedback I’ll blog about the other options at a future date.

So, let me be clear, today we are going to take (what should be) the easy option of deploying OOS to use HTTP.

The TechNet article states that this is achieved in 2 simple steps:

Create the OOS farm (using PowerShell)
Verify that the farm was successfully created.

After that we need to configure consumer applications (which Microsoft call hosts and which I think is a slightly confusing term as they don’t host anything), in my case SharePoint 2013 – but we’ll come to that later.

Create the OSS Farm

Well this is deceptively easy and involves running one line of PowerShell. The TechNet article warns that before we can run the PowerShell to create the farm we may need to first install the commandlet by importing the OfficeWebApp module. However, I found that the installer had taken care of that for me.

In a single server HTTP deployment scenario it seems we only have 3 parameters to worry about when executing the NewOfficeWebAppsFarm commandlet:

–InternalURL: This is the name of the OOS server i.e. http://{yourservername}.
–AllowHttp: Tell the farm to allow HTTP traffic.
–EditingEnabled: Tells the farm to allow in-browser editing for SharePoint users.

So the PowerShell command which I ended up running, together with the resulting output which was coughed up 2 minutes later, is as shown below:

This is all very simple it seems but I really wish that Microsoft would provide a proper UI for their sever apps. I can’t help but feel I might be missing other configuration options and trawling through PowerShell parameter descriptions is not my idea of fun.

Verifying the farm

So far, so good. It is prudent to follow Microsoft’s guidance and verify that the farm was successfully created. You do this by simple accessing the {severname}/hosting/discovery URL in the browser on the server and, if all is well, the resulting output should be like that shown below (although there is much more XML not shown in the screenshot).

The redacted text will be your server name.

Hooking it up to SharePoint 2013

So far we have managed to get OOS up and running. The next step is to configure the consumer applications (hosts) to use the service.

Now, I could find no guidance on how to do this for SP2013 (hence the main point of this post), which leaves me with 3 options:

Just guess!
Use guidance on configuring SP2013 to use OWA
Use guidance on configuring SP2016 to use OOS

I went for the last option and the afore mentioned TechNet article provides a link to another article which I used as my guide.

Configure Office Online Server for SharePoint Server 2016

You should read this article in detail as it makes clear (amongst other gotchas) that you need to be running Claims Based Authentication and that testing OOS using the SharePoint system account won’t work!

This article branches on whether we are setting up OOS for a test environment over HTTP or a production environment over HTTPS.

In this article, I’m just sticking with the test environment/HTTP scenario as mentioned above.

It seems we have 5 steps to work through:

Create a WOPI binding between SharePoint and the OOS
View, and if need be, update the WOPI zone
Configure SharePoint to allow oAuth over HTTP
Add legacy support for Excel Services
Check that it all works

WOPI stands for Web Application Open Platform Interface Protocol and is simply the the protocol used to access documents via OOS (and OWA)

Working through each in turn.

Create a WOPI binding between SharePoint and OOS

Rather confusingly, the TechNet article refers to this step as creating a binding between SharePoint 2016 and Office Web Apps. Come on chaps, we’re talking about OOS here and if you’re going to change the product name on us then please do so everywhere.

It’s as simple as running a PowerShell command from SharePoint to name the OOS server and to add a flag to allow HTTP traffic:

New-SPWOPIBinding -ServerName -AllowHTTP

There are a few gotchas here:

Make sure you are on the SharePoint Server and not the OOS – doh!
Make sure you run the SharePoint Management Shell rather than the standard PowerShell console – double doh!
Run the SharePoint Management Shell as an Administrator – triple doh!
Make sure to use the FQDN of the OOS – no doh!

Here’s a sample of my output from the management console.

Note how there is a response for every file types supported by OOS.

Check the WOPI Zone

It seems OOS uses zones to determine the URL and protocol to communicate with SharePoint and we should check that we are using HTTP in the Internal zone. To check this simply run the Get-SPWOPIZone from the SharePoint Management Shell. If all is well you should see output like mine below.

Hang on – not so fast! This is indeed what the TechNet article states; that if we get response “internal-https” then that’s what we are after and move on.

But that don’t seem right to me because here we are wanting to use plain old HTTP surely. And indeed if we just gleefully accept that this is not a typo then your implementation simply won’t work. How can it, we’re telling SharePoint to expect data over HTTPS when we’ve set thing up in OOS to be delivered over HTTP!

“East is East, and West is West, and never the twain shall meet”

This bit is important!

So to fix this we need to set the WOPI zone to the correct protocol (HTTP in this case). To do that run the following PowerShell

Set-SPWOPIZone -zone “internal-http”

If you don’t do this your deployment won’t work and you’ll be scratching your head for hours wondering why – you have been warned!

Allow OAuth over HTTP

You only have to do this when using HTTP of course.

Run the following PowerShell:

$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
$config.Update()

And then run (Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp which will return True if all is well.

Enable the Excel SOAP API

This is needed for Excel Services to work properly so that data is refreshed in Excel Web Parts. You just need to run the following PowerShell where {yourserverURL} is the well, the URL to you server.

$Farm = Get-SPFarm
$Farm.Properties.Add(“WopiLegacySoapSupport”,”{yourserverURL}/x/_vti_bin/ExcelServiceInternal.asmx”)
$Farm.Update()

Verify it works

And that’s it folks. All we need to do now is check that it works as expected. The one gotcha here is that it won’t work with the SharePoint system account so make sure you are testing it with some other account.

It’s a thing of beauty.

In Summary

Setting up OOS for use in SP2013 wasn’t too difficult. Actually the most difficult thing about the whole exercise was loading all the pre-requisites on the OOS server so that the installer would run. The message here is to RTFM (or the TechNet article in this case).

I really feel that Microsoft should provide a UI to this application. Relying on PowerShell is shoddy IMHO. The same might be said for the SharePoint side of the house, they do after all give us a UI in the CA web site for setting up AAM, email servers and just about everything else, so why is OOS integration the poor relation?

Basically, configuring SP2013 to use OOS is the same (identical in fact) to configuring SP2016. There are a few gotchas along the way and one glaringly unobvious typo from Microsoft. Hopefully this article will have helped you to navigate your way to a successful implementation of OOS.