By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,952 Members | 1,937 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,952 IT Pros & Developers. It's quick & easy.

Error instantiating a COM+ proxy

P: n/a
I have a two tier system.

I've created a COM+ package on the data tier (Win2003) and exported it as a
COM+proxy (v 1.0 compliant) and installed this onto a Win2000 web
application.

I've created a simple VB6 application that I run on the web tier to call a
method on the proxy stub and this successfully runs on the data tier.

However, I've attempted to create an ASP page that does exactly the same
thing and it falls over.

err.description: Permission denied
err.number: 70

I presume that this is a permissions problem for the anonymous web user. Is
it that the web user can't access the Proxy stub, or is it a permissions
thing on the data tier?

Any advice would be most welcome

Thanks

Griff
Jan 13 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Try giving rights to the COM object in dcomcnfg (from Start---run)

Ray at work

"Griff" <Ho*****@The.Moon> wrote in message
news:e1*************@TK2MSFTNGP15.phx.gbl...
I have a two tier system.

I've created a COM+ package on the data tier (Win2003) and exported it as
a COM+proxy (v 1.0 compliant) and installed this onto a Win2000 web
application.

I've created a simple VB6 application that I run on the web tier to call a
method on the proxy stub and this successfully runs on the data tier.

However, I've attempted to create an ASP page that does exactly the same
thing and it falls over.

err.description: Permission denied
err.number: 70

I presume that this is a permissions problem for the anonymous web user.
Is it that the web user can't access the Proxy stub, or is it a
permissions thing on the data tier?

Any advice would be most welcome

Thanks

Griff

Jan 13 '06 #2

P: n/a
> Try giving rights to the COM object in dcomcnfg (from Start---run)

Sorry, not got this to work....what I tried was as follows:

1 - I ran dcomcnfg on the web tier (the one with the proxy)
2 - I selected the class ID in the list of applications {A89..}
3 - I went to the tab "Default Security"
4 - In the second box "Default Launch Permissions" I set the following:

Add user "IUSR_^servername^ = Allow Launch

5 - I tried the web page again .... same "permission denied" error

Griff

Jan 13 '06 #3

P: n/a
You may need...
....permissions at the file level for the DLL or whatever
is exposing that com object.

The latest service pack to XP as well as many of microsofts
patches are tightening up and not giving the developer as many
freedoms as we once had (which is a good thing).

Let me know if the file permissions resolved the issue.

D.
Griff wrote:
Try giving rights to the COM object in dcomcnfg (from Start---run)

Sorry, not got this to work....what I tried was as follows:

1 - I ran dcomcnfg on the web tier (the one with the proxy)
2 - I selected the class ID in the list of applications {A89..}
3 - I went to the tab "Default Security"
4 - In the second box "Default Launch Permissions" I set the following:

Add user "IUSR_^servername^ = Allow Launch

5 - I tried the web page again .... same "permission denied" error

Griff


Jan 13 '06 #4

P: n/a
"Griff" <Ho*****@The.Moon> wrote in message
news:e1*************@TK2MSFTNGP15.phx.gbl...
I have a two tier system.

I've created a COM+ package on the data tier (Win2003) and exported it as
a COM+proxy (v 1.0 compliant) and installed this onto a Win2000 web
application.

I've created a simple VB6 application that I run on the web tier to call a
method on the proxy stub and this successfully runs on the data tier.

However, I've attempted to create an ASP page that does exactly the same
thing and it falls over.

err.description: Permission denied
err.number: 70

I presume that this is a permissions problem for the anonymous web user.
Is it that the web user can't access the Proxy stub, or is it a
permissions thing on the data tier?

Any advice would be most welcome

Under Windows 2003 only members of the <machine>\Distributed COM Users group
is allowed to access any COM+ objects from a remote computer. There are
various approaches to solving the problem. You could add the name of the
remote user to this group, or you can change the default COM Security
permissions to allow Everyone access.

On the Windows 2003 server, bring up your Component Services control panel
applet and right click on "My Computer". Choose the Com Security tabe and
add "Everyone" both local and remote access.

HTH

Brian
Jan 13 '06 #5

P: n/a
> You may need...
...permissions at the file level for the DLL or whatever
is exposing that com object.


The web (Win2000) and data (Win2003) servers are not in a domain, and there
is no TRUST relationship between them.

I added the permission you mentioned to the DLL in the web\c$\program
files\complus\{a9832.....}\myDLL.dll - no luck.

I'll write up my full setup in a reply to Brian Muth (in this same thread)

Thanks

Griff


Jan 16 '06 #6

P: n/a
Hi Brian

Thanks for the reply - unfortunately it did not work.....

