Enabling Licensing and Editing for Office Web Apps in SharePoint 2013

I had the unfortunate need to understand the licensing model a little bit better recently for enabling editing in Office Web Apps.  It’s a little bit of a circuitous route so I thought I would just quickly detail it here.  In short you want to:

  1. Create a new license mapping for folks that are going to be editing Office Web Apps.  This license mapping is created with the New-SPUserLicenseMapping cmdlet, and it allows you to say “this claim” maps to “this right”.  The list of rights is hard-coded, and you can get them with the Get-SPUserLicense cmdlet.  For editing Office Web Apps you want to use the OfficeWebAppsEdit right.  The “this claim” can be an Active Directory group or any other claim that your users are going to have. After you’ve created the mapping you want to add the mapping and turn on licensing.  For more details see http://technet.microsoft.com/en-us/library/jj219627.
  2. When you create the Office Web Apps farm use the -EditingEnabled switch; you can also use this with the Set-OfficeWebAppsFarm cmdlet after the fact.  For more details see http://technet.microsoft.com/en-us/library/jj219436.

So a complete PowerShell script for this would look something like this (assuming I’m using membership in an AD group called “OWA Editors” as the claim required to edit):

#NOTE:  this is using an AD security group so I’m using the -SecurityGroup parameter
#if I was using FBA, then instead I would use the -Role and -RoleProvider parameters
#if I was using SAML, then instead I would use the -ClaimType, -OriginalProvider and
#-Value parameters, or you can just use the -Claim with an SPClaim parameter
$a = New-SPUserLicenseMapping -SecurityGroup “OWA Editors” –License OfficeWebAppsEdit
$a | Add-SPUserLicenseMapping
Enable-SPUserLicensing
New-OfficeWebAppsFarm -Verbose -InternalUrl https://<machinename> -ExternalUrl https://<fully.qualified.machine.name> -CertificateName <FriendlyNameOfCertificateFromPreviousStep> -ClipartEnabled -TranslationEnable -EditingEnabled

For more details on getting Office Web Apps set up in your farm you can also see my earlier post on it here:  http://blogs.technet.com/b/speschka/archive/2012/07/23/configuring-office-web-apps-in-sharepoint-2013.aspx.

Where Did My OWA ULS Logs Go In SharePoint 2013

One of the neat features about SharePoint 2013 is that Office Web Apps has been split off into it’s “own product” so it doesn’t have to be installed on a SharePoint server anymore.  There are lots of reasons to do that, like being able to maintain a separate patching schedule, being able to do a patch with no downtime, using the same OWA farm for multiple SharePoint farms or other applications, etc.  One of the things that can be tricky to figure out though is what to do when you need to troubleshoot an issue.


Well it turns out that we still have ULS logs for OWA, even though it’s not “SharePoint” per se.  The log files are not where you’re used to finding them though – you need to look in the C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS folder to find them.  That’s the default location, you can change it as well using PowerShell.  Once you find them the same tools that you use to examine SharePoint ULS log files will work with these as well.  Hopefully you won’t ever need to use this post  🙂  but just in case, here it is.

Configuring Office Web Apps in SharePoint 2013

As you know or will soon learn, Office Web Apps in SharePoint 2013 is no longer a service application that is part of your SharePoint farm.  Instead it is installed as a separate farm, which provides a number of advantages, such as reuse between multiple SharePoint and Exchange farms, a separate patching schedule, etc.  It can be a little confusing at first though, to figure out how to connect an Office Web Apps farm to a SharePoint farm.  What follows here are the installation pre-requisites for Office Web Apps and information about how to connect these farms together.

Prerequisites

 

