I have a client-server application written in VB5 running fine since
years on Win98, WinNT e Win2000 systems.
Client and server are ActiveX components accessed by Remote Automation.
Now I have tried to install the application on a WinXP-SP2 PC, but I get
   a "Permission denied" error while creating the call-back object on
the client PC.

The Remote OLE works only partially:
1) the client succeeds to create the server object on the remote PC
2) The server on the remote PC succeeds to create call-back object on
the server
3) But the last step does not happen: the server on the remote PC cannot
create the call-back object on the client machine

I have disabled the firewall, but I got no result.

Any suggestions?

Thank you for replying.
(I've  already posted in vb.ole.automation, without getting any solution)

Have you read this?.....

How To Troubleshoot Run-time Error '70' in DCOM Applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;180384

Ken Halter wrote:

Thank you for your reply, ...but the article you linked refers to DCOM
applications, while I use Remote OLE Automation and not DCOM.

I do not know how to apply the information of the article on my case.

thank you anyway

Most articles that refer to using DCOMCNFG.EXE show what you see in Windows
2000 and prior. In XP, this opens "Component Services" in Control
Panel|Administrative Tools.

To follow the article, run the command and click on "Component Services"
item inside "Component Services" window. If you don't click on it you won't
see any subitems inside it. After clicking on it, go to Computers|My
Computer|DCOM Config. You might see some warnings that some AppID's are not
recorded, choose No. Choosing No leaves things the way they were so you can
debug things further. Choosing Yes will fix something for you in that
particular machine, but hides a setup step that you were supposed to take if
you were to make a setup package. Usually what is causing these warnings are
components made in C++, where the developer has full control of which
registry entries to create. The developer may have forgotten to create
certain keys. I am not sure if this normal to do or not, I don't know. In
VB6, you have nothing to worry about unless you are making your own setup
EXE program and adding the registry keys manually, but this is rare.

If you want to show the settings for a particular component, right-click on
it and select Properties.

When the article talks about default security or default options for all
objects, right-click on My Computer and select Properties.

INFO: Registry Entries Made by an ActiveX Component
http://support.microsoft.com/default.aspx?scid=kb;en-us;183771



Show quoteHide quote

Someone wrote:
Thanks for your reply.

But the object that creates problems is an ActiveX component (written in
VB5) accessed through Remote Automation and not DCOM.
That object is not listed in the DCOMCNFG.EXE, but in the Remote
Automation Connection Manager.

I try to figure out any possible workaround reading DCOM's articles, but
I believe the problem is in WinXP and its security: the application
works fine under Win9x, ME, NT3.5, NT4, Win2000, but only under WinXP it
does't work correctly.

Try this:

- Start "OLE View" in VS Tools in the Start menu.
- Close "Grouped by Component Category" to easily view other options.
- Open "All Objects".
- Click on your component, for example "Project1.Class1".
- Go to "Activation", "Launch Permissions", "Access Permissions", and modify
as needed. Note that there is a Modify button to the lower right.

In my version of XP+SP2, OLE View crashes if I click "+" to the left of my
component, but clicking on the component itself works fine.


Show quoteHide quote

I just tested a dummy DLL "Project1.Class1". In XP, "DCOM Config" lists it
with its GUID, not the friendly name, so it's difficult to see which one.
Use OLE View to find the GUID, then look it up in "DCOM Config". Since VB6
can create a different set of registry keys each time you compile without
binary compatibility, always use OLE View before going to DCOM Config.


Show quoteHide quote

Someone wrote:
I will try it and then report here.

Anywy, I do not understand why under WinXP should I set the securiy of
an OLE Remote Automation object with DCOM-Config tools and not with
Remote Automation Connection Manager?
Under Win2000 DCOM-Config is not required.

Thank you for your support.
Gio

I was confusing both because I never used "OLE Remote Automation", so I
assumed that it runs on top of DCOM. I also didn't see "Remote Automation
Connection Manager", but just found it now in VS6 Enterprise Tools. It seems
that you have to at least check "Allow Remote Activation".

In XP+SP2, Windows firewall was introduced, so turn it off from Control
Panel.

Also, someone may have removed Everyone group. Everyone group includes
SYSTEM account, so SYSTEM account cannot do anything. Check this article:

http://support.microsoft.com/kb/315270/EN-US/

Quote:

Show quoteHide quote

Someone wrote:

Already tried all, but nothing... :-(

I'm going to ask in the XP-ng, maybe they could have some idea...

Thank you anyway for your help.
Gio

Some articles that I found:

INFO: Common Remote OLE Automation Errors
http://support.microsoft.com/default.aspx?scid=kb;en-us;141824

Default System Security Policy
http://support.microsoft.com/default.aspx?scid=kb;en-us;143260

More:

http://support.microsoft.com/search/default.aspx?qu=Remote+Automation+Connection+Manager


Show quoteHide quote

Giobibo wrote:
I forgot to say that my application uses DCOM objects too.

With some remote objects I use the Remote Automation as transport with
other remote objects I use DCOM.

Well the part of the application that uses DCOM run perfectly without
the "Error 70", thus the DCOM setting and related issues are correct.

Show quote Hide quote Results 1 - 13 of 13 for dcom SP2 "permission denied" -dotnet group:*.vb.*
(0.16 seconds)
http://groups.google.com.my/groups?as_q=dcom+SP2&num=100&scoring=r&hl=en&as_epq=permission+denied&as_oq=&as_eq=dotnet&as_ugroup=*.vb.*&as_usubject=&as_uauthors=&lr=&as_drrb=q&as_qdr=&as_mind=1&as_minm=1&as_miny=1981&as_maxd=26&as_maxm=10&as_maxy=2005&safe=off

1 Make sure you enable network COM+ access and network DTC access on the
(DCOM) server
2 DCOM Config
COM Security tab
-Under Access Permission
            Edit Default: Give user permission
            Edit Limits: Give user permission
-Under Launch and Activation Permissions
            Edit Default: Give User permission (Administrators group should
have full permission by default)
            Edit Limits: Give User permission (Administrators group should
have full permission by default)
MSDTC tab
-Security Configuration
            Enable Network DTC Access
            Enable Allow Inbound
            Enable Allow Outbound
            Select Mutual Authentication Required (it should be the default)


Show quoteHide quote

Giobibo wrote:
I have found the solution!
I'll post it here, may be it could be interesting for somebody else.


The problem was the RPC limitation introduced by WinXP-SP2.

After editing the registry keys:
  - RestrictRemoteClients
  - EnableAuthEpResolution
the program run correctly.

Details on the RPC changes introduce by SP2 and how to edit the registry
here:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EHAA

Is there a more elegant way to do this?
Update Workstations with new executable
Compile, Save, Exit, ReStart, big trouble
Problem connecting to remote MySQL DB from VB6
Dependency walker and custom ocx.
Lexical analysis
How many ORs can you have in ADODB
Need to know when a process is exited
Best way to have a subroutine modify more than one variable
Scheduling Control