DCOM security

[Andrew Jarvis]

I am having problems creating a DCOM component under Windows XP SP2.

I am creating the component locally to eliminate any remote access issues.

When I set the identity to "The interactive user" I can create the component
okay so I know that its registered okay and all its dependencies are
present.

When I set the identity to the logged on user but specified explicitly under
"This user" I get VB error "ActiveX component can't create object".

What is the difference between "interactive user" and specifying the same
user under "This user"?

I have tried adding "Everyone" with full control under each security section
to no avail.

I have checked for any DCOM restrictions in "Local Security Settings\Local
Policies\Security Options" but none are set.

Where else should I look?

O my own computer there are only six policies in "Local Security
Settings\Local Policies\Security Options" - four "Accounts", a "Network
access" and a "Network security". On the problem computer there are
sixty-four.

What has added these additional policies?

 

[Andrew Jarvis]

PS. This is part of a distributed application that worked adequately until
we installed SP2.

 

[Roger Abell]

Keep in mind that granting to UserX and granting to
Interactive (with the understanding that the tests are
made with UserX logged in locally) do differ in that
the grant to UserX is without qualification as to whether
local or remote.
Have you examined the information on the changes to
DCom Activation security which was introduced with
XP SP2 ?
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EIAA

 

[Andrew Jarvis]

I have since discovered that if I double click the server in Explorer then
it launches okay.

If I right click and do Run As UserX then a dependency cannot be located.

Am I right in thinking that the environment is not being supplied to the
application in this instance?

What would cause this?

 

[Andrew Jarvis]

Finally figured it out.

In the environment path variable, the drive letter for the path of the
dependent DLL was assigned by "cmd /c subst ..." in the Startup folder!
Therefore it did not exist in the new user context.

Apologies for wasting your time.

AJ

 

[Roger Abell]

Hey, no apollogies needed nor expected
Glad you sorted it.