Exchange 2013 with Office Web Apps Server Integration

Introduction

With Exchange 2007 and 2010, Outlook Web Access/App [OWA] users can preview documents attached to e-mails directly from their browser. This feature, known as WebReady Document Viewing, converts supported documents (Word, Excel, PowerPoint or PDF) to HTML and displays them in the web browser, allowing users to read Word documents, for example, without the need to have Word installed or first downloading the file.

Whenever a user receives an e-mail with a supported attachment, an “Open as Web Page” link appears next to the attachment:

Figure 1: WebReady Document Viewing Link in Exchange 2010

All the user needs to do to preview the attachment is click on the link and the WebReady Viewing version of the document will open:

Figure 2: WebReady Document Viewing in Exchange 2010

With Exchange 2013 there is another method to preview these types of documents. To provide an even better experience to users, we can integrate Exchange 2013 with Microsoft Office Web Apps Server [OWAS].

Up until now, to provide the WebReady Document Viewing functionality, Microsoft relied partially on 3rd-party components. With all the security concerns that there has been around this functionality, replacing it with OWAS might not be such a bad idea… This also means that Microsoft has full control over all the components used by this feature.

By default, the following file types are displayed using OWAS:

• Word documents (doc, docx, dotx, dot and dotm extensions);
• Excel documents (xls, xlsx, xlsm, xlm and xlsb extensions);
• PowerPoint documents (ppt, pptx, pps, ppsx, potx, pot, pptm, potm and ppsm extensions).

With previous editions of Exchange, WebReady Document Viewing is built in to Exchange. With OWAS integration in Exchange 2013, SharePoint 2013 and Lync Server 2013, when a user wants to preview an Office attachment, Exchange/SharePoint/Lync makes a Web app Open Platform Interface [WOPI] call to the Office Web Apps Server which renders the document instead.

Note:
OWAS is not used to render attachments in IRM [Information Rights Management] protected messages.

Installing Office Web Apps Server

Although this article is about the integration of OWAS with Exchange 2013 and how to configure it, I will provide a basic guide on how to install OWAS on a single Windows Server 2012 box.

The first step is to install the prerequisite software for OWAS. To do this, open a PowerShell console as an administrator and run the following cmdlet and then restart the server:

Add-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

Figure 3: Installing OWAS Requisites

Now, download Office Web Apps Server from the Microsoft Download Center. Double-click the .img file you just downloaded and run Setup to start the installation:

1. On the Read the Microsoft Software License Terms page, select I accept the terms of this agreement and then select Continue:

Figure 4: OWAS Installation – License Terms

2. On the Choose a file location page, select the folder where you want to install OWAS and then select Install Now (I left the default location):

Figure 5: OWAS Installation – File Location

3. When Setup finishes installing Office Web Apps Server, click on Close:

Figure 6: OWAS Installation – Complete

After installing Office Web Apps Server, you might notice that there is no GUI to manage it! This is because configuration and management of OWAS is done solely through PowerShell. Unlike products such as Exchange, Lync or even SCOM, OWAS only has a few cmdlets:

Figure 7: OWAS Cmdlets

Configure Office Web Apps Server

Now that Office Web Apps Server is installed, we need to configure it.

OWAS can communicate with SharePoint, Lync and Exchange using HTTPS by the means of a digital certificate. This is obviously highly recommended for production environments. In a test environment, however, you do not need to use HTTPS, but in this case Lync will not work.

If you want to use HTTPS, please note that the certificate used in the OWAS server must meet the following requirements:

• The certificate must come from a trusted Certificate Authority [CA] and include the fully qualified domain name of the Office Web Apps Server farm in the Subject Alternative Name field (and must not begin with an asterisk);
• The certificate must have an exportable private key;
• The Friendly name field must be unique within the Trusted Root Certificate Authorities store;

After obtaining an SSL certificate from your own or a 3rd-party CA (usually recommended if you plan to allow external access to your OWAS server) you have to import the certificate to the OWAS server (I used the Certificates MMC to request a certificate from my internal CA which automatically saves it into the local certificate store). However, don’t bind the certificate manually in IIS as this will be done automatically as we will see shortly.

