Chapter 27. Office Web Apps 2013 Integration with SharePoint 2013
In This Chapter
Planning for Office Web Apps 2013 Use
Key Differences Between Excel Services and Excel Web App
Server Prerequisites for OWA 2013 Overview
Browser Support of Office Web Apps
Licensing Requirements for OWA 2013
Installing and Configuring Office Web Apps 2013
Verifying the Settings in the Document Library
Testing OWA 2013 Functionality
Office Web Apps 2013 (OWA 2013) provides a browser-based viewing and editing experience for SharePoint 2013 users who need to collaborate on Word, Excel, PowerPoint, or OneNote documents. This is the second version of this product, and Microsoft has changed it from a SharePoint service application in SharePoint 2010 to a standalone product for use with SharePoint 2013 (and, of course, improved it in many respects, as covered in this chapter). OWA 2013 also provides functionality that Exchange Server 2013 and Lync Server 2013 can use, but this chapter focuses on the SharePoint 2013 features.
The browser-based viewing and editing of document capabilities has become more popular since other companies such as Google started offering products like Google Docs, and more knowledge workers needed access from a variety of devices such as smartphones and tablets, which often do not have the full Microsoft Office applications installed.
OWA 2013 also “powers” a large portion of the thumbnail previewing capabilities in SharePoint 2013 (in search results and in document libraries), and for that reason is also an important component for most enterprise implementations of SharePoint 2013.
This chapter provides an overview of the capabilities of the tool set and the configuration process, and walks through the user interface to clarify how the product might be of value to different types of organizations.
Planning for Office Web Apps 2013 Use
This section provides some “food for thought” for organizations interested in implementing the OWA 2013 functionality to allow end users another method of collaborating on Word, Excel, and PowerPoint documents. Prerequisites, licensing issues, and limitations by browsers are covered in this section, albeit from a fairly high level because of the wealth of information provided by Microsoft on these topics (for which links are given).
Fundamentally, it is important to be familiar with the different file types OWA 2013 can display. Fortunately, OWA 2013 displays the most common Microsoft Office file types, as summarized in the following list:
Word documents (.doc, .docx, .dotx, .dot, .dotm extensions)
Excel documents (.xls, .xlsx, .xlsm, .xlm, .xlsb extensions)
PowerPoint documents (.ppt, .pptx, .pps, .ppsx, .potx, .pot, .pptm, .potm, .ppsm extensions)
Note
PowerPoint Broadcast was provided in SharePoint 2010 but is removed from SharePoint 2013. It is available through SkyDrive and Lync Server 2013. This feature broadcasts PowerPoint slides and provides an embedded PowerPoint viewer that provides an optimal viewing experience, but is available only on the Windows platform.
Unlike its predecessor, which was a service application in SharePoint 2010, OWA 2013 provides functionality that can be used by a number of other popular Microsoft products. Figure 27.1 provides a visual summary of the connectivity points between OWA 2013 and other key Microsoft products (namely Exchange 2013, Lync 2013, and SharePoint 2013).
Key Differences Between Excel Services and Excel Web App
As discussed in detail in Chapter 26, “Extending SharePoint 2013 with Excel Services, Visio Graphics Services, and Access Services,” Excel Services provides a number of features that can be seen to overlap with OWA 2013. First of all, Excel Services allows users to view Excel files in their browsers and, to a very limited degree, interact with them. But Excel Services is not intended to allow users to edit content directly in the browser, whereas Excel Web App in OWA 2013 is specifically designed for editing content in the browser. Table 27.1 provides additional information about the differences between the products.
Note
It can be confusing to determine which product (Excel Services or Excel Web App) is rendering content, but the URL can help. If the URL contains the term WopiFrame, Excel Web App is involved; if the URL contains the term xlviewer, however, Excel Services is rendering the page.
Server Prerequisites for OWA 2013 Overview
OWA 2013 has a number of prerequisites, as covered in this section, to ensure a successful configuration. There are a number of recommendations on how not to configure the server that are important for the architect or administrator to understand to avoid unnecessary troubleshooting efforts.
Server prerequisites are listed in Table 27.2 along with other key notes on server configuration to keep in mind.
Specific Server 2008 R2 Prerequisites
As an older operating system, Windows Server 2008 R2 requires more downloads to be installed than Windows Server 2012, as summarized in the following list:
Office Web Apps Server 2013
.NET Framework 4.5
KB2592525 (An application that uses DirectWrite does not start in a restricted security context in Windows 7 or in Windows Server 2008 R2.)
Windows PowerShell 3.0
For Windows Server 2008 R2, the following list describes the minimum role services that are required for the web server (IIS) server role:
Common HTTP features
Static content
Default document
Application development
ASP.NET
.NET Extensibility
Internet Server Application Programming Interface (ISAPI) extensions
ISAPI filters
Server-side includes
Security
Windows authentication
Request filtering
Management tools
IIS Management Console
Ink and handwriting services
Ink support
The following are recommended but not required for Windows Server 2008 R2:
Performance
Static content compression
Dynamic content compression
Specific Windows Server 2012 Prerequisites
As a newer operating system, Windows Server 2012 already includes .NET Framework 4.5, KB2592525, and Windows PowerShell 3.0. However, the OWA Server 2013 software does still need to be downloaded as with Windows Server 2008 R2.
For Windows Server 2012, the following list describes the minimum role services that are required for the web server (IIS) server role:
Management tools
IIS Management Console
Common HTTP features
Default document
Static content
Security
Request filtering
Windows authentication
Application Development
.NET Extensibility 4.5
ASP.NET 4.5
ISAPI extensions
ISAPI filters
Server-side includes
In addition, the following are recommended but not required for Windows Server 2012:
Performance
Static Content Compression
Dynamic Content Compression
Note
Additional guidance and information is available from TechNet: http://technet.microsoft.com/en-us/library/jj219435.aspx. This includes guidance on load balancers, domain name server (DNS) requirements, planning language packs, topology planning, security planning, and design recommendations for larger OWA 2013 farms.
Note
Note that applying Office Web Apps Server updates by using the Microsoft automatic updates process isn’t supported with OWA 2013. First, the OWA 2013 Server must be removed from the farm by using the PowerShell commandlet (cmdlet) Remove-OfficeWebAppsMachine, and then Office Web Apps Server must be uninstalled by using Add or Remove Programs, the software update installed, and then the Office Web Apps Server farm can be re-created. This process is more complicated with multiserver farms and is described in detail on TechNet: http://technet.microsoft.com/en-us/library/jj966220.aspx. Microsoft recommends that organizations manage updates by using Windows Server Update Services (WSUS) or by using System Center Configuration Manager (SCCM), which uses WSUS.
Browser Support of Office Web Apps
For organizations that decide to support Office Web Apps, it is important to test the various browsers in use because the browser will become a primary tool used for editing documents. Simply stated, browser support for OWA 2013 is the same as for SharePoint 2013, so here is quick reminder of browsers supported by SharePoint 2013:
Internet Explorer (IE) 10: Supported
IE 9: Supported
IE 8: Supported
IE 7: Not Supported
IE 6: Not Supported
Google Chrome (latest released version): Supported
Mozilla Firefox (latest released version): Supported
Apple Safari (latest released version): Supported
Mobile browser support is shown in Table 27.3. Because there is such a proliferation of mobile devices, not all devices are officially supported by Microsoft and therefore not included in this table. The organization should test any devices not “officially” supported by Microsoft to determine the level of interaction possible when using these devices.
Note
Some functionality in SharePoint 2013 requires ActiveX controls, and currently only 32-bit versions of Internet Explorer support this functionality. You can find more information about the features that won’t be supported by browsers that don’t support ActiveX controls at http://technet.microsoft.com/en-us/library/cc263526.aspx#activex.
Licensing Requirements for OWA 2013
Organizations interested in using Office Web Apps in their environments still need to comply with Microsoft licensing policies. View-only functionality in OWA 2013 is free, but the ability to edit Office files in the browser requires an editing license.
SharePoint 2013 provides new license enforcement capabilities that are controlled through PowerShell, and which work with OWA 2013. This new licensing needs to be enabled, also via PowerShell, and then only users who have the appropriate license, or belong to Active Directory (AD) groups that have been approved, can edit Office files in their browsers using OWA 2013.
Office Web Apps licensing offers two options:
View-only: By default, OWA 2013 is view-only. View-only functionality is provided for free.
Edit and view: An editing license is required to use the editing features of OWA 2013 with SharePoint 2013. Editing can be enabled when you create the OWA 2013 Server farm.
Enterprise customers who are licensed for Office 2013 through a Volume Licensing program can enable OWA 2013 editing for SharePoint 2013 on-premises.
Refer to the Microsoft Software License Terms shown when Office Web Apps Server is installed for more details on licensing.
As always, consult with a qualified Microsoft software vendor for more complete details, because there are many ways OWA 2013 can be used. For example, there are additional capabilities when OWA 2013 is used in conjunction with Lync 2013.
Installing and Configuring Office Web Apps 2013
This section gives instructions for installing OWA 2013 on a single Windows Server 2012 server, and then shows how to connect to a SharePoint Server 2013 enterprise farm over HTTP. Many organizations might have more complex configurations, but this process provides an overview of the process involved with establishing basic functionality for testing purposes, or for smaller environments where a single OWA 2013 server may suffice.
Microsoft provides detailed instructions for a number of other different configurations at http://technet.microsoft.com/en-us/library/jj219455.aspx. It includes the following scenarios:
Deploy a single-server Office Web Apps Server farm in a test environment
Deploy a single-server Office Web Apps Server farm that uses HTTPS
Deploy a multiserver, load-balanced Office Web Apps Server farm that uses HTTPS
The following steps apply to the first scenario, that of deploying a single-server OWA 2013 Server farm in a test environment. The prerequisites for the server that are needed for this exercise are covered previously in this chapter in the section titled “Server Prerequisites for OWA 2013 Overview” in the Windows Server 2012 column. The items in the subsection titled “Specific Windows Server 2012 Prerequisites” are installed in the exercise steps that follow, so those do not need to be preinstalled.
Assuming you have a server that meets those requirements, and is connected to the same domain as your SharePoint 2013 farm, complete the following steps to configure Office Web Apps:
1. A PowerShell script will be run first to prepare the server for the OWA 2013 installation. If it isn’t run, you will receive an error message when trying to install OWA 2013.
2. Open Windows PowerShell on the Windows Server 2012 server (named OOWA201301 in this example). Paste in the following script and press Enter:
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
This character maps to American Standard Code for Information Interchange (ASCII) 45; to see the character, hold down the ALT key, type 45 on the numeric keypad, and then let go of the ALT key.
Note
A number of things can go wrong when using PowerShell and pasting in code. A general best practice is to paste code into Notepad first to clear any unneeded formatting, and then paste it into PowerShell. PowerShell also needs to run with sufficient permissions to execute the code, which can require additional steps, depending on the server configuration.
The results should be similar to those shown in Figure 27.2.
3. Reboot the server to complete the installation process.
4. When the server reboots, log in and download the Office Web Apps Server software, or locate the DVD with the software on it. The file used in this example is en_office_web_apps_2013_x64_dvd_1123682.iso.
5. Mount the ISO file so that it can be used, or insert the DVD; a message box should appear allowing you to tap to choose what happens with this disc. Click the link and click Run Setup.exe. If this message does not come up automatically, browse to the installation media and click Setup.exe.
6. Check the box next to I Accept the Terms of This Agreement, and click Continue.
7. On the Choose a File Location page, leave the defaults unless there is a specific reason for changing the file locations. 2.23GB is required for the installation, so verify that you have plenty of drive space available for the installation. Click Install Now.
8. When the installation completes, click Close to close the Microsoft Office Web Apps Server 2013 window.
9. Open Internet Explorer, and enter the following URL to locate and then download KB2810007: http://support.microsoft.com/kb/2810007. Then press Enter. Locate the link to download the 64-bit update package and click it.
10. When the download page opens, verify that English is the selected language and click the Download button. Answer any prompts to save the download in the appropriate location. The file wacserver2013-kb2810007-fullfile-x64-glb.exe will download.
11. Locate the file and click it to start the installation of KB2810007.
12. Check the box next to Click Here to Accept the Microsoft Software License Terms. Click Continue.
13. When the installation has completed, click OK to close the Update window.
14. Next, the OWA 2013 server farm is created. Open Windows PowerShell and enter the following code, replacing servername with the name of your server:
New-OfficeWebAppsFarm –InternalURL "http://servername" –AllowHttp –
EditingEnabled
In this case, the servername is http://owa201301. Note that Secure Sockets Layer (SSL) is not being used in this example.
15. When the script completes, as shown in Figure 27.3, you are prompted to enable editing. If you are confident that your environment is properly licensed, type Y and press Enter.
16. When the process completes, a list of configuration details is provided, as shown in Figure 27.4. This is a good time to take a screen capture of these settings or use PowerShell commands to export the settings to a text file. Note that the log location is listed here, which is important to know if you need to troubleshoot in the future.
17. Next, verify that the Office Web Apps server farm was created successfully by browsing to the .../hosting/discovery website on the OWA 2013 server. In this example, the URL http://owa201301/hosting/discovery is entered into the Address bar, and the results are shown in Figure 27.5.
FIGURE 27.5 Results of browsing to the .../hosting/discovery website after a successful OWA 2013 farm creation.
Now that the OWA 2013 server has been configured, the SharePoint 2013 “host” needs to be configured. You can find additional information about the host configuration process at http://technet.microsoft.com/en-us/library/ff431687.aspx.
Office Web Apps can be used only by SharePoint 2013 web applications that use claims-based authentication. Office Web Apps rendering and editing do not work on SharePoint 2013 web applications that use classic mode authentication. To verify the setting for the web application in question, access Central Administration, click Application Management, Manage Web Applications, select the web application in question (for example, SharePoint - 80), and click Authentication Providers on the ribbon. The Authentication Providers window should show claims-based authentication. If it doesn’t, OWA 2013 won’t support connectivity to the web application.
If you completed the steps in the previous section successfully, perform the following steps to configure the SharePoint 2013 host and test functionality:
1. From the SharePoint 2013 host server, open SharePoint 2013 Management Shell.
2. Next, you create the binding between SharePoint 2013 and the OWA 2013 server. Enter the following code into the Management Shell and press Enter:
New-SPWOPIBinding -ServerName servername –AllowHTTP
In this example, servername is replaced by "owa201301.company123.org" (with quotations included), which is the fully qualified domain name (FQDN) for the OWA 2013 server.
A long list of settings displays, as shown in Figure 27.6.
3. Next, the Web application Open Platform Interface (WOPI) zones for the SharePoint bindings need to be set. OWA 2013 uses the concept of zones to determine which URL (internal or external) and which protocol (HTTP or HTTPS) to use when it communicates with the host. Enter the following code in the Management Shell:
Set-SPWOPIZone –zone "internal-http"
4. To verify the setting, enter the following code in the Management Shell:
Get-SPWOPIZone
The results should look like Figure 27.7, where the SPWopiZone displays as internal-http.
Note
The application programming interface (API) that OWA 2013 uses to communicate with hosts is called WOPI (Web application Open Platform Interface). Office Web Apps Server accesses and manipulates files using the WOPI API. WOPI is a RESTful API that uses HTTP/HTTPS, which means that, as much as possible, Office Web Apps Server is stateless. This makes it more resilient to failures such as network outages to hardware failure.
5. Next, the AllowOAuthOverHttp setting in SharePoint 2013 needs to be set to True. Enter the following code in the Management Shell:
$config = (Get-SPSecurityTokenServiceConfig)
6. Then, enter the following code:
$config.AllowOAuthOverHttp = $true
7. Next, enter the following code:
$config.Update()
8. To verify the settings have applied, enter the following code:
(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp
Figure 27.8 shows the results of these PowerShell commands. Note that the value of True should appear after the last Get command is entered. This means that AllowOAuthOverHttp is set to True.
9. Now it is time to verify that Office Web Apps is working. Navigate to the SharePoint 2013 site collection on the host that has been configured in this exercise. Access a document library and click the ellipsis next to a Word document. The results should look like Figure 27.9, where the hover panel displays a thumbnail of the first page of the Word document.
Note
There are many reasons why OWA 2013 might not work even if all the previous steps have been followed. Some tips are as follows:
Make sure that the library containing the files is configured to allow OWA 2013 viewing (see the next section, “Verifying the Settings in the Document Library”).
Verify that claims authentication is enabled for the web application housing the site collection that houses the documents being tested.
Verify that the Site Collection Feature Open Documents in Client Applications by default is not activated.
A full crawl may be required for thumbnails to function properly.
Make sure that you are not logged in as System Account. Whenever the currently logged-in username appears as sharepointsystem, that user cannot edit or view the document. Log in as a different user and try to access Office Web Apps again.
Make sure that the document doesn’t exceed 10MB, which is the default limit.
You can find additional troubleshooting tips at http://technet.microsoft.com/en-us/library/ff431687.aspx.
Verifying the Settings in the Document Library
An additional step to take in an existing SharePoint 2013 environment is to validate the settings of the document library or libraries that house the documents that the administrator wants to support the OWA 2013 access method. Follow these steps to ensure that the document library is configured to support OWA 2013 use:
1. Navigate to the document library with an account that has owner-level permissions on the site and click the Library tab on the ribbon; then click the Library Settings button.
2. Click Advanced Settings in the General Settings section.
3. In the Opening Documents in the Browser section, select the option next to Open in the Browser or Use the Server Default (Open in the Browser). Click OK.
4. Test that viewing Word, Excel, or PowerPoint documents in the browser and editing in the browser is functioning properly.
Testing OWA 2013 Functionality
Now that the service applications are configured and the configurations for the site collection, library, and Central Administration have been reviewed, it is time to test the functionality of OWA 2013 by accessing and editing documents in the browser.
The following sections assume the following:
On the PC: Word 2013, Excel 2013, and PowerPoint 2013 are installed on the PC, which is using Windows 8 and IE 10.
For the document library: The Advanced Settings page is set to Open in the Browser in the Opening Documents in the Browser section. Documents are not required to be checked out before they are edited, nor is content approval required for submitted items.
For the site collection: In Site Collection Features, the Open Documents in Client Applications by default is not activated.
Testing Word Access via OWA 2013
Assuming the conditions listed at the beginning of the “Testing OWA 2013 Functionality” section are met, follow these steps to test Office Web Apps with a Microsoft Word 2010 document. These steps are high level, and additional testing from different browsers, operating systems, and versions of Office should be performed:
1. Using an account with contribute-level permissions, navigate to the document library that meets the prerequisites listed in the previous section and that contains one or more files created in Word 2013.
2. Hover over the Name field of a Word document and click it. The file should open in the same browser session, as shown in Figure 27.10. Note that the toolbar provides a File tab, Edit Document, Share, Find, and Comment icons, and a Zoom drop-down menu in the lower-right corner.
3. Click the Edit Document icon, and select the Edit in Word Web App option; the Word Web App re-renders and adds a ribbon to allow for editing of the document.
4. A limited Word ribbon now appears, which provides File, Home, Insert, Page Layout, and View tabs. Review the tools available to get a sense for the functionality supported.
Multiple users can now edit a Word document via OWA 2013, a feature not available with OWA in SharePoint 2010. To test this, with the Word document open for editing as one user (User1), access the same document using another PC and different user account (User2) so that it opens in the browser, and click Edit in Browser. Make changes using the different user accounts, and save from both accounts; then exit, reopen, and review the changes. If multiple users are editing the same document, OWA 2013 displays a message that another user is also editing the document and highlights changes in a different color after they are saved.
5. Add an image to the document, as shown in Figure 27.11. Note that a new tab appears when the image is added and selected that provides limited image-editing tools.
6. Click the Save button to save the changes.
7. Click the Close button; the browser returns to the document library.
This simple testing can be used as training for users new to the OWA 2013 products and can help them gain confidence editing documents in the browser.
Testing Excel Access via Office Web Apps
If the organization has both Excel Services and OWA 2013 installed, it is important for IT, site administrators, and end users to understand the differences in capabilities between the products. The differences between Excel Services and Excel Web Apps were discussed earlier in this chapter in the section titled “Key Differences Between Excel Services and Excel Web App,” but IT should ideally provide training to users to ensure that they understand the capabilities and the pros and cons of each solution.
Assuming the conditions listed at the beginning of the “Testing OWA 2013 Functionality” section are met, Excel document access via Office Web Apps should be functional. This section reviews a sampling of features available when a user chooses to edit an Excel spreadsheet in SharePoint 2013, and also tests two users accessing and editing the same spreadsheet in OWA 2013.
Follow these steps to test the Excel services application:
1. Using an account with contribute-level permissions, navigate to the document library that meets the prerequisites listed at the beginning of this section and that contains one or more files created in Excel. The Excel file should have some equations and at least one graph in it ideally.
2. Hover over the Name field of an Excel document and click it. The file should open in the same browser session.
3. Access the Edit Workbook drop-down menu, and select Edit in Excel Web App. Note that the tools offered for Excel differ subtly from those for Word (as covered in the previous section). The toolbar provides a File tab, Home tab, Insert tab, View tab, and Open in Excel icon, as shown in Figure 27.12. Note that the URL contains the page WopiFrame.aspx, which informs us that OWA 2013 is rendering the current content.
Note
There is no Save button when Excel is edited in the browser. Instead, all changes are saved when they are made.
4. Test multiple people editing the spreadsheet in the browser by logging in to the same SharePoint site with a different user from a different PC or image and access the Edit Workbook drop-down menu; then select Edit in Excel Web App. As shown in Figure 27.12, in the lower-right corner, the different users editing the spreadsheet are tracked.
5. Test modifying the spreadsheet with two users simultaneously to see the results.
If two or more people edit a spreadsheet in the browser, none of the users can click Open in Excel; instead, a message displays stating, “You are currently collaborating on this workbook with other people. You cannot edit this workbook in Excel while other People are also editing it in the browser or filling out a survey from this workbook.”
Testing PowerPoint Access via Office Web Apps
Assuming that the conditions listed at the beginning of the “Testing OWA 2013 Functionality” section are met, PowerPoint document access via Office Web Apps should be functional. This section reviews a sampling of features available when a user wants to access a PowerPoint document via Office Web Apps.
Follow these steps to test the PowerPoint services application:
1. Using an account with contribute-level permissions, navigate to the document library that meets the prerequisites listed previously and that contains one or more files created in PowerPoint.
2. Click the name of the PowerPoint file; it opens in the browser. A File tab is visible, as are Edit Presentation, Share, Start Slide Show, and Comments tabs. Slide navigation arrows are available at the bottom, as well as a Notes button, Editing View button, Reading View button, and Slide Show button.
3. Access the Edit in Presentation drop-down menu and click Edit in PowerPoint Web App. As shown in Figure 27.13, the tabs available are: File, Home, Insert, Design, Animations, Transitions, and View.
Summary
This chapter covers the new iteration of Office Web Apps that is a separate application from the SharePoint product line. The general consensus is that this is a good thing, because the previous version of Office Web Apps as a service application had some issues. It is also an appropriate change since OWA 2013 provides functionality to other Microsoft applications other than SharePoint. Prerequisites are covered along with the installation and configuration process of OWA 2013 on a single server that connects via HTTP to a SharePoint host. Numerous notes are provided that further expand on the capabilities, limitations, and troubleshooting the product. Examples of interacting with OWA 2013 are provided for Word, Excel, and PowerPoint documents. In summary, Office Web Apps provide some valuable tools for organizations wanting to provide viewing and editing of Word, Excel, and PowerPoint content to users through supported browsers, but caveats and limitations also apply to the editing and collaboration tools made available in the browser.
Best Practices
The following are best practices from this chapter:
OWA 2013 enables end users to view and edit Word, Excel, and PowerPoint documents in supported browsers when properly configured. It also renders thumbnail images in document libraries and the SharePoint 2013 search engine. Most organizations find these are highly valuable features and save end users time by allowing them to see the documents before opening them, as well as editing them in supported browsers if needed.
Organizations interested in using OWA 2013 in their environments still need to comply with Microsoft licensing policies, as discussed from a high level in this chapter.
There are a number of differences between the capabilities of Excel Services and Excel Web App, both of which allow end users to interact with Excel documents in their browsers, that are summarized in this chapter.
OWA 2013 now allows multiple users to edit Word, Excel, and PowerPoint documents simultaneously.
Even when OWA 2013 is properly configured, troubleshooting may be required, and there are many prerequisites that need to be met in terms of the configuration of the OWA 2013 servers, the web application, and the document library that houses the documents. These were covered throughout the chapter.