Office Automation and IIS

Every once in a while, I see users asking about how to automate Office applications on the server, either to create a Word document, an Excel spreadsheet, or Powerpoint slidedeck. I understand the noble intentions to re-leverage the functionality of Office and make it web accessible to many simultaneous clients/co-workers. However, there are many caveats to this approach, including the fact that Office is meant to run Interactively and not meant to be simultaneously used...



I have a ASP.NET 2.0 application that is creating powerpoint documents on the fly using powerpoint com objects that are installed on the server.  I am having some issues with security

It is currently working, but the website is running as administrator and I would like to tighten up those permissions.

The website is a stand alone site. I created its own AppPool called PowerpointAppPool

The website is loaded into that pool. If I set the identity to my own personal Administrator Account everything works fine.

What I tried to do:

1. I created a Domain User account called PPT ACCESS
2. I set the Identity on the PowerpointAppPool to PPT ACCESS with the password i set
3. then I went to AdminTools->Component Services->DCOM Config and set the PPT ACCESS user to full launch/access/config privilidges on Microsoft Powerpoint Presentation

I thought that would do it, but no good.

1. Is this what I should be doing?
2. Is there another service in DCOM that needs to be enabled (eg. a global MS Office App)?
3. Is there a way to debug where the access failure is coming from?


Unfortunately, your questions actually have little to do with IIS/ASP.Net and everything to do with Office Automation. Specifically, you are asking about using Office Automation interface as an automated server-side application instead of end-user client-side automation.

I suggest first researching the permissions (DCOMCNFG) and privileges (secpol.msc) needed by the Office Automation COM objects, and then make sure that the user account executing code on your behalf on IIS has those permissions.

  • This blog entry describes how IIS and ASP.Net determine the user identity used to execute code on your behalf. You must tune privileges and related ACLs to this user identity. You also need to remember that depending on the authentication protocol and server configuration, you may not be able to use that user identity to hop off the server as a remote-authenticated user for security reasons - while an interactive user would not have such a "double-hop" restriction.
  • KB 257757 does a great job laying out the general problem of Office Automation and common issues. For example, it points out that Office has major problems when running with a user token that does NOT have the Interactive SID. For security reasons, IIS6 creates all user tokens WITHOUT the Interactive SID. Unfortunately, there is no way to get IIS6 to create user tokens with the Interactive SID, and there is no way to make Office work without the Interactive SID... so YMMV.

Now, before you naysayers snicker about how Microsoft is "not making its software work better together", I suggest you take a reality pill. Office is a UI application designed for single end-user Interactive use. Meanwhile, IIS and ASP.Net are server-side platforms designed for multi-user remote access. The two environments are about as polar as it gets. One should be amazed that the two cooperate to automate at all.

At this point, I can only wish you good luck on this endeavor to reduce the necessary privileges to execute Office Automation Objects.


Comments (4)

  1. jvierra says:

    This question has come up over-and-over for years. Thnkyou for clarifying it loudly from a very hard to argue with perspective.

    See my additions here to why and what can or might be done to be able to use Office from the web.

  2. David.Wang says:

    jvierra – Thanks…

    Yeah, Office Automation is right up there with:

    1. writing VB COM components for use in ASP pages

    2. using Access/JET as the database for use in ASP pages

    When it comes to practicality.

    I understand that Office Automation, VB COM components, and Access MDB databases are easy to create and use, and it is tempting to try and scale the desktop solution to co-workers/clients by simply bringing it to the web… but what users fail to understand is that those technologies are all ultimately designed for Single end-user Interactive use on a desktop and NOT multi-user remote access on a web page.

    And when you try to shoehorn a desktop application onto the web and beyond its initial design, all sorts of bad things like hangs, crashes, slow performance, high lock contention, etc can occur. And no matter how much users complain, Microsoft can only provide a few hacks and recommend that you "use the right technology designed for the right problem".

    XML, SQL, Script Components, and ASP.Net are the way to go to write scalable, multi-user, remote-access web applications…


  3. Mark Jenner says:

    It seems to me that wanting to have a web app be able to process and/or produce Word and Excel documents is an extremely basic and common requirement with very wide utility.  There is nothing inherently "interactive" about reading or writing an Excel spreadsheet… it is simply a file format that should be able to be easily processed in a non-interactive environment.

    The fact that Microsoft products are unable to provide this functionality is only an indication of inadequate design on the part of Microsoft.  They simply inextricably coupled the disparate functions of document processing and creation on one side with the interactive applications with which these functions are typically carried out by desktop users on the other.

    Microsoft, in the person of Mr. Wang, instead of aknowledging this design flaw and working to address it, blames the customer for wanting this functionality.  A 100% legitimate and useful customer requirement is invalidated as being "outside of reality".

    Microsoft may view "reality" as "anything Microsoft can do".  Well, the users know otherwise.

  4. David.Wang says:

    Mark – I’m not certain where you are coming from. This is my point —

    Microsoft Office has on object model that can be perfectly used from a Web App to process/produce Word/Excel documents. People do this all the time in non-interactive manner for Office-related automation.

    The problem is whether the function can be non-interactively accessed in a single-threaded or multi-threaded manner and its performance/reliability — specifically, for web-access. This actually reduces down to a classic problem with a class solution that is hardly an "Microsoft reality". Almost all developers would choose the same tradeoffs given the information at the time.

    Let’s look it this way — 99.9999% of Office users run it interactively with no requirement of multi-threaded access (which is additional software complexity, which translates into added cost and longer/riskier ship date). You can certainly make an academic argument that non-interactive, multi-threaded access to Office is a 100% legitimate and useful customer requirement, but when you weigh the $100 billion worth of the 99.9999% Office users vs the $10 million worth of non-interactive, multi-threaded access, what would you choose?

    I am sure that you will choose to delay Office release at the cost of $10 million/day to add a feature/design worth only $10 million over its lifetime.

    This is the reality of software development which few people know nor understand.


Skip to main content