Office Interop DCOM Config on a Windows Server IIS Machine to open Word, Excel and Access files with ASP.NET C# How to setup DCOM Configuration Settings to use Office Interop Word, Excel, and Access with ASP.NET C# on a IIS Windows Server machine

IIS URL Rewrite: redirect di più nomi di dominio su un singolo hostname

If you’ve stumbled upon this post you’re most likely dealing with the Microsoft Office primary interop assemblies (PIAs), also known as Microsoft.Office.Interop library set. This is a neat collection of libraries, released by Microsoft through NuGet, which can be used to programmatically access – open, edit, save, create and so on – Microsoft Office files such as: xls / xlsx (Excel), doc / docx (Word), mdb (Access) and so on.

In case you also need a tutorial / coding sample about how to implement Microsoft.Office.Interop library set in a typical ASP.NET C# application, we suggest to read this post: here we’ll take for granted that you’ve already did something like that and you’re trying to publish it onto a production IIS server machine – arguably, without success.

The problem(s)

As soon as you install these assemblies in your developer machine you’ll be able to deal with the Office files without issues. However, when you’ll eventually want to publish your efforts in a production server (Windows Server + IIS), you might deal with one of the following errors:

System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

or:

System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access denied. (Eccezione da HRESULT: 0x80070005 (E_ACCESSDENIED))

or:

System.Runtime.InteropServices.COMException: The message filter indicated that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER))

or:

System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

or:

System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file

These are the most common errors you might encounter when dealing with Microsoft.Office.Interop: luckily enough, there’s a quick solution for each one of them.

The Fix(es)

Let’s start with the easy one.

80040154 Class not registered

If you’re hitting the 80040154 Class not registered error, it probably just means that Microsoft Office isn’t installed on your IIS server machine. Yeah, that’s about it! If you thought that you could avoid installing it, you were wrong: a locally-installed instance of Microsoft Office is required to use the Microsoft.Office.Interop libraries, because they basically launch the actual MS Office apps in background to handle the calls.

As a matter of fact, they also do that in an highly-inefficient way, often messing up with the multi-thread context of a typical Web Application – that’s why you should use  ,   or other similar methods to synchronize access to these kind of calls. We won’t expand such topic here any further, but you can see a sample lockers implementation / tutorial / code sample in this post.

80070005 Access denied

This error basically means that the web site is definitely finding the COM objects related to the MS Office application you want to execute, but the Application Pool in charge of the running process doesn’t have permissions to use them. In order to fix that, follow these steps:

  • Open IIS Manager > Application Pools and identify the identity assigned to the Application Pool assigned to the web application (it’s in the Advanced Properties tab). Keep a note of that user (or system) account, because you’ll need it later on. If you fond the ApplicationPoolIdentity there, you need to do some little extra-work: as you might know, that user it’s a dynamically created, unprivileged account: to change its permissions in the following steps, you’ll need to look-up for the IIS AppPool\[AppPoolName] role. If that’s too much for you to handle, you can change the identity to a “static” account… but you shouldn’t do that, as the ApplicationPoolIdentity usage is a best practice to deal with IIS7+ / IIS8+ Application Pools in a secure way. For additional info on that topic, read this StackOverflow thread.
  • Launch the   command from Windows > StartRun or from a command-prompt: go to Component Services > Computers > My Computer > DCOM Config, then locate the various “Microsoft XYZ Document” and/or “Microsoft XYZ Application” entries, where XYZ are Word, Excel and/or Access – depending on what you need to access programmatically from your ASP.NET web application: you’ll need to perform the following tasks for each one of them.
  • Right-click the entry and select Properties:
    • Go to the Identity tab, where you’ll see three radio buttons: The Interactive User, The Launching User and This User. Select This User, then put the credentials of the account who installed MS Office – or an administrative account.
    • Go to the Security tab, where you’ll find three group boxes: for the first two of them – Launch and Activation Permissions and Access Authorization –  select the Customize radio button, then add the same identity that runs your web site’s Application Pool – the one which you took note of few minutes ago. In some scenarios, depending on the Windows Server version, you’ll also need to add the IUSR and IUSR_[MACHINENAME] accounts.

IMPORTANT: in case the DCOM Config panel does not contain any “Microsoft XYZ Document” and/or “Microsoft XYZ Application“, it’s most likely due to the fact that a 32-bit MS Office version has been installed on a 64-bit server machine: if that’s the case, we’ll need to launch the snap-in in 32-bit mode by using the following command:

For additional info regarding this topic, you can take a look at this MS TechNet article.

RPC_E_SERVERCALL_RETRYLATER

This error message is strictly related to the fact that we’re trying to use the Microsoft.Office.Interop libraries in a multi-thread environment: if you see this, it probably means that two (or more) users are trying to create an instance of the same Office.Interop object, which cannot be done. The fix is to just implement a way to queue such requests by using    ,   or other similar methods (see this post for a quick implementation / code sample).

The RPC server is unavailable

The error 0x800706BA usually happens when the RPC Locator / RPC Endpoint Mapper windows service is not running. To fix that, just open Control Panel > Administrative Tools > Services and manually launch it. In case this is enough to fix your issue, remember to switch its starting behaviour from “Manual” to “Automatic”, otherwise your Web Application will cease to work upon each machine reboot.

0x800A03EC Cannot access the file

The 0x800A03EC Cannot access the file is arguably the worst error you can experience, as the given error message is completely misleading. To fix that, you have to the following:

  • Create the following new folders on your Windows Server + IIS machine:
    • C:\Windows\SysWOW64\config\systemprofile\Desktop (for 64-bit Servers only)
    • C:\Windows\System32\config\systemprofile\Desktop (for both 32-bit and 64-bit Servers)
  • Set Full control permissions for these Desktop folders for the Application Pool user (IIS AppPool\DefaultAppPool if you’re using the ApplicationPoolIdentity dynamic account).

That’s it for now: I sincerely hope that this post will help most developers who’re struggling against the adversities of the dreadful Microsoft.Office.Interop ASP.NET library package!

 

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 *

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