At the same time that SharePoint 2010 was released, the Office team released the Office Web Applications. These browser versions of Word, Excel, and PowerPoint were tightly integrated with SharePoint and in fact originally required SharePoint to run. To install them, you would stand up a SharePoint server, and then install the web application bits on that server. Like a service pack or CU, you would then run PSCONFIGUI to integrate the bits into the farm, and install the relevant service applications. Simple enough.
However, there were some quirks associated with them. As noted here, removing the web applications from the server would actually remove the server from the farm. Simple enough to correct, but if you uninstalled the SharePoint bits before uninstalling the Office Web Application bits, you could be left with an effectively inoperable server.
During the 2010 release lifetime however, we started to see the Office Web Applications pop up elsewhere. Initially powering Facebook’s docs.com, they could also be seen as part of Windows Live. Obviously, when Office 365 was released, they were front and center. With this increasingly broad adoption, and requirement for scale, a reliance on SharePoint as a platform made less and less sense, and now, for 2013, we get a new architecture.
Standalone Web Applications Server
The big change is that Office Web Applications is no longer reliant on SharePoint. It installs and configures independently and it can serve any number of clients, SharePoint being one, and Exchange being another. In fact, it’s now positively hostile to SharePoint and other servers – you can’t install it on a machine where the SharePoint bits are installed at all. The same goes for Exchange, Lync, SQL Server, or anything really. The following is from the TechNet document “Plan Office Web Apps Server Preview”:
Servers that run Office Web Apps Server Preview must not run any other server application. This includes Exchange Server, SharePoint Server, Lync Server, and SQL Server. If you have hardware constraints, you can run Office Web Apps Server Preview in a virtual machine instance on one of these servers.
Do not install any version of Office. You must uninstall Office before you install Office Web Apps Server Preview.
The Office Web Application Server really doesn’t play well with others. It pretty well demands that it is installed in isolation from other servers, which in reality means that a small SharePoint farm will consist of 3 servers – one SharePoint front end server, one SQL server, and one Office Web Applications server, and while virtualization makes this much more palatable, it may be a bit much for some smaller organizations to swallow.
Setting It Up
The official (pre-release) document on planning and deploying the Office Web Application server can be found here and here respectively. Originally, I had planned on putting together a step by step walkthrough, but Steve Peschka from Microsoft published this article today that does precisely that.
Steve’s article is great because it describes the process of setting up the server with both http and https. Http is fine if all traffic is internal, but if you will have any external traffic, you must set it up with SSL (if security matters at all to you..), and the server will support only one zone, you cannot use both http and https. As you would expect, setting it up for SSL is more complex than for http.
All of the setup is done with Powershell. Powershell is fantastic, and highly useful, but I don’t think that anyone would claim that it’s easy to get started with, especially for small farm administrators,
I think that it can safely be concluded that it’s significantly harder to get the Office Web Applications installed with 2013 than it was with 2010.
Takeaways
Anyone running a two server SharePoint farm with the Office Web Applications on 2010 will wind up with a three server farm after upgrading to SharePoint 2013. This can be done via virtualization, or by standing up another physical box. Depending on the workload, the Office Web Application server doesn’t need to be particularly powerful, but no matter what, it introduces an added level of complexity. For those that heavily leverage the server, that’s a good trade-off, but for others, perhaps not.
The Office Web Applications are a fantastic set of tools, and they have been significantly improved in 2013. I am however concerned that the lack of a smooth architectural transition path from 2010 combined with the lack of a simple setup process may keep some (smaller) organizations away from it. Of course, those organizations will also have the option of moving to Office 365 where these services will already be set up and running.
Something tells me that this may just be the point.