6

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?

Kolten
  • 163
  • 5
  • Microsoft advertises SharePoint to be especially designed to work well with MS Office, so I think if you use SharePoint it's not a bad idea to install Office. And because of that, I wouldn't be surprised that a lot of 3rd party SharePoint apps rely on Office being installed... –  Oct 13 '10 at 16:36
  • @xor_eq: SharePoint integrates with Office, true. But nowhere does Microsoft say or even recommend to install Office on a SharePoint server. – Michael Stum Oct 13 '10 at 21:02
  • 1
    Your logic sounds good to me. Personally, I would balk because of the additional patching required every cycle. – SilentW Oct 13 '10 at 22:14
  • 2
    One concern you've not mentioned is that the installation of Office opens yet more potential vulnerabilities, which to my mind is the most serious issue. – John Gardeniers Oct 13 '10 at 22:43

7 Answers7

8

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.

Jeroen Ritmeijer
  • 717
  • 1
  • 6
  • 14
7

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.

Kara Marfia
  • 7,892
  • 5
  • 32
  • 56
6

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.

Michael Stum
  • 4,010
  • 4
  • 35
  • 48
  • Thank you - I was looking for an official Microsoft statement on the matter, but couldn't find one. This is great. Reading it also confirms my assumptions that this should never, ever be done - for reasons I didn't even initially think about. – Kolten Oct 13 '10 at 22:10
  • 1
    That's a good point, and maybe something that you can take back to the prospective vendor and/or the business folks that need the component. However, there are those (myself among them) that believe IT is there to serve the needs of the business. If the business decides, after having been fully briefed of the risks and potential extra administration from the IT staff, that they want this anyway, you just have to work with that. – mfinni Oct 14 '10 at 17:17
  • 1
    @mfinni Of course, Business Needs are always above everything. I'm not a big fan of commercial solutions advocating this though, as the expectations of non-technical management people can be too high ("If it wouldn't work, they wouldn't sell stuff like this, would they? I think it's your fault"). That being said, I think that most big companies run on less-than-optimal and fragile solutions that break if you look at them in the wrong way, but otherwise do exactly what they need to do: Generate Value. Choose a Poison, but know both possible outcomes before :) – Michael Stum Oct 14 '10 at 17:31
3

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.

Peter Tillemans
  • 1,246
  • 1
  • 9
  • 7
  • We are a very large organization, and have approximately 2,000 concurrent clients hitting our SharePoint farm at any given time. Downtime is strictly regulated and planned via change management. – Kolten Oct 13 '10 at 16:54
  • Well, that was not exactly the use case I had in mind ;-). I hope you have a very big farm and benchmark/estimate the impact on the capacity plan. – Peter Tillemans Oct 13 '10 at 16:59
  • 1
    What overhead - disk space? The update requirements just mean that you have more updates to do, based on likely risk. The office updates still come out on Patch Tuesday, so there's no change to your existing process - assuming you patch your OS today. You just have an expanded footprint of things that you have to keep patched. Actual reboots required for Office updates, I'm sure, are less frequent than reboots for Windows updates. And what do you mean by "footprint"? – mfinni Oct 13 '10 at 16:59
  • Footprint meaning changes to the registry, software taking up memory, etc. So from the responses I'm getting this is common practice and I shouldn't be too worried? I expected the exact opposite to be quite honest - I have always thought installing client apps on a server was a bad idea?! – Kolten Oct 13 '10 at 17:05
  • Client apps on a server is indeed very problematic. Slow, unreliable, lock up at various times, unpredictable memory consumption and increased likelihood of virus infections to start with. Support and maintenance nightmare. That being said, I have seen it and know many people just put up with it in small and medium sized enterprises. – Peter Tillemans Oct 13 '10 at 17:13
  • 2
    @Peter Tillemans: In my opinion, you're spouting blanket generalizations that aren't applicable to every scenario or situation. Should you install Office on your file server, probably not. Should you install Office on a Sharepoint server if it's needed for some specific Sharepoint functionallity, yes you should. – joeqwerty Oct 13 '10 at 17:26
  • @joeqwerty: I agree, exactly my point. – Peter Tillemans Oct 13 '10 at 17:30
  • @kolten - if by "footprint" you meant "changes to the registry", well, why is that a problem? Software installers handle their own changes to the registry. "Software taking up memory?" You're installing software to do something, in this case it's a requirement for what you want Sharepoint to do. It's like complaining about IIS using CPU, on a webserver. In this instance, Office isn't "client software", it's "server software" because a server is using it to automate something. – mfinni Oct 13 '10 at 19:50
  • Yes, but its not like its server software. I'd have no issues evaluating a dll that does something as opposed to an entire office suite. You talk like this is server software - it isn't. Its meant to be used by a client directly on the machine, not called by a 3rd party application. There is a difference, most notably the amount of memory it takes up as well as changes to the registry, which thru reading it seems might interfere with Exchange server (not that i have exchange on the same box - just illustrates my point). I guess next step might be to see what exactly the minimum req's are. – Kolten Oct 13 '10 at 20:30
3

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"

Rob Moir
  • 31,664
  • 6
  • 58
  • 86
0

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.

tombull89
  • 2,958
  • 8
  • 39
  • 52
  • Viewing of documents isn't really the issue here. While I appreciate the response, my issue is to do with 3rd party components requiring Office to be installed on the server do perform thier specific functions. – Kolten Oct 13 '10 at 21:30
0

Another reason for Office-on-the-server is when it's a terminal server for thin clients :-)

DutchUncle
  • 1,265
  • 8
  • 16