Office Web Apps does not have a prerequisites installer like SharePoint 2013 does so you may need to install these components separately before you starting installing.

 

  1. Install PowerShell 3.0 (RC1 is the latest version at this time: http://www.microsoft.com/en-us/download/details.aspx?Id=29939)
  2. Install .NET 4.5 (RC is the latest version at this time: http://www.microsoft.com/visualstudio/11/en-us/downloads#net-45). IMPORTANT: If the installer shuts down any of the .NET listeners during installation, you MUST reboot the server prior to installing WAC. Otherwise you will find numerous errors about endpoint not found, not listening, or connection refused in the Office Web Apps application node in the Event Viewer and you will not be able to render any documents.
  3. Install this hotfix: http://www.microsoft.com/download/en/details.aspx?id=27928

 

UPDATE:  I wanted to update with some additional information on this for RTM and Windows Server 2012.  Part of the difficulty in providing this guidance before we ship is that things change.  Here’s the latest experiences when using RTM builds on Windows Server 2012:

  1. You don’t need to do any of the three steps above.
  2. You need to start PowerShell as an administrator.
  3. You need to add the WAC admin module as follows:  import-module “C:\Program Files\Microsoft Office Web Apps\AdminModule\OfficeWebApps\OfficeWebApps.psd1”

 

You will need to jump through a couple of hoops on Server 2012 to get all the pre-reqs in place.  You need to:

  1. Install the IIS, .NET 4.x, and the Ink and Handwriting Services (no idea why on that last one)
  2. After all that’s finished you have to go back add additional features to that service: 
    1. “ASP.NET 4.5” 
    2. “.NET Extensibility 4.5”
    3. “ISAPI Extensions”
    4. “ISAPI Filters”
    5. “Server Side Includes”

You can now install Office Web Apps.  Once it’s installed, you need to either create a new Office Web Apps farm, or join your server to an existing farm.  In this case I’m just going to describe how to create a new farm; to get the PowerShell to add a server to a farm just do a get-command *office* in PowerShell.  To create the farm do the following:

 

  1. Open PowerShell by going to Start…Run and typing powershell.
  2. To use HTTPS with WAC (recommended):
    1. Create an SSL certificate that will be used with the fully qualified domain name of the server; make note of the friendly name you use when you create the certificate. You should use IIS to request the certificate to ensure that it gets created in the correct certificate store.
    2. Provision the WAC farm with this PowerShell command: New-OfficeWebAppsFarm -Verbose -InternalUrl https://<machinename> -ExternalUrl https://<fully.qualified.machine.name> -CertificateName <FriendlyNameOfCertificateFromPreviousStep> -ClipartEnabled -TranslationEnable
  3. To use HTTP with WAC (not recommended):
    1. Provision the WAC farm on the WAC server with this PowerShell command: New-OfficeWebAppsFarm -Verbose -InternalURL http://<machinename> -ExternalUrl http://<fully.qualified.machine.name> -AllowHttp -ClipartEnabled –TranslationEnabled

 

Now that your Office Web Apps farm is up and running, you can connect your SharePoint farm.  To do that, login to any server in your SharePoint farm and open the SharePoint PowerShell command window.  Use the following command to connect to the Office Web Apps farm:

 

  1. To use HTTPS with WAC (recommended):
    1. Create the connection to WAC with this PowerShell command: New-SPWOPIBinding -ServerName <fully.qualified.machine.name of WAC server>
  2. To use HTTP with WAC (not recommended; Note – will not work if you did not configure Office Web Apps to support HTTP):
    1. Create the connection from the SharePoint farm to the WAC farm with this PowerShell command: New-SPWOPIBinding -ServerName <NameOfWacServer> -AllowHTTP
    2. Run the following command on the SharePoint server (note there’s no “s” at the end): Set-SPWopiZone internal-http

 

Generally speaking, you should configure Office Web Apps to use HTTPS. The reason for that is that you can only have one WopiZone binding per SharePoint farm, HTTP or HTTPS. If you ever have both HTTP and HTTPS web apps zones, you will need Office Web Apps to be HTTPS. If it’s HTTP only, you will get mixed content warnings when you are in an HTTPS site and you try and render HTTP Office Web Apps. However if you try to render HTTPS Office Web Apps in an HTTP web app zone you will not get any warnings. In addition, since the access token is passed between SharePoint and the Office Web Apps servers it is safer to have the traffic encrypted with SSL so that it cannot be sniffed out and replayed.

UPDATE:  One final note worth making here.  When you create the New-SPWopiBinding to the web apps farm, it will use the server name you provide and expect it to be HTTPS.  That means if you say your ServerName is wac.foo.com, then it will try and contact it at https://wac.foo.com.  If you do not have an SSL certificate with a common name of wac.foo.com bound to the IIS server that the web apps is using, then the New-SPWopiBinding will fail and tell you that it can’t find the server.  There other thing to note is that THIS IS NOT NECESSARILY THE SERVER NAME SHAREPOINT WILL USE TO REQUEST WAC CONTENT!!  The server name it will use is actually contained in a discovery document on the web apps server.  If you navigate to https://wac.foo.com/hosting/discovery then you should get the XML document it uses, and it will show the names it is using for both the internal and external zone (web apps only have two zones, it is not like SharePoint). 

 

The reason I bring this up is because what I found is that after I run the New-SPWopiBinding cmdlet on SharePoint, by default it is setting the current WOPI zone as internal-https.  However, I use a fully qualified domain name for my WAC endpoint.  So instead of SharePoint requesting web apps at https://wac.foo.com, it makes the request to https://wac.  The problem then is that your SSL certificate on the web apps servers does not match the request coming from SharePoint, so you will get a random and varying assortment of errors.  The solution to this is to change your WOPI zone in SharePoint with the Set-SPWopiZone cmdlet, i.e. Set-SPWopiZone external-https.  That will make SharePoint use the external name in the discovery document, which should be https://wac.foo.com.  Many thanks to Yanlin for helping me track this down!