What I will attempt to do is to set out the full set of security permissions
and state what does and does not work. Hopefully, for those in the know, it
will be obvious what my mistake is.

SET UP
Web tier = Win2000
Data tier = Win2003
These servers are NOT in a domain and there is no trust relationship between
these servers. They are effectively "stand alone".

COM+ APPLICATION
Package installed on DATA tier and exported as a proxy (COM+ 1.0 format).
This is installed on the WEB tier.

WHAT DOES WORK
Logging on as the WEB TIER administrator, I can run an executable that calls
this proxy COM+ application. It successfully executes on the DATA tier.

WHAT DOES NOT WORK
Opening up a web browser to run an ASP page that does exactly what the
executably in the previous step did. Error is: 70, Permission denied.

PERMISSIONS ON THE WEB TIER
From Component Services control panel, myComputer properties, Default
security:
Default access permissions: [blank]
Default launch permissions: IUSR_WEB "Allow defaultLaunchPermission"

From Component Services control panel, COM+ Applications, myPackage
properties
Only property is the IP address of the DATA tier on the Activation tab

From Component Services control panel, COM+ Applications, myPackage,
myComponent properties
All greyed out

C:\Program Files\ComPlus Applications\{A8....}\myDLL.dll
I tried to explicitly give IUSR_WEB explicit EXECUTE permissions, but this
had no effect, so I removed it.

PERMISSIONS ON THE DATA TIER
From Component Services control panel, myComputer properties, COM security
tab:
Access permissions (default): EVERYONE & SELF (local and remote access),
SYSTEM (local access)
Access permissions (limits) : ANONYMOUS LOGON, DISTRIBUTED COM USES,
EVERYONE ( local & remote access)
Launch and activation permissions (default): ADMINISTRATORS, EVERYONE,
INTERACTIVE, SYSTEM (local launch, remote launch, local activation, remote
activation)
Launch and activation permissions (limits): ADMINISTRATORS, DISTRIBUTED COM
USERS, EVERYONE (Local & remote launch, local & remote activation).

From Component Services control panel, COM+ Applications, myPackage
properties
Security: enforce access checks for this application; perform access checks
at the process and component level; authentication level (packet);
impersonation level (impersonate)
Identity: This user (DATA\Administrator)
Activation: Server

From Component Services control panel, COM+ Applications, myPackage,
myComponent properties
Transactions support: not supported
Security: nothing ticked
Activation: don't force activation context
Concurrency: required

The actual DLL is held on the D drive and it's security is: Administrators
(Full control); System (Full control); USERS (Read & Execute)

Not sure what else to try.....

Griff
"Brian Muth" <bm***@mvps.org> wrote in message > Under Windows 2003 only
members of the <machine>\Distributed COM Users group
is allowed to access any COM+ objects from a remote computer. There are
various approaches to solving the problem. You could add the name of the
remote user to this group, or you can change the default COM Security
permissions to allow Everyone access.

On the Windows 2003 server, bring up your Component Services control panel
applet and right click on "My Computer". Choose the Com Security tabe and
add "Everyone" both local and remote access.

HTH

Brian

Jan 16 '06 #7

P: n/a
Is "Roles" something that I should be investigating (or at least users
within the CREATEOWNER role)? I'm not familiar with roles....

Griff
Jan 16 '06 #8

P: n/a
Oh, missed out the following:

On DATA tier, added EVERYONE to the [Distributed Com Users] Group, but to no
avail.

Griff
Jan 16 '06 #9

P: n/a
Hmmm

On the web tier I temporarily added the "IUSR_Server" to the Windows
Administrators group and it didn't help. Not sure what this tells me - does
it tell me that the permission denied error is on the DATA tier?

All help appreciated in this one

Griff
Jan 17 '06 #10

P: n/a
You can always tell directly what permission is being denied if you turn on
logon auditing in your local security settings.

HTH

Brian
Jan 17 '06 #11

P: n/a
Solved it.

Because the two machines are NOT in the same domain, authentication is not
passed around using SIDs but by encrypted username and password.

The context that the application is being run under (on the WEB tier) is of
course the IUSR_Server user. By default, IIS controls the password for
IUSR_Server.

What I had to do was to create a user on the DATA tier "IUSR_Server" and
give that a password of "1234" (for example). On the web tier, I then had
to stop IIS controlling the password and change it to "1234". After that,
everything worked.

Well, it did in our test environment. Yet to try it on our production
environment, but fingers crossed!

Anyhow, thanks for everyone's help in this.

Griff
Jan 18 '06 #12

P: n/a
>
Because the two machines are NOT in the same domain....


Ah, a key piece of information missing from your posts.

Glad you solved it!

Brian
Jan 18 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.