Office web apps server
Exchange 2013 with Office Web Apps Server Integration
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.
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:
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:
- 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
- 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
- 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:
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
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
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.
How To Deploy Office Web Apps Server 2013
The 4 Steps Of Office Web Apps Server 2013 Installation
Office Web Apps provides browser-based versions of Excel, One Note, Word and PowerPoint. It also helps users who access files through SharePoint 2013.
The objective of this topic is to define the steps to install office web apps 2013, create the farm and the binding so that it can be used within SharePoint 2013 test environment.
For this example, we have the following systems in place:
- Windows Server 2012 r2
- SharePoint Server 2013
1) Install Server roles, features & Role services
- Ink and Handwriting services
- Dynamic Content Compression
- Windows Authentication
- .Net Extensibility 4.5
- ASP.Net 4.5
- Server Side Includes
Restart the server.
Note that if your installation is done on Windows Server 2016, the feature “Ink and Handwriting services” is now a default part of the server and no longer requires a separate package.
2) Install Office Web Apps
Launch the setup from the DVD file and wait until the installation is finished.
3) Create Office Web Apps Farm
1) Specify the internal URL for the server name
2) Use administrative privileges
3) run the Power Shell command “New-OfficeWebAppsFarm -InternalURL http://servername -AllowHttp -EditingEnabled”
This command allows HTTP as it is internal and the function enable editing to allow users to edit documents.
To verify that the farm is successfully created, type in the browser the URL “http://servername/hosting/delivery”.
4) Bind Office Web Apps and SharePoint
The communication between both sides still need to be done through HTTP protocol.
1) Use administrative privileges
2) Switch over SharePoint management shell
3) Run the command “New-SPWOPIBinding -ServerName servername -AllowHTTP”
The command should return that HTTP protocol is used internally and a list of bindings.
Check SharePoint default internal zone:
If it is HTTPS, change it into HTTP:
Set-SPWOPIZone -Zone internal-http
Set the authentication OAuth over HTTP to true:
- $config = (Get-SPSecurityTokenServiceConfig)
- $config.AllowOAuthOverHttp = $true
SharePoint can now use Office Web Apps.
To avoid errors, few points need to be verify before testing Office Web apps within SharePoint:
a) Check SharePoint authentication mode (claims-based and not classic) using PowerShell:
- (Get-SPWebApplication $WebAppURL).UseClaimsAuthentication
b) Check that the login account is not a system account but a testing account.
c) Enabling editing Office Web Apps, if it is false, set it to true using the PowerShell command:
d) Check that Office Web Apps has enough memory
Need help, more details can be found on here.