I’ve recently been involved in a somewhat unusual client engagement, in that I was designing and delivering the infrastructure without knowing the shape of the IA or solution architecture. Obviously, this imposed some restrictions on what we could define, but it also meant that I had to handle some aspects of the engagement that would normally be taken care of by other colleagues. To that end, I suppose some of these considerations aren’t purely infrastructure-specific, but they could be in an engagement like this one and they’re things that infrastructure people should understand. Hopefully it’ll be useful for solutions people as well.
As you will have surmised from the title, we were deploying the Office Web Apps. In this case they were being installed with a new SharePoint Server 2010 Standard farm. This is a list of considerations that cropped up during the engagement and a few other bits I’ve picked up since RTM:
- WAN Acceleration: The Office Web Apps help performance over the WAN. This hadn’t occurred to me until I read the recently-released TechNet guidance on geographically-dispersed environments, but this all makes sense, because the documents load progressively. This is explained in more detail in the article. It’s worth keeping this in mind as an aid for global deployments and worth further taking note of the licensing concerns below if the Office Web Apps will be deployed for this reason.
-
Licensing: The Office Web Apps license model is based on the volume license for the Office 2010 client. These licenses are supplementary to any SharePoint license concerns, although you might choose to install both in the same farm. This Infoworld article explains it better than anything else I’ve read. The major implications of this are:
- Assuming this Infoworld article is right, and if the farm will be accessed by external users, they will not be covered by a SharePoint FIS license. All of those users will need to have an Office 2010 volume license (not a home license) in order to access these documents in the browser.
- This license could be provided by the consuming business or whoever, but it would need to be in place. How this would be monitored, what is and isn’t acceptable use and how licensing audits would work in this scenario are all issues that would need to be inspected in some detail with a licensing specialist.
- Presumably you could deploy a web application that’s disconnected from the Office Web Apps service applications in order to maintain compliance, but then you negate the WAN optimisation benefits mentioned above, and this clearly has broad IA implications. I’d also recommend confirming the legitimacy of this approach for compliance.
- On the other hand, internal users are covered by an Office 2010 volume license if it has been purchased, even if the software isn’t installed on their machines. You might find this is the case with enterprise agreements. This means internal users can start to take advantage of the Office Web Apps even if an Office 2010 upgrade is months or years in the future.
- Talk to a licensing specialist to confirm all of this as it pertains to your deployments, as there are surely other wrinkles I’m not covering and I’m basing this on an article written by a journalist rather than Microsoft or a licensing specialist. The only reason I’m referencing that article is that it’s the clearest explanation I can find.
- Assuming this Infoworld article is right, and if the farm will be accessed by external users, they will not be covered by a SharePoint FIS license. All of those users will need to have an Office 2010 volume license (not a home license) in order to access these documents in the browser.
- Install Media: Once you’ve got the licenses in place, you may have some trouble finding the install media. Even though the media is for 64-bit systems, it’s downloaded from 32-bit downloads on the volume license site.
- Caching: The Office Web Apps Cache is a site collection that should be moved to it’s own database for each web application (in most cases), as the default cache size is 100GB. One way or the other, it’s a different type of content and it makes sense not to clutter actual content databases with this cache data. There are probably different database backup/restore requirements as well. If the existence of this site collection is news to you, read those links above before going any further.
- Topology: Make sure to plan your topology for the Office Web Apps. You will be adding three new service applications and they will tax your system differently based on how they are used. This is a big topic and the planning guidance is fantastic, so I’ll merely point out the Estimate performance and capacity requirements for Office Web Apps document and leave it at that.
-
Database Permissions and Application Pools: The Office Web Apps have some quite unexpected database permission requirements. From the Deploy Office Web Apps TechNet guidance:
Note: You can choose to create a new application pool to be used with a service application. When creating a new application pool, you can specify the security account used by the application pool to be a predefined Network Service account, or you can specify a managed account. The account must have readwrite privileges for the SPContent database and SPConfig database. For more information about services account permissions in SharePoint, see Account permissions and security settings (SharePoint Server 2010).
This blows a few holes in the least-privileged model. In this case, we chose to create a new application pool for the Office Web Apps service applications and ran it under the farm account, since the permission requirements are so pervasive. This could be its own separate identity, but the important thing for me is that using the farm account for these services contains the extensive privileges more than granting these wider permissions to the Service Applications application pool would. One way or the other, we’re looking at a different application pool for security reasons. And if anyone’s curious if this is really necessary, it is. You will be unable to actually use the Office Web Apps without these database permissions in an otherwise-least-privileged configuration.
There are a number of other topics to consider before deploying the Office Web Apps, such as the default open behaviour, Office version requirements, browser support and other topics from the solutions world that I daren’t venture in to, but hopefully these infrastructure considerations won’t be overlooked when focusing on those issues.