At Aptillon we work on all types of SharePoint environments from SharePoint 2007 to SharePoint 2016, On-Premises, Cloud and Hybrid, and when it comes to on-premises deployments, we have all sorts of configurations that we have worked with including self-hosted and IaaS deployments using services such as Microsoft Azure. Being responsible for so many different environments and configurations means that it is critical to not only pay attention to obscure Microsoft KB articles but to also analyze them with great scrutiny to be certain that we understand the impact to our various clients. Recently our team noticed some very interesting language in the Azure-based KB article, Microsoft server software support for Microsoft Azure virtual machines: https://support.microsoft.com/en-us/kb/2721672.
At first glance this article doesn’t seem all that interesting from a SharePoint point of view, until, that is, you get to the section that outlines Office Web Apps Server. We have highlighted the interesting text…
Microsoft Office Web Apps Server
Running Office Web Apps Server on Azure is supported but has some licensing limitations. For example, editing a document by using Office Web App is not permitted.
According to this statement you can run Office Web Apps Service in read-only mode on an Azure VM but you cannot use it to edit a document. This puts a very severe limit on the server’s functionality and seems counter to what has been implied by numerous blog posts from Microsoft employees and, more importantly, from what we have been told, through our clients, by various Microsoft licensing representatives.
To get some clarification we reached out to our trusted Microsoft contacts. The responses from them were very much unexpected - per the current licensing structure for Office Web Apps, no one is allowed to install Office Web Apps on Azure VMs, period. Therefore, the KB article is inaccurate in that it allows for a read-only deployment, and as such should be ignored.
Digging into this matter, we learned that the crux of this issue seems to be the legal definition of hardware ownership within the end-user license agreement (EULA). The EULA for Microsoft Office Web Apps Server states the following:
“You may run any number of instances of the server software in any number of physical and virtual operating system environments on your servers.”
Note the highlighted word, “your” – this is critical in terms of how Microsoft interprets the EULA and implies ownership. From our point of view, “your servers” is at best ambiguous because it doesn’t necessarily imply ownership. If you pay for hosted servers in Azure, are they “your servers”? Probably easy to argue no in this case, but what if you lease servers from a hardware vendor like Dell or maybe you have a dedicated hosting plan at a company like Rackspace? Are they your servers? According to our multiple Microsoft contacts, when asked about these scenarios, the answer was always an emphatic “No” - since you do not own the physical hardware they are not your servers and therefore you cannot deploy Office Web Apps in any capacity on those servers.
What has been an interesting complication for us is that we have had a couple clients recently go through a licensing true up review with their Microsoft licensing representative and as part of that review the representative okayed running Office Web Apps Server in an Azure environment.
As a result of all of this we are left in a place where various Microsoft sources seem to be at odds with each other. What is clear is that a KB article is not a legally binding document so it really doesn’t matter what is stated in the aforementioned KB article. The agreed upon EULA and how it is interpreted appears to be the key to determining what is and is not allowed with Office Web Apps Server. It is clear from our contacts in Microsoft that they strongly believe the EULA does NOT allow use on servers where the client does not own the physical hardware and despite our personal interpretation of the legalese it really all comes down to how Microsoft interprets it.
This is more interesting when you consider deployments outside of Azure VMs. As previously noted, it would seem that Amazon VMs, Rackspace servers, and leased hardware all fall into the same category of physical hardware not owned by the client.
It’s important to call out that there is no technical reason why you can’t use Office Web Apps Server on a service-hosted virtual machine. This is a limitation by legal definition only. We have seen many clients run Office Web App Server on hosted machines without any technical issues.
So where does that leave us? Our contacts suggested that a new KB article might come out soon, but again, a KB article is not a legal agreement. Aptillon is advising all of our clients to contact their Microsoft licensing specialist to discuss the potential issue to ensure they are in compliance with the licensing agreements and hopefully, if enough people complain, we can collectively get the EULA changed. So if you find yourself in this predicament we encourage you to let your voice be heard – tell Microsoft that such restrictive wording in the EULA makes it impractical for most companies that do not outright purchase their own hardware. Explain to them that it’s generally not economical to purchase hardware – leasing, and IaaS options are the new norm and have been for a long time.
Update: 3/17/2016 - Rackspace’s Todd Klindt contacted Aptillon to provide us with this quote - “We confirmed with Microsoft that partner owned, customer dedicated gear is ok for licensing OWA/OOS, so we’re good.” This further demonstrates that, as we noted above, there are a lot of different pieces of information pointing to different conclusions. So again, your best bet is going be that you make sure to ask your licensing representative whether you are legal and get something in writing, as Rackspace has done.
I wrote a quick little utility to make it slightly easier to work with results coming back from a REST call to the SharePoint 2013 search endpoint. Details available here: http://blog.mannsoftware.com/?p=2031
Source code available on GitHub: https://github.com/Sector43/SPRestSearchParser
Like it? Made some improvements? Please submit a Pull Request so everyone can take advantage of your improvements.
Mostly notes for myself, but a quick write-up on configuring VS Code to work the way I need it to. Provides some details on:
- Configure Git, including credential caching for GitHib
- Configuring Karma
- Configuring TypeScript support
Details are available here: http://blog.mannsoftware.com/?p=1951