.NET Access Error with COM API

[CappyTan]

I have a project that is working locally when I run it in Visual Studio (running as administrator) to open a session and make requests.

However, when I deploy it to the server which is running Windows Server 2008 RS and IIS 7 I am getting what appears to be a permissions error that I am not sure how to fix.

System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {B3B13604-A675-11D2-9B95-00104B71EB3F} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

Any help would be greatly appreciated.

 

[Jay Converse]

64 bit IIS?
Accpac version and service packs?
Accpac client installed on server?
Accpac credentials passed in uppercase?

 

[WalterHeisenberg]

It is indeed 64 bit IIS. We did not have 32 bit applications enabled in the application pool if that makes a difference. The environment is Accpac 5.6 PU2 running on SQL Server 2008 R2. The client is indeed installed on the server and the credentials are being supplied in uppercase.

 

[Jay Converse]

Accpac is a 32-bit app, so enable it in the pool.

 

[WalterHeisenberg]

We have enabled the 32-bit in the app. pool but that did not solve the issue. We also changed application pool to run as the domain administrator. Any other ideas?

 

[DjangMan]

What is the SharedData path and the Programs Directory?

 

[WalterHeisenberg]

SharedData is a unc path to a network share on its own drive. The program files are local in C:\Sage.

 

[ettienne]

Don't use UNC paths to shares on local drives, use the natural path instead.

 

[WalterHeisenberg]

Sorry - what I typed previously was not clear. The shared data directory is not a local drive. It is our production server and we are using a UNC path rather than a mapped drive. The program files are local and those are not referenced by UNC.

 

[DjangMan]

Does the user that IIS is using to run as have rights to c:\sage and to run executables and invoke COM objects?

 

[WalterHeisenberg]

We gave all the Accpac related DCOM items Access Permissions to everyone as we weren't sure which one specifically would help us. But that is the only DCom change we made. We changed the IIS application pool to be a domain admin to rule out if access to the program files was causing this.

Thanks for all your help.