- Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
- Use Azure Storage for backup - Thu, Feb 23 2023
- Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023
As you probably know, Office Web Apps Server is a SharePoint add-on product that gives you Web browser-based versions of the following Office applications:
In my experience, Office Web Apps (confusingly referred to as OWA in Microsoft product documentation--don't you think of "Outlook Web App"?) is a no-brainer for on-premises SharePoint deployments because your users can view, edit, and create Office documents without having to rely upon locally installed Office software.
What you might not yet know is that the current version of the product, Office Web Apps Server 2013, is quite changed from its previous iteration. Here are the major changes:
- OWA 2013 is no longer a service application that is directly integrated into SharePoint. Now OWA runs as a separate server
- OWA 2013 cannot be installed on the same server running (a) SharePoint; (b) SQL Server; (c) AD DS. Also, you can't have a local installation of Office on your OWA server.
- OWA 2013 now supports multi-author editing
- OWA 2013 now supports Adobe PDF conversion from Word (Didn't see that one coming, did you?)
- OWA 2013 requires Windows PowerShell for all aspects of installation and management
I'm sure that my final bullet point may strike a bit of fear into the hearts of Windows administrators who have not yet taken the plunge into Windows PowerShell. Look at it this way: Deploying OWA 2013 to your SharePoint farm gives you the perfect excuse to dive into master Windows PowerShell!
One more preliminary note--about licensing. OWA 2013 is free to download, and the product may be installed on as many servers as you need to run the service. The cost comes in user licensing, and the details on this depend upon (a) whether your users will read documents or read and write; and (b) whether your OWA faces only your internal environment or if it will be exposed to the Internet.
I'll spend the remainder of this blog post giving you the high-level overview of how to set up OWA 2013 in your SharePoint farm. For better or for worse, I assume that your servers all run Windows Server 2012 and your SharePoint environment is based in SharePoint Server 2013.
For those who love summaries, here are the steps from a bird's eye perspective:
- Manually install the prerequisite software
- Download and install the OWA 2013 binaries
- Download and install the latest Public Update
- Create the OWA farm
- Configure the SharePoint-OWA binding
Let's begin!
Download and installation
As I said already, you can download the Office Web Apps Server 2013 for free from the Microsoft Download center. Again, when you pick out your candidate server to run OWA 2013, remember that the server can't have SharePoint, SQL, or Office installed locally.
You know how SharePoint has a prerequisite installer that automates the installation of prerequisite software? Yeah, well OWA 2013 doesn't include any of that. If you try to install the OWA binaries by running Setup.exe from the downloaded bits, you'll see the uninformative error message that is shown below.
Setup is unable to proceed due to the following error(s)
What exactly are the OWA 2013 prerequisites? Check the documentation, and in the meantime, let's go ahead and manually configure the prerequisites proactively. Fire up an administrative PowerShell session, run Import-Module ServerManager, and then issue the following statement:
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
You'll need to reboot the OWA server once the PowerShell statement completes.
Once you're back from the reboot, run Setup.exe again and accept all defaults. When you are finished laying down the binaries you'll see equally content-free message box shown in the next screenshot.
Thank you for installing Microsoft Office Wet Apps Server 2013.
Before we create our OWA farm and connect OWA to our existing SharePoint farm, download the latest Office Web Apps Server 2013 public update from the Microsoft Download Center. There's no magic here--download, install, and reboot.
With that out of the way, let's remain on the OWA server and create our OWA farm.
Configuration
Okay. Believe it or not, we need only a single PowerShell statement to set up the OWA farm on our OWA server. Check it out:
New-OfficeWebAppsFarm -InternalURL http://owa -AllowHttp -EditingEnabled
In the previous example, http://owa is the name of my OWA server, and AllowHttp disables the requirement for digital certificates and SSL/TLS. Of course, your business requirements might require secure communications. The EditingEnabled parameter is what costs the money--internal OWA instances support document reading for free (Yay, Microsoft!).
At any rate, make sure to study the New-OfficeWebAppsFarm syntax so you are clear as to all the available options.
Now switch over to your SharePoint 2013 server, open an administrative PowerShell session, and run the following statements:
Add-PSSnapin Microsoft.SharePoint.PowerShell
This statement loads the SharePoint 2013 snap-in into memory.
New-SPWOPIBinding -ServerName owa.nuggetsphere.local -AllowHTTP
The New-SPWOPIBinding cmdlet creates the Web Application Open Platform Interface (WOPI) binding between your SharePoint farm and the OWA 2013 server. This binding will redirect requests to certain Microsoft Office file extensions (such as those registered to Word, Excel, PowerPoint, and OneNote) to the OWA server. The AllowHTTP flag is relevant only for test cases like mine in which I do not need SSL encryption.
Set-SPWOPIZone -zone "internal-http"
The Set-SPWOPIZone cmdlet configures the zone that the SharePoint farm will use to navigate the user's browser to the WOPI application. The possible options are as follows:
- Internal-HTTP
- Internal-HTTPS
- External-HTTP
- External-HTTPS
If you use OWA in an HTTP environment like I'm doing here, then you also need to set the AllowOAuthOverHttp property of the SharePoint Security Token Service (STS) object to True. Here's the formula:
$config = (Get-SPSecurityTokenServiceConfig) $config.AllowOAuthOverHttp = $true $config.Update()
The third line is important because we need to write our change back to the SharePoint farm configuration database. You can verify the configuration by running the following statement; you should get back a value of True.
(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp
Usage
Let's get this party started. Connect to your target SharePoint 2013 Web application, navigate to a document library, and open a compatible Office document as usual. To ensure that the document opens in a browser as opposed to a local Office application, you can either open the document's fly-out menus or set the default document option action in the document library settings pages.
You can see what a document looks like when it's open for editing in Word Web App by inspecting in the next screenshot and a browser-based PowerPoint deck after that.
The editing experience in Office Web Apps is excellent, on par with that of Office 365.
Office Web Apps makes it convenient to display PowerPoint content without requiring the presence of a local PowerPoint installation.
That wasn't too difficult, was it?
