Can I run Excel 2010 on a server?

This question is not about a person using Excel on a computer that happens to have an Windows Server OS. And it is not about using any Sharepoint services features!

The question is about automated processes that use code (Office Automation) to open Excel files, manipulate them, run calculations, read data, save copies of the file and close the files... all in code.

In previous versions of Excel the licensing agreement prevented use on a public server, notes from Microsoft warned about the problems trying to use Office Automation in a server environment, and we were warned that Excel was single threaded and not designed for use on a server.

Most of the articles about this were written before Office 2010.

But now, Excel 2010 is designed to work on a High Performance Computing server using HPC Services for Excel. One HPC document mentions "Windows HPC Server 2008 R2 includes a comprehensive pop-up manager that can handle occasional dialog boxes and pop-up messages".

So my question is... is it now "safe" to run code that automates Excel 2010 on a "normal" server without using the HPC services?

If not, can the HPC Services for Excel work on a single server?

I don't need the high performance, distributed computing, aspect of HPC Services for Excel... just the ability to run Excel on a server.

Can that now be done?

Thanks, Glen

Solution 1:

Your question boils down to "can I use Excel automation APIs safely?" and has little to do with server specifics. Of course, Excel does run on Windows Server platforms and it even is a rather common scenario in Terminal Server environments, but typically it is run interactively by the respective users. It has always been safe to run it this way (i.e. older versions were put on Terminal Servers as well).

That being said, KB257757 which has been last revised on July 2nd, 2010 and with the "applies to" section explicitly listing "Microsoft Excel 2010" , states:

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.

specifically on the licensing issue:

Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office.

and concludes with this in bold face:

Microsoft strongly recommends a number of alternatives that do not require Office to be installed server-side, and that can perform most common tasks more efficiently and more quickly than Automation. Before you involve Office as a server-side component in your project, consider alternatives.

I believe you can't have a statement more definite than this.