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:

  • Word
  • Excel
  • Powerpoint

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.

image
(image used from Microsoft’s Ignite Course)

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:

Install-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices

Next, download and run the Office Web Apps Server setup. The installation itself is very simple:

Accept the license terms and click Continue:

image

Enter the path where the Office Web Apps Server should be installed and click Install Now:

image

Wait for the installer to complete:

image

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:

    • Get-OfficeWebAppsFarm
    • Get-OfficeWebAppsHost
    • Get-OfficeWebAppsMachine
    • New-OfficeWebAppsFarm
    • New-OfficeWebAppsHost
    • New-OfficeWebAppsMachine
    • Remove-OfficeWebAppsHost
    • Remove-OfficeWebAppsMachine
    • Repair-OfficeWebAppsFarm
    • Set-OfficeWebAppsFarm
    • Set-OfficeWebAppsMachine

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:

image

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”:

image

Enter a name for this policy and click Next:

image

Click Allow and then click Next:

image

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:

image

Click Use SSL… and click Next:

image

Enter the internal host name (or VIP) that points to your Office Web Apps Server/Farm and click Next:

image

Enter /* as the path, select Forward the original host header instead of the actual one… and click Next:

image

Enter the external hostname for your Office Web Apps Server and click Next:

image

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:

image

Select No delegation, but client may authenticate directly and click Next:

image

Accept de default (All Users) and click Next:

image

Click Finish to create the rule.

image

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:

image

Make sure you deselect Verify normalization and Block high bit characters and then click Apply:

image

Confirm your changes by applying the configuration to the TMG server:

image

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:

SNAGHTML1fb4a9db

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”

For example:

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):

image

image

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:

image

image

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)

Fiddler2

When using Fiddler, you should see something like this when clikcking the “Preview”-link:

image

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.

image

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

image

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:

image

Conclusion

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!

18 comments

  1. Great article Michael. Iv been looking for some clarity on this server role for a while. Even for a lab enviroment does this need to be installed on a dedicated server? Or can it be co-located with Exchange or even a Lync role? And is it me or is Fiddler THE MOST AWESOME tool for troubleshooting Lync/Exchange Web Services? 🙂

    1. As far as I know, it isn’t supported running Office Web Apps alongside Exchange, Lync or SharePoint. Because each of these servers needs IIS, I guess adding another workload might cause some additional issues. Furthermore, you wouldn’t want Office Web Apps to take away valuable resources either… As to whether that’s possible in your lab: I haven’t tried it (yet), so won’t be able to tell if it works or not…

      And you’re right. Fiddler is pretty much thé tool for troubleshooting web services, so I’m with you on that one 🙂

  2. very nice article Michael. One question though, when it comes to specifying the common name of the certificate when creating a new web farm, where do I find that? is that an already configured certificate from a CA? Do I need to create a CA server and generate a certificate before creating a new officewebapp farm?
    Thanks,

    1. Hi Boris,

      you’ll either need to buy a certificate from a 3rd party CA (e.g. Digicert, Verisign, …) OR you could get a certificate from your own (internal) CA. If you don’t have an internal CA, I think you’d be better (and cheaper) off just buying one. The name from the certificate is the one that you give it, and you can find it from the properties of the certificate.

  3. Hi Michael
    Very nice article, one thing in which i am confused, if i want owa users to preview a document then in this case should i deploy a certificate from internal CA or should i add SAN name of office web server farm external url in the existing exchange certificate, please note users are accessing OWA from out side the organization and their machines are not joined to the domain, also do i have to have a dedicated public IP and do i have to create A record in external DNS for office web apps external url.
    if i am using two servers in office web apps farm then in this case should i add office web apps server names as well as internal and external urls in the SAN name of the certificate or only internal and external url should be fine
    our internal domain name is different then the external one, but in our internal dns server we have dns zone for our external dns name in which some records are created, would it be fine if i will give internal and external url same
    Thanks

    1. Hi there!

      Thanks for the feedback.

      So, about your question. You will need to include the internal & external name as either a subject alternative name (SAN) or as the subject name on the certificate that is used for Office Web Apps. Given that your users aren’t domain joined, you’d better use a 3rd-party certificate (e.g. from Digicert, …). If you are using split-dns (using the same domain name internally and externally), that will save you some names on the certificate as they would be the same. For example, if you are using owa.domain.com as your internal URL and your external URL, you’d need only a certificate of which the Subject Name would match “owa.domain.com”.

      Hope this helps!

      Michael

    1. Charles,

      officially, the certificate shouldn’t have an asterisk in the SAN. However, I’ve tested it and a wildcard certificate works just fine…
      The documentation could be more clear, but if you have a wildcard certificate, you don’t have to go and purchase a new certificate right away.

      However, if you ever run into issues (even if they’re not related), you might perhaps be required to purchase a separate certificate.

      Other than that, there are also some other requirements which you can read here: http://technet.microsoft.com/en-us/library/jj219435.aspx

  4. Hello Michael

    Do you know if its at all possible to bind the webapps to another port. I am trying to setup my test lab and I am already using 443 for exchange (on the nat gateway) *exchange is installed on a separate machine but I only have one public IP address.

    Thanks

    1. Hi Michael,

      I haven’t tried it myself, but I could imagine that by specifying a port-number in the URL (e.g. http://owaserver.domain.com:444) you’d be able to alter the port. You’d have to test it though. On the other hand, to overcome the issue of a single external IP address (I have that ‘problem’ myself), you could use a TMG which allows you to forward traffic to another server based on the hostname (e.g. outlook.domain.com and owaserver.domain.com point to the same external IP but the first one is forwarded to Exchange and the latter is forwarded to the Office Web Apps Server. That’s how I do it atm.

      Cheers!

      Michael

  5. Hi Michael, Just to point one small but important thing with the command New-OfficeWebAppsMachine –MachineToJoin the is the one of another member of the farm, not the current server name. I just struggle with that for a hour, so I prefer point it out to you and your reader.

    Great Article by the way !

    1. look like my comment didn’t go as expected, you should read New-OfficeWebAppsMachine –MachineToJoin name is the name

  6. Hello Michael,
    thank you for this great post, it helps.

    I’ve got this error in the event viewer when I try to access an Office document from the Internet: Could not contact WOPI End Point. Error details – ‘Unauthorized url

    In the ULS logs, I’ve got:

    HttpRequestAsync (WOPICheckFile,WACSERVER), request failure [HttpResponseCode:Unauthorized, HttpResponseCodeDescription:Unauthorized ( The server requires authorization to fulfill the request. Access to the Web server is denied.

    I’ve followed your explanations for the TMG publication. Nothing special in the TMG logs …

    Any idea?
    Thanks

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s