Print | posted on Monday, July 30, 2012 3:50 AM
As you maybe aware there are a veritable ton of cool new capabilities in the latest release of Office Web Apps Preview. It really is a killer piece of tech. This post walks you through how to configure Office Web Apps editing in your SharePoint farm, which is not as “automatic” as you may imagine. We’ll also take a look at an interesting new capability in SharePoint 2013 Preview for license enforcement.
Please note that this article applies to the Office Web Apps Server and SharePoint 2013 Preview release. Things are likely to change between now and the final releases. I will update this article shortly after RTM.
Some background on Office Web Apps Server Preview
With this release Office Web Apps (OWA) is no longer a set of SharePoint Service Applications, and the deployment of a separate OWA farm is necessary. This is a good thing! Despite the need for “more” servers than before, it allows OWA to provide it’s services to things other than SharePoint, avoids the common pitfall of resource scrimping deployment and fundamentally allows OWA to be revved independently from SharePoint. Take a look at task manager from a newly minted OWA server which has just been booted and is not responding to any requests:
The highlighted processes are all OWA related (with a couple more below the second image). Probably not a good idea to have all that running alongside SharePoint and it’s Velocity and NodeRunner gubbins!
So we need a OWA farm. OWA installation will be blocked if SharePoint is already installed. It’s no big shakes, we need a few prerequisites installed (including the Ink and Handwriting Support Windows Feature if we are using the same base image as we do for a SharePoint box). Once we’ve installed the bits, we run a Windows PowerShell cmdlet (New-OfficeWebAppsFarm) to create the OWA farm. Then we configure a connection between the SharePoint Farm and the OWA Farm using the New-SPWOPIBinding cmdlet and the Set-SPWopiZone cmdlet. Head on over to Steve’s blog for the details of this stuff.
Also check out my buddy Ali’s post on leveraging Microsoft Translation Services with OWA.
Viewing in Browser from SharePoint Server 2013 Preview
Great. So far so good. As this point we can now use OWA from our SharePoint sites to open files in the browser by choosing View In Browser from the item’s context menu. Also note the uber cool preview provided.
It’s worth noting there is no longer any Site Collection scoped feature for this stuff as in SharePoint 2010 with OWA. We still have the library options to control the defaults for a library and the Site Collection scoped feature for opening documents in the client apps.
As you would expect when we click the View in Browser option, OWA opens the file in view mode.
Awesomeness. But as cool as it is, we want to be able to edit that sucker. The only menu we see is OPEN IN EXCEL. We want to see the EDIT menu, and also be able to choose the Edit in Browser context menu option. And yes, those really are all caps menus!
If we try and open up a file in Edit mode, we will see a dialog similar to the below:
Enabling Edit in Browser
In order to allow editing we need to configure our OWA Farm to allow editing. This is a simple additional configuration step in Windows PowerShell. We could also have added this switch to the initial command when we created the OWA farm.
Set-OfficeWebAppsFarm -EditingEnabled
Easy peasy, lemon squeezy. Now we can go ahead and use the edit mode and also the EDIT DOCUMENT menu item is available when viewing.
However, what if we want to allow editing via OWA to only a distinct set of users?
SharePoint Licensing to the rescue!
Which brings us to a new capability in SharePoint Server 2013 Preview named Licensing. All you all thought I was about to start on a rant about licensing SKUs and cost and what not!
As you are probably aware for many years now it is an incredibly common customer request to be able to deploy a single SharePoint farm but have only a certain group of users be able to access Enterprise features. Thus saving money (at least until the deployment is widely adopted) on those premium Enterprise CALs. The only way to do it properly from the technical side was to deploy two separate farms (one Standard and one Enterprise) which from a collaboration point of view sucked!
In SharePoint 2013 Preview, administrators can now assign licenses to users and enable license checks. W00t! These checks are effectively enabled by leveraging claims. The canonical example here of course is by using an AD Security Group.
Once again this new capability has no user interface whatsoever and it’s all configured and managed by Windows PowerShell cmdlets.
Unsurprisingly OWA also can leverage the SharePoint Licensing capability. SharePoint is “aware” of OWA (and Project Server) and it includes these in the set of licenses. We can check this out by executing the following Windows PowerShell which will list the license types.
Get-SPUserLicense
License
-------
Enterprise
Standard
Project
OfficeWebAppsEdit
The one we are interested in of course is OfficeWebAppsEdit. Let’s go ahead and add (for the purposes of demonstration only) Domain Users to that license. The first thing we do is create a license mapping which connects the security group to the type of license. Then we add that mapping to the current configuration. Then we turn on Licensing (the capability is off by default).
# create a license mapping and add it to the current mappings. we could of course pipebind these together
$lmap = New-SPUserLicenseMapping -SecurityGroup "Domain Users" -License OfficeWebAppsEdit
$lmap | Add-SPUserLicenseMapping
# turn on licensing
Enable-SPUserLicensing
Note that if we use the –SecurityGroup parameter, the group’s existence is validated when we execute the cmdlet as is the license. We can also use the –Role parameter, or custom claim types and values.
We can also view the current license mappings.
Get-SPUserLicenseMapping
Identity : 6593aea1-efa8-4d1c-839b-13e5ae9e9f5a
License : OfficeWebAppsEdit
Name : Domain Users
ClaimValue : S-1-5-21-3910503199-1739462322-41582061-513
ClaimType : http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
OriginalIssuer : Windows
ValueType : http://www.w3.org/2001/XMLSchema#string
Sweet, huh? License enforcement my means of user claims all automatically handled for us by SharePoint 2013. All of this is a another very good reason why you want to use SSL for the WOPI Binding.
s.