Although we are installing OWAS in a single-server, we still need to create a farm. This is done using the New-OfficeWebAppsFarm cmdlet and the following parameters:

• –InternalURL is the FQDN name of the server that runs OWAS;
• –ExternalURL is the FQDN name so that OWAS can be accessed on the Internet;
• –CertificateName is the friendly name of the certificate to be used for HTTPS;
• –EditingEnabled (optional) enables editing in Office Web Apps when it is used together with SharePoint. It is not used by Lync or Exchange because these hosts do not support editing.

There are many additional parameters to configure a farm, which are not relevant for this article. To know more about these, run: Get-Help New-OfficeWebAppsFarm -Detailed

In my environment, I used the following cmdlet:

New-OfficeWebAppsFarm -InternalUrl “https://owas.letsexchange.com” –CertificateName “OfficeWebApps Certificate” –EditingEnabled

Figure 8: OWAS Configuration – New Farm

After the farm is created, we can see its details in the PowerShell window. To verify that OWAS is installed and configured correctly, use a web browser to navigate to the OWAS discovery URL, composed of the InternalUrl followed by /hosting/discovery. In my case:

https://owas.letsexchange.com/hosting/discovery

If OWAS is working as expected, you will see a WOPI-discovery XML file in the web browser:

Figure 9: OWAS WOPI-discovery XML

Configure Office Web Apps Server Integration

Now that we know that OWAS is working fine, let’s configure Exchange 2013 to use it.

Configure Office Web Apps Server URL

To use OWAS to render attachments in OWA, first we need to specify the URL of the OWAS using the Set-OrganizationConfig cmdlet (this is done from an Exchange Management Shell):

Figure 10: Configuring OWAS URL

Note:
WAC stands for Web Access Components.

If everything went well, you will see the Application Log the 140 and 142 Event IDs for MSExchange OWA. 142 means the discovery of the Office Web Apps Server was successful, while a 141 means something went wrong:

Figure 11: OWAS Integration Configuration Event ID 140

Figure 12: OWAS Integration Configuration Event ID 142

Enable Office Web Apps Server Rendering

By default, the OWA Virtual Directory is already configured to enable the rendering of attachments through OWAS both on public and private computers:

Figure 13: OWA Virtual Directory Configuration

If you want to disable, for example, OWAS from being used on public computers, you can do so using the following cmdlet (this assuming OWAS is accessible from outside your internal network):

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -WacViewingOnPublicComputersEnabled $False

Force Office Web Apps Server Rendering

Another available option is to force users to render attachments using OWAS first before they can open them. As you guessed, this is done by setting ForceWacViewingFirstOnPublicComputers and/or ForceWacViewingFirstOnPrivateComputers to True.

Office Web Apps Server Logs

To determine where the Office Web Apps Logs are stored, run the following cmdlet in the OWAS PowerShell prompt:

Figure 14: OWAS Log Files Location

In that folder, which you can change, you will find OWAS log files. OWAS is very “verbose” so these logs contain a lot of information which makes them hard to go through. However, all the information is there.

Office Web Apps Server Document Preview

Once everything is working, we can preview Office documents the same way we do in Exchange 2007 and 2010: by clicking on the Preview link next to the attachment:

Figure 15: Document Preview in Exchange 2013

As you can see from the screenshot below, OWAS integration works in any of the “main” web browsers and the document preview itself is much more faithful to the actual document than with WebReady Document Viewing (compare this with Figure 2):

Figure 16: Document Preview in Exchange using OWAS

Conclusion

Integrating Office Web Apps Server with Exchange 2013 to preview Office attachments might be a security and user experience improvements, but it is still another piece of software that administrators have to consider, design and implement and maintain…

It would be interesting, and useful, if Microsoft allowed users to edit documents through OWA using OWAS as they do when using SharePoint. Maybe this will be available soon.