Note: This is not a “how to” article on what steps you need to take to configure OWA in 2013, it is a listing of the problems I ran into while configuring mine, and what solutions I found. If you’re installing OWA, you’ll definitely want to read this, as it will probably help you, but it’s not a step by step how to guide on how to do it…
I ran into a few problems while configuring OWA for use in a new SharePoint 2013 farm today.
The DNS name you pick matters
I wasn’t sure of the architecture of this whole thing and one question was bugging me…
Does the user need direct access to the OWA server? Or do the SharePoint Web Front ends act as a proxy for it?
I setup a config and ran Fiddler on the client with the browser to see what server(s) it connected to – sure enough it connects to the OWA server(s) directly.
This has some implications for us if we’re making this available on the internet…
Think of this for a moment, in 2010, OWA was a “Service Application” – if your user had access to the WFE, SharePoint took care of the rest, even if OWA was on a different box (or boxes) It was Magic.
With OWA2013, you’ll need an external IP address, an SSL certificate your browsers will see as valid, and NLB or an external load balancer if you’re using more than one OWA box.
It also means you’ll want to build your OWA farm with a legit DNS name and not the machine name.
Uninstalling an old config:
First, I had messed around with using HTTP before my certificates were ready.
No Problem, I thought, I’ll just remove that Initial Farm config I had built with New-OfficeWebAppsFarm command, surely there is a Remove-OfficeWebAppsFarm command right?
The above shows me 3 commands for creating, but only 2 for removing!
Yep, I can use New-OfficeWebAppsFarm, but there is no Remove-OfficeWebAppsFarm!
It turned out to be easy enough, on my one box farm in Dev, I just needed to use
Note that if you have more than one machine in the OWA farm, you’d need to run the above command on each box, saving the first one (master) until last.
With that cleared up and was ready to install with my cert.
The next thing I ran into – the new-OfficeWebAppsFarm command wants the “friendly name” of the cert, not the domain name – it was easy enough to figure that out, but it threw me for a loop.
Time for my first OWA farm install!
Here I ran the command below on the first node of OWA:
New-OfficeWebAppsFarm -internalURl https://myurl.com -editingenabled -certificate "Mycertsfriendlyname"
Everything seemed pretty great…
Confirming it works
Except when you’re done, you’re supposed to check that it works by visiting this URL:
This is supposed to display a nice little snippit of XML – one that looks familiar if you’ve ever pulled up a web service in a browser.
Instead I got an error.
HTTP Error 500.21 – Internal Server Error
Handler “DiscoveryService” has a bad module “ManagedPipeLineHandler” in its module list
It looked like asp.net wasn’t registered.
I searched the error, and found this article: http://consulting.risualblogs.com/blog/2013/04/03/office-webapps-deployment-error/
bottom line, I ran this command:
and that re-bound ASP.net to IIS.
So far so good, the page was coming up now on the first node.
Adding a second OWA server
Now time for the second node.
To add a 2nd-99th OWA node, the command is a little different:
New-OfficeWebAppsMachine -MachineToJoin myowaurl.com
Here, I ran into one more issue – kinda simple but an “of course!” kinda moment.
When I ran the command the first time, it couldn’t find the OWA server to connect to.
Care to guess why?
Because these are all behind a load balancer, I had host entries on both OWA servers that pointed back to themselves. This is common so that you can log on to one server and confirm THAT server is working. Well, I got ahead of myself here, and the new-officewebappsmachine command was being redirected back to itself.
Easy fix, I pointed the host entry to the other server long enough to do the command, then set it back so I could test it locally. I’m glad I did that, because the second node had the same problem as the first, something I might not have found without the host entry.
I ran that aspnet_regiis.exe -ir command a second time, and did an IIS reset and things were looking good on my second OWA node.
Oh and one more goofy thing I noticed…
Configuring SP to talk to OWA
No OWA build is complete until it’s registered with SharePoint 2013 so SP knows where to send the traffic.
To do this, on the SharePoint server we run this command:
New-SPWOPIBinding -Servername urltoyourserver.com
Now what’s odd here, is it rejected my server name multiple times.
It did not like:
- “Myurl.com” (I don’t know if I actually tried this one)
What worked was just using myurl.com – no quotes, no https://
As soon as I finished the stuff above, I thought I was ‘done’ after all, the commands worked so OWA must work now right?
Don’t test OWA with the System account
I ran into a few more issues when I tried to test this. Remember that bit above, where I said on each OWA server, I had put in a host entry so that I could log on to the server, and test just that server? Well, I was logging on to the server as the SharePoint “System Account” – and guess what? That doesn’t work. Now you might expect a nice error that says something like “You can’t use this as the system account” – Nope. Just a nice correlation ID to go hunt down. And in the ULS logs what do we see? Well, nothing that indicates that I can’t use the admin – I dug it up the solution by searching the web.
So I tested with a different account which solved one problem, but it still wasn’t working…
Make sure the individual WOPI bindings match the overall zone
You configure the connection between SharePoint and OWA on the SP box by using commands like this:
New-SPWOPIBinding –ServerName dnsnameof.yourserver.com
write-host "Setting Zone"
Set-SPWOPIZone -zone "External-HTTPS"
Now, you might ask, how did I choose the zone? There are 4 choices, and somewhere I read that if this site is going to be available internally and externally, use “External-HTTPS”
Not so fast..
As it turns out there’s another command that’s relevant here:
This will list out a bunch of individual bindings for each file type.
Guess what those bindings said? Internal-HTTPS.
Another search on the internet and yeah, these should have been the same as the overall zone set by the Set-SPWOPIZONE command I used above.
Wanting a “quick win” it seemed faster to change the overall zone by reissuing the set-SPWOPIZone command than to figure out how to update 185 bindings. I ran this:
Set-SPWOPIZONE -zone "internal-https"
And guess what??
OWA works now.
Ok, so that sums up my first few installs of Office Web Apps 2013 and tying them to SharePoint 2013 in a multi-server OWA farm.
That’s a lot of material, lets see if i can sum this up with a nice bulleted list:
- Use a real DNS name for your OWA box, not the machine name.
- It’s possible to remove an OWA farm config, even though there is not a “remove-OfficeWebAppsFarm.
- Don’t put host entries on your OWA boxes until after you’re done with the install.
- When configuring the WOPI bindings on the SharePoint farm, don’t use https:// in the DNS name.
- make sure the zone listed for each binding matches the zone set for the the overall connection.
- When you test OWA, don’t use the Farm account.