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.
Earlier today I ran across a strange installation problem and I wanted to share my findings...
The core scenario was about as generic as they come for a single-server farm.
Base line scenario:
Windows 8 with Hyper-V
Windows 2012 Standard guest
SQL 2012 Standard
The deployment plan was straightforward. Use Windows deployment services to provision out a new server, then install SQL, then install the SharePoint prerequisites, then roll out SP and provision. It should have been super fast and easy.
Well, as we all know, SharePoint always tries to makes life interesting.
Installation failed with a super descriptive error:
"SharePoint Server 2013 encountered an error during setup"
Time to dive into the logs... They pretty much told me nothing at first. The logs reported
"Error: Failed to install product: C:\<installFolder>\global\oserver.MSI ErrorCode: 1603(0x643)"
Definitely a better message, but it didn't quite help either.
Time to rollback to the snapshot taken after the prereq's were installed. Try again. Fail.
The piece the really helped was the Windows error reporting information that was available after dismissing the SharePoint installation dialog.
Error code FC73469E lead me to an insightful post. Sure enough, the VM preparation steps omitted the proper CPU count.
Roll back to the prereq snapshot, up the CPU count, take another snapshot. Install. #FailAgain
Same error. Same log entries. No progress...
Further research showed that others had also documented this problem and some were pointing at a MSI hack left as a comment on a msdn blog post. Maybe I'm old fashioned but msi hacks ain't right.
Looked over the logs, checked permissions, checked the sql installation, changed install accounts, move the install media to a new location, checked the software prereqs ... reviewed the prereq logs... lots of installs failed.
Then it dawned on me that all my attempts to resolve the problem started from the same base configuration - I used the prerequisiteinstaller on the image that had the wrong CPU count. I had "corrected" the CPU problem by changing the VM with the prereqs, then using that snapshot as the base.
The next and last test was rolling back to a clean server, updating the CPU count and *then* installing the prerequisites.
Net net: The prerequisiteinstaller recorded information about the wrong CPU state, which then forced the installer to choke. No msi hacks were necessary (yeah!), only a clean *proper* vm state.
I should have reverted to a clean state once I determined the core state had been compromised. Instead, I "cheated" by going back to a snapshot that incorporated the "faulty" prereq's ... and that in the long run cost me a lot of time.
Over here in the skunk works division of our company... we've been busy the past few months working on some prototypes that will allow us to integrate physical data with the usefulness of SharePoint.
We're unveiling a portion of our efforts at the SharePoint Evolutions Conference 2013 in London next week. You've heard me say this before - this conference rocks. I love this conference for many reasons but the one reason that sticks out in my mind is the simple fact that I spend a lot time creating new content. This year was no different! The fact we got to use soldering irons to put a demo together made this the most exciting presentation build...
If you are attending the conference next week, swing by my session and check out the evolution of business data collection and management...
Title: Remote monitoring with SharePoint 2013 and making it smart!
Session: COM710 from 1500-1600 in the Rutherford room
This should be a fun session with demos, hardware with blinky lights, and hopefully some good discussion!