In Exchange 2013, your users can benefit from a rich(er) document viewing experience when integrating with Microsoft’s Office Web Apps 2013 Server. Before, Microsoft relied on a 3rd-party component from Oracle to provide the “Web-Ready Document Viewing” functionality.
One could debate whether the decision to pull his functionality from Exchange is a good idea, but given the recent security-related concerns and the problems it raised, I don’t think it’s such a bad idea after all. Besides that, Microsoft has now full control over the component which is something we can only benefit from as they now control the lifecycle, feature sets, updates etc…
For a fact, Lync 2013 and SharePoint 2013 also leverage (and require) Office Web Apps in order to unlock their full feature set to the client. So if you are going to deploy any of these server applications, you’ll be looking at deploying an Office Web Apps Server (farm) anyway.
Office Web Apps Server
So, as the name might already give away, The Office Web Apps Server can be used to render most of the office file types:
The way the Office Web Apps Server works is relative simple and straightforward. For sake of keeping this document to the point, I’ll oversimplify the explanation. Whenever a user wants to preview a document (attachment), the Exchange server will make a WOPI call to the Office Web Apps Server which will now render the document (instead of the built-in component that used to render the document).
All connections between Exchange and Office Web Apps are secured using SSL so that data never goes clear-text over the wire.
Another good thing about the Office Web Apps Server is that it’s relatively simple. Both from an architecture point-of-view and a deployment/management point-of-view.
Basically, an Office Web Apps Server can either fulfill a front-end role or a back-end role. As part of the back-end role it can e.g. be used only for Word or Excel or PowerPoint. I would go for the default install, which is a “multi-role” server. In this scenario, each Office Web Apps Server performs all tasks. Unless you are running an environment which has very specific needs towards one or the other file type, I would recommend sticking with the default.
From a scalability point-of-view, you can (very) easily add Office Web Apps Servers and load-balance amongst them. Having multiple multi-role servers will also make your solution more resilient as a single server outage will have less impact on a certain workload.
Installing and Configuring Office Web Apps Server
Integrating with Office Web Apps is a two-phase process. First, you’ll need to setup Office Web Apps, secondly you’ll need to create a “trust” between the Application (e.g. Exchange) and Office Web Apps Server. The process of creating this trusts varies from application to application.
Let’s first start by installing and configuring the Office Web Apps Server:
As stated earlier, the installation process is relatively easy. In this article, we will be deploying it on a Windows Server 2012. If required, you can also deploy Office Web Apps on Windows Server 2008 R2. The good thing about deploying on Windows Server 2012 is that you don’t need additional hotfixes or components. Installing the following prerequisites is enough:
Open PowerShell and run the following command:
Next, download and run the Office Web Apps Server setup. The installation itself is very simple:
Accept the license terms and click Continue:
Enter the path where the Office Web Apps Server should be installed and click Install Now:
Wait for the installer to complete:
After the installation click Close.
One thing you will notice after installing Office Web Apps Server is that it doesn’t have a GUI! Yes, you read it correctly, configuration and management is done entirely through PowerShell! Luckily that isn’t much of a problem, as these are the only commands that are available:
To setup a new Office Web Apps farm, run the following command:
New-OfficeWebAppsFarm –InternalUrl <url> –ExternalUrl <url> –CertificateName <name>
The interesting part in this command is the Certificate name. This parameter requires you to enter the friendly name of the certificate. Something that’s – at least to me – very uncommon. To find out what the friendly name is, open the properties of the certificate, click the “Details”-tab and look for the “Friend name”-field:
The value that is registered there should be used as value for the CertificateName parameter:
New-OfficeWebAppsFarm –InternalUrl <url> –ExternalUrl <url> –CertificateName “alert”
Adding a second server to an existing farm is also relatively easy:
New-OfficeWebAppsMachine –MachineToJoin <name>
Before heading over to Exchange, let’s have a look at what URLs you should be using and what the implications are if you want to also be able to use the Attachment previewing functionality from outside your company.
External access for Office Web Apps Server
Obviously, the InternalURL parameter depicts that URL that your internal users are going to use when connecting to Office Web Apps. If you want your external users to be able to use Office Web Apps through OWA as well, you will have to make it externally available.
For example: if you are using split-dns, then your internal and external URLS could be equal:
New-OfficeWebAppsFarm –InternalUrl https://officewebapps.company.com –ExternalUrl https://officewebapps.company.com –CertificateName <certname>
On the other hand, it’s not uncommon to use a different namespace internally then externally:
New-OfficeWebAppsFarm –InternalUrl https://officewebapps.company.com –ExternalUrl https://officewebappsexternal.company.com –CertificateName <certname>
Publishing Office Web Apps Server through TMG 2010
One way of publishing your Office Web Apps Server to the internet is through a TMG.
In a redundant setup, you will be publishing the VIP from the load balancer onto the internet.
To publish Office Web Apps through TMG, you will have to setup a new Firewall Policy. To do this, run the “Web Site Publishing Wizard”:
Enter a name for this policy and click Next:
Click Allow and then click Next:
Depending on how your topology looks like and whether or not you’re using a load balancer, select Publish a single Web site or load balanceror Publish a server farm of loadbalanced Web servers and click Next:
Click Use SSL… and click Next:
Enter the internal host name (or VIP) that points to your Office Web Apps Server/Farm and click Next:
Enter /* as the path, select Forward the original host header instead of the actual one… and click Next:
Enter the external hostname for your Office Web Apps Server and click Next:
Select a Web Listener. If none exist, you’ll have to create one first. If so, make sure that you configure No authentication and use a SSL certificate:
Select No delegation, but client may authenticate directly and click Next:
Accept de default (All Users) and click Next:
Click Finish to create the rule.
There are still some settings that need to be changed before this new rule will work. Right-click the new rule and select Configure HTTP:
Make sure you deselect Verify normalization and Block high bit characters and then click Apply:
Confirm your changes by applying the configuration to the TMG server:
Verifying an Office Web Apps Server installation
To verify if the installation and configuration of your Office Web Apps server was successful, you need to browse to the hosting/discovery virtual directory from your Office Web Apps Server.
The URL from our example would then be: https://officewebapps.domain.com/hosting/discovery/
If everything works as expected you should get a response, in the form of an xml file, that contains the configuration information from the Office Web Apps Server. It should look something like this:
Verify that the URLs that are returned in each zone match with what you’ve configured so far. You might need to click on the plus-sign (+) to view these URLs.
Configuring Exchange Server 2013
To make Exchange 2013 “aware” of the newly installed Office Web Apps Server, you will need to run the following command from the Exchange Management Shell:
Set-OrganizationConfig –WACDiscoveryEndpoint “<office web apps url>/hosting/discovery”
Set-OrganizationConfig –WACDiscoveryEndpoint “https://officewebapps.domain.com/hosting/discovery”
Once completed, open the Application log and look for Event ID’s 140 & 142 (MSExchange OWA):
If these events exists, Discover of the Office Web Apps Server has completed successfully.
Next, you will need to enable the Office Web App rendering for each OWA Virtual Directory. You do this by running the following commands:
Set-OWAVirtualDirectory “<Server>\owa (Default Web Site)” –WacViewingOnPublicComputersEnabled $true
Set-OWAVirtualDirectory “<Server>\owa (Default Web Site)” –WacViewingOnPrivateComputersEnabled $true
Once you’ve done this. Verify if the settings were applied correctly by running the following command:
Get-OwaVirtualDirectory | Format-Table Name,WacViewing*
Verify that both values (WacViewingOnPublicComputersEnabled and WacViewingOnPrivateComputersEnabled) are set to true.
Please note that it might take up to 15 minutes before the changes are applied successfully. If you want to speed up this process, you might want to run iisreset. Don’t forget that this will kill any active connections that might exist!
Once all steps above are completed successfully, you should be able to open OWA and preview a document:
Troubleshooting Office Web Apps Server
As with many things, sometimes things can go wrong. Here are some things that you could do. Remember that these steps can only be a part of the process you need to go through in order to get things sorted out, but they’ll definitely set you on your way:
- Manually check if https://officewebapps.yourdomain.com/hosting/discovery returns an XML response and check if you can navigate to the URLs in this response successfully (both internally and externally).
- Optionally you can use Fiddler2 to check what is going on in the back (see below)
- Take a look at the Office Web Apps Logs (see below)
When using Fiddler, you should see something like this when clikcking the “Preview”-link:
First, and iFrame is loaded (61) after which connection to the Office Web Apps Server are made (62-64).
If you see something like the following, Office Web Apps isn’t used.
Check if discovery took place successfully and make sure that the configuration for your OWA virtual directories are correct.
Office Web Apps Logs
To determine where the Office Web Apps Logs are stored, run the following command on the Office Web Apps Server:
Get-OfficeWebAppsFarm | ft LogLocation
In that folder you will find the log files. I must warn you, the logs are a bit chatty and can sometimes be cumbersome to go through. It’s always a good idea to have the user’s email address at hand to search through the logs:
I hope that this (lengthy) article will help you to better understand why and how you need to implement Office Web Apps with Exchange Server 2013. To me it’s almost unthinkable having to deploy Exchange 2013 without putting an Office Web Apps server (farm) next to it.
For many Administrators, this will be the first time they will be confronted with it. But my advise is: learn (to love) it. Alternatively, you could choose to move to Office 365 as this functionality is enabled by default for Office 365 mailboxes.
Many thanks to Jens Trier Rasmussen for some really invaluable input!