80070005 Access is denied error while accessing Word Interop from the Server in a ASP.NET Application - How to fix

80070005 Access is denied error while accessing Word Interop from the Server in a ASP.NET Application - How to fix

Last week I published a couple post regarding the use of the Microsoft.Office.Interop.Word namespace within an ASP.NET C# Application, respectively about opening a DOC or DOCX file from a Byte Array and converting them to PDF files. Although these techniques can be very useful to deal with MS Word documents, they have more than a couple drawbacks that we should always take into consideration when using them:

  • They are often painfully slow and inefficient, especially when dealing with huge amount of files (batch processing).
  • They consume a massive amount of memory - considering the task given to them.
  • They have a terrible multi-thread support, to the point that they might lead to scale/concurrency issues.
  • They do require MS Office installed where we use them.
  • They do require an awful set of permissions to allow the IIS users to access the required DCOM components the IIS.

I'm not saying we shouldn't use them: as a matter of fact we kinda have to, unless we want to donate a kidney to some commercial libraries that can handle these tasks in a much better way. At the same time, we should get ready to experience some issues because they will create some havoc here and there sooner or later.

In this post we'll be talking about the following error, which you will often see right after publishing your web application to your IIS-enabled Windows Server:

Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

As you might easily guess, this is a permissions issue related to the usage of these DCOM components we talked about earlier: let's see what we can do about it.

The first thing we should do is to acknowledge the problem. You most likely already know that the permissions given to the IUSR and IIS_IUSRS accounts - those used by IIS to serve their web applications - are very different between your development machine and a real Web Server machine: this is exactly what's been happening there. The same Interop.Word methods that flawlessly work on your PC won't perform well on a real server right out of the box. In order to make them work we need to properly configure the access permissions and launch permissions of the required DCOM components.

Here's how we can do that:

  • Login to the Server Machine and open a command-line prompt.
  • Write
    DCOMCNFG and hit Enter: a modal window will appear.
  • Navigate through Component Services > Computers > My Computer -> DCOM Config
  • Open the node and look for an entry named Microsoft Word (something), such as Microsoft Word 97 - 2003 Document.
  • Right-click on it and select Properties.
  • Select the Security tab and give launch permissions and access permissions to the  IUSR and IIS_IUSRS account (to do that, select the Customize options using the radio-buttons, then click Edit).
  • Select the Identity tab and change the selected radio-button from The launching user (the default) to The interactive user.
  • Click Apply to confirm the changes, then - without closing the modal window - restart your web application and try again.
  • If the issue goes away, close the modal window: you're done! If you still get it, go back to the General tab, locate the Authentication Level drop down list and choose None.

That's about it.

Wait a minute: what if there is no Microsoft Word (something) entry in the DCOM components list?

If you experience this, it most likely means that you either don't have MS Word installed on the server machine or you have installed a 32-bit version within a 64-bit environment. You can fix the former case by installing MS Word, otherwise you're doomed. If it's the latter, you hit a known bug of most Windows-based machines: the DCOM configuration manager only shows the 64-bit DCOM components. Luckily enough, you can still execute the 32-bit version by using the following command-line instruction:

Repeat the above guide using this command instead of

DCOMCNFG

and you should be good to go.

If this still doesn't work, we strongly suggest to take a look to this Technet blog post which explains a number of other possible workarounds for this specific issue.

 

About Ryan

IT Project Manager, Web Interface Architect and Lead Developer for many high-traffic web sites & services hosted in Italy and Europe. Since 2010 it's also a lead designer for many App and games for Android, iOS and Windows Phone mobile devices for a number of italian companies. Microsoft MVP for Development Technologies since 2018.

View all posts by Ryan

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.