In case you missed it, the Office team is in the process of releasing the RTM version of Office Online Server (OOS) to the public. Customers with a Volume Licensing account can download OOS from the Volume License Servicing Center, OOS will be available on MSDN beginning May 9th, 2016.
For most Exchange admins OOS as well as the previous versions of the same product, are a new technology. For a great overview of deploying Exchange 2016 with OOS I recommend to view the recording or at least the slides of the session that Michel de Rooij recently presented on this subject.
Unfortunately the documentation for OOS is not (yet) of the high standard we’re seeing with Exchange and some other products. In this post I want to highlight two topics as an example: sizing requirements and virtualization support.
Sizing your OOS servers
Maybe the comparison with Exchange is not the best example here, because Exchange 2010 was the last version where sizing documentation was of a very high quality. For recent versions of Exchange the guidance is shifting towards using the calculator to design your environment, instead of using the calculator to validate your design.
The guidance for OOS is even worse:
That’s odd, SharePoint 2016 is a very different application and the recommended production architecture is to spread the roles over multiple servers. SharePoint does know the Single-Server farm concept but this is recommended for development, testing or very limited production use. The SharePoint teams gives two sets of minimum requirements, one for development and one for pilot or user acceptance scenario’s:
We’re sizing our production OOS deployment so let’s pick the largest one: 4 CPU cores and 24 GB of memory. The assumption here is that the Office team had the SharePoint Single-Server deployment in mind when they referred to SharePoint sizing for OOS.
But wait, there is another authoritative source: the Exchange team! In the Exchange 2016 Preferred Architecture is a short section dedicated to designing your OOS servers.
So without asking any questions about the number of users, % of OotW usage or whether we need view-only or editing capabilities we’re now at 8 CPU cores and 32 GB of memory, times two per datacenter of course because the PA assumes HA. Please note that the SharePoint team recommends to use at least double of your memory as the free disk space, so that would make 64 GB instead of 40.
With the current lack of real-world performance figures it probably would make sense to start with a relatively small server, monitor your deployment carefully and add resources if necessary. Which brings me to my next point.
Virtualization
Just as every other modern application OOS supports deployment in a virtualized environment, giving customers the choice and flexibility to deploy OOS on their own terms.
The first bullet is probably good advice for performance and manageability reasons, the second bullet is basic common sense. The interesting part is hidden in the first paragraph:
…is supported when you deploy it using Windows Server Hyper-V technology…
Is Microsoft really saying that you’re allowed to deploy OOS on Hyper-V but not on VMware, Xen, KVM or any other hypervisor solution that is certified through the Windows Server Virtualization Validation Program (SVVP)? Yes they are, but this has to be a mistake. I cannot think of any valid reason behind this statement.
But wait, there is more…
While researching this subject I noticed several other interesting or questionable statements in the OOS documentation on TechNet. To name a few:
The Office team recommends SSL offloading, that means that the load balancer would be the endpoint for the SSL tunnel and that all traffic between the load balancer and the real servers will be unencrypted. This goes against the security principle of treating both external as well as internal networks as unsafe by default. It’s considered best practice to deploy SSL bridging instead. The Office team acknowledges this and recommends to mitigate the risks involved by recommending the use of firewalls and private subnets to secure the traffic.
The load balancing section mentions a requirement for layer 7 routing and client affinity but lacks any recommendations on what affinity options to choose and does not mention how to configure the load balancer’s health checks. In practice we see that a lack on guidance in this area generally leads to bad implementations.
In conclusion
I could go on for a while, but I won’t. I recommend every Exchange organization considering OOS with Exchange 2016 to perform a cost-benefit analysis to start with, for instance if 95% of the users will use non-OotW clients to access Exchange 2016 mailboxes an OOS deployment maybe doesn’t make sense. And there is of course the licensing aspect, as editing capabilities are not free and are coupled to Office suit licensing.
I you are planning your OOS deployment with Exchange 2016, make sure to contact your Microsoft representative to confirm that OOS on your hypervisor will be supported. From a sizing perspective, start with a small VM and add resources when necessary. And make sure to keep an eye on the Twitter an Blog-o-sphere for more updates on this subject.
