I noticed a lot of 3rd party SharePoint applications require that Office be installed on the server in order to function - PDF converters, for example.
To me, this seems like a horrible idea. The overhead, update requirements, reboots, and footprint all combine to make this a bad idea. Am I wrong in my assumption?
Speaking as a vendor who provides a popular PDF Converter for SharePoint that requires Office to be installed on the server for some formats I'd like to add my 2 cents.
In the past when I was in charge of change control for a large financial institution I would have raised my eyebrows if any vendor required office to be installed on the server. Oh how I loved my fancy Ivory Tower.... the irony is not completely lost on me.
Fact is that sometimes we need to look at what the business requires, and if the business requires perfect fidelity when converting documents that use the latest and greatest office formats then you can't escape going down the route of installing Office on the server.
Now, plenty of people have tried and failed to make this stable, and sometimes even employing dedicated people that go around rebooting hung servers. The thing is, if you know what you are doing and deal with all the pitfalls, of which there are many, then it is actually possible to successfully and reliably use Office on the server in a way that scales well.
I don't want to make this into an elaborate sales pitch, but we have hundreds of (high profile) customers and I have yet to hear from a customer who had a crash, outage or any kind of downtime related to our software.
If you don't know what you are doing and just code up some COM automation with Office directly in your SharePoint app then you are bound to run into problems, but if you do your job well, run everything in a separate process, allow optional offloading to non SharePoint servers then there is nothing wrong from a technical perspective with running office on the Server.
When a vendor or supplier wants me to install client/bulky apps on a server, it lowers my opinion of their technical savvy and/or experience. I don't like it, but I'm used to it.
Sometimes I'm able to get ahead of things and learn about these little surprises before the purchase. It's up to me to make the case that we're going to have trouble down the road with a company that doesn't understand why a leased network printer should have a better method of volume tracking than buggy crapware installed on a server.
It's definitely a bad idea, but unless you're in a position to go with another supplier based on the unprofessionalism and sloppiness of this kind of requirement, it's nothing to lose much sleep over.
Programs that interact with Office often use the COM/Interop Interface, which is not supported on a Server:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
I can confirm that certain operations indeed deadlock the process (Printing out a Word Document on a Printer Driver that opens a Prompt caused me major headaches).
However, some applications only require office because of some component it brings with it and they may indeed run perfectly well.
But as said: If the Manufacturer of the Operating System and the Office Product says it's not supported, I'm inclined to believe them.
I agree it is an idea which sends shivers down my spine, but it is pretty standard practice with content management systems targetting Office document collaboration.
I have also found this practice on Linux with OpenOffice with Plone for example.
Now, when we look at it pragmatically, in many may use-cases is the sharepoint server not a realtime critical resource, and the company copes just fine with an occasional reboot. Especially in SME environments there are relatively few users so the loads generated will not bring the server to its knees. In these circumstances this is a pragmatic approach to get the automations people want.
You're absolutely right that it's a bad idea. But... At the end of the day this is what we do as system administrators though is it not? We have to balance the costs of making a change to our production servers against the cost of not making that change.
If the business must have a certain functionality on the Sharepoint install and this is the only way to get it then what else can you do really? Be clear about the risks and costs of doing the install in terms of resources and potential downtime for patching, etc. and see how it stacks up.
One thing that probably is reasonable is to find out exactly what office components are needed and do a minimalist install of just those components. There's a big difference between whacking the office disk into the server and just doing a "point and drool" quick install and saying "well it only needs, for example, word plus the foobaz plugin, so that's all I'll install"
The points the others have made about installing software on a server are good ones which I agree with. I would think servers should be used for serving and being used for their designated role.
If you don't want to install the full office suite there are small packages to allow you to view documents, powerpoints and so on. Look at Powerpoint Viewer or Word Viewer.
Another reason for Office-on-the-server is when it's a terminal server for thin clients :-)
