Freigeben über

Office Automation and IIS

  • Artikel

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...

Question:

everyone,

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?

Answer:

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.

//David

Comments

  • Anonymous
    May 12, 2006
    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.

    http://tech-comments.blogspot.com/2006/05/support-for-office-document-creation.html#links

  • Anonymous
    May 12, 2006
    The comment has been removed
  • Anonymous
    December 20, 2007
    The comment has been removed
  • Anonymous
    December 20, 2007
    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. //David