VB6 DCOM weirdness with HOSTS file after installation of XP SP2

[Rens Segaar]

Hi all,

Finally I got around to start testing one of our major products - heavily
based on VB6 EXE servers and DCOM - for compatibility with XP SP2. And -
luckily - I got things going finally, except for one little thing...

Got this ordinary (for testing purposes very simple) VB6 client application
and (again for testing purposes very simple) VB6 EXE server. The client
'instantiates' the EXE server using the CreateObject() function. Mind you, I
got all this working across two computers (without setting everything open
and with the firewall enabled and the two computer not being in the same
domain). The following are all local scenarios:

CreateObject(myserver, "") -- OK (logically)
CreateObject(myserver, "127.0.0.1") -- OK
CreateObject(myserver, "localhost") -- OK (even when localhost is
removed from the HOSTS file)
CreateObject(myserver, "192.168.200.23") -- OK (where the IP address
is the address of the local machine)
CreateObject(myserver, "192.168.1.1") -- OK (where the IP address is
mapped onto a Microsoft Loopback-adapter)
CreateObject(myserver, mycomputername) -- OK

CreateObject(myserver, "TestName") -- FAILS (where TestName is in the
HOSTS file and maps onto 192.168.200.23)
CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in the
HOSTS file and maps onto 192.168.1.1)

In both cases the error is a (70) Permission Denied error. There is some
kind of lookup taking place, because when a try a fake name (one that is not
in the HOSTS file) the error returned is (462) The remote server machine
does not exist or is unavailable.

Somehow the name resolution is locked out (??).

All this was working OK prior to installing SP2.

Turning off the firewall and/or further relaxing DCOM security settings have
no effect on this issue.

You may wonder why I want this to work at all, given all the other
possibilities, but within our existing code this is the way it was
implemented in the past and we want this funcitionality back in order not to
have to rewrite a very huge part of our code.

Any idea? Anyone?

TIA,
Rens Segaar
senior software engineer
www.beveco.nl

[David Candy]

This is the wrong group.

news://msnews.microsoft.com

and look for VB groups (or psdk).

--=20
----------------------------------------------------------
http://www.uscricket.com
"Rens Segaar" > wrote in message =
...
> Hi all,
>=20
> Finally I got around to start testing one of our major products - =
heavily=20
> based on VB6 EXE servers and DCOM - for compatibility with XP SP2. And =
-=20
> luckily - I got things going finally, except for one little thing...
>=20
> Got this ordinary (for testing purposes very simple) VB6 client =
application=20
> and (again for testing purposes very simple) VB6 EXE server. The =
client=20
> 'instantiates' the EXE server using the CreateObject() function. Mind =
you, I=20
> got all this working across two computers (without setting everything =
open=20
> and with the firewall enabled and the two computer not being in the =
same=20
> domain). The following are all local scenarios:
>=20
> CreateObject(myserver, "") -- OK (logically)
> CreateObject(myserver, "127.0.0.1") -- OK
> CreateObject(myserver, "localhost") -- OK (even when localhost is=20
> removed from the HOSTS file)
> CreateObject(myserver, "192.168.200.23") -- OK (where the IP =
address=20
> is the address of the local machine)
> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address =
is=20
> mapped onto a Microsoft Loopback-adapter)
> CreateObject(myserver, mycomputername) -- OK
>=20
> CreateObject(myserver, "TestName") -- FAILS (where TestName is in =
the=20
> HOSTS file and maps onto 192.168.200.23)
> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in =
the=20
> HOSTS file and maps onto 192.168.1.1)
>=20
> In both cases the error is a (70) Permission Denied error. There is =
some=20
> kind of lookup taking place, because when a try a fake name (one that =
is not=20
> in the HOSTS file) the error returned is (462) The remote server =
machine=20
> does not exist or is unavailable.
>=20
> Somehow the name resolution is locked out (??).
>=20
> All this was working OK prior to installing SP2.
>=20
> Turning off the firewall and/or further relaxing DCOM security =
settings have=20
> no effect on this issue.
>=20
> You may wonder why I want this to work at all, given all the other=20
> possibilities, but within our existing code this is the way it was=20
> implemented in the past and we want this funcitionality back in order =
not to=20
> have to rewrite a very huge part of our code.
>=20
> Any idea? Anyone?
>=20
> TIA,
> Rens Segaar
> senior software engineer
> www.beveco.nl
>=20
>

[Rens Segaar]

I did post this to a VB group.

If your talking about me crossposting this to the windowsxp.general
newsgroup as well, there is a pretty good reason for it and I do see why
this would be a wrong group. I sincerely doubt my problem has anything to do
at all with VB6, the use of the CreateObject() function or any psdk. It has
to do with things in the Windows XP system changing after installing SP2, in
this case in particular in dealing with the HOSTS file. To some extend I
have actually higher expectations from the windowsxp.general group than from
the vb.com group where it comes to getting the right answer. I cannot think
of (i.e. find) any better group, but any suggestions are most welcome.

Regards,
Rens Segaar

"David Candy" <.> wrote in message
...
This is the wrong group.

news://msnews.microsoft.com

and look for VB groups (or psdk).

--
----------------------------------------------------------
http://www.uscricket.com
"Rens Segaar" > wrote in message
...
> Hi all,
>
> Finally I got around to start testing one of our major products - heavily
> based on VB6 EXE servers and DCOM - for compatibility with XP SP2. And -
> luckily - I got things going finally, except for one little thing...
>
> Got this ordinary (for testing purposes very simple) VB6 client
> application
> and (again for testing purposes very simple) VB6 EXE server. The client
> 'instantiates' the EXE server using the CreateObject() function. Mind you,
> I
> got all this working across two computers (without setting everything open
> and with the firewall enabled and the two computer not being in the same
> domain). The following are all local scenarios:
>
> CreateObject(myserver, "") -- OK (logically)
> CreateObject(myserver, "127.0.0.1") -- OK
> CreateObject(myserver, "localhost") -- OK (even when localhost is
> removed from the HOSTS file)
> CreateObject(myserver, "192.168.200.23") -- OK (where the IP address
> is the address of the local machine)
> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address is
> mapped onto a Microsoft Loopback-adapter)
> CreateObject(myserver, mycomputername) -- OK
>
> CreateObject(myserver, "TestName") -- FAILS (where TestName is in the
> HOSTS file and maps onto 192.168.200.23)
> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in the
> HOSTS file and maps onto 192.168.1.1)
>
> In both cases the error is a (70) Permission Denied error. There is some
> kind of lookup taking place, because when a try a fake name (one that is
> not
> in the HOSTS file) the error returned is (462) The remote server machine
> does not exist or is unavailable.
>
> Somehow the name resolution is locked out (??).
>
> All this was working OK prior to installing SP2.
>
> Turning off the firewall and/or further relaxing DCOM security settings
> have
> no effect on this issue.
>
> You may wonder why I want this to work at all, given all the other
> possibilities, but within our existing code this is the way it was
> implemented in the past and we want this funcitionality back in order not
> to
> have to rewrite a very huge part of our code.
>
> Any idea? Anyone?
>
> TIA,
> Rens Segaar
> senior software engineer
> www.beveco.nl
>
>

[David Candy]

Have you checked the account it's running in and compared it to the file =
permissions. There aren't many in general that will understand your =
question. I understand the question but have no idea about the =
solution..

--=20
----------------------------------------------------------
http://www.uscricket.com
"Rens Segaar" > wrote in message =
...
>I did post this to a VB group.
>=20
> If your talking about me crossposting this to the windowsxp.general=20
> newsgroup as well, there is a pretty good reason for it and I do see =
why=20
> this would be a wrong group. I sincerely doubt my problem has anything =
to do=20
> at all with VB6, the use of the CreateObject() function or any psdk. =
It has=20
> to do with things in the Windows XP system changing after installing =
SP2, in=20
> this case in particular in dealing with the HOSTS file. To some extend =
I=20
> have actually higher expectations from the windowsxp.general group =
than from=20
> the vb.com group where it comes to getting the right answer. I cannot =
think=20
> of (i.e. find) any better group, but any suggestions are most welcome.
>=20
> Regards,
> Rens Segaar
>=20
> "David Candy" <.> wrote in message=20
> ...
> This is the wrong group.
>=20
> news://msnews.microsoft.com
>=20
> and look for VB groups (or psdk).
>=20
> --=20
> ----------------------------------------------------------
> http://www.uscricket.com
> "Rens Segaar" > wrote in message=20
> ...
>> Hi all,
>>
>> Finally I got around to start testing one of our major products - =
heavily
>> based on VB6 EXE servers and DCOM - for compatibility with XP SP2. =
And -
>> luckily - I got things going finally, except for one little thing...
>>
>> Got this ordinary (for testing purposes very simple) VB6 client=20
>> application
>> and (again for testing purposes very simple) VB6 EXE server. The =
client
>> 'instantiates' the EXE server using the CreateObject() function. Mind =
you,=20
>> I
>> got all this working across two computers (without setting everything =
open
>> and with the firewall enabled and the two computer not being in the =
same
>> domain). The following are all local scenarios:
>>
>> CreateObject(myserver, "") -- OK (logically)
>> CreateObject(myserver, "127.0.0.1") -- OK
>> CreateObject(myserver, "localhost") -- OK (even when localhost is
>> removed from the HOSTS file)
>> CreateObject(myserver, "192.168.200.23") -- OK (where the IP =
address
>> is the address of the local machine)
>> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address =
is
>> mapped onto a Microsoft Loopback-adapter)
>> CreateObject(myserver, mycomputername) -- OK
>>
>> CreateObject(myserver, "TestName") -- FAILS (where TestName is in =
the
>> HOSTS file and maps onto 192.168.200.23)
>> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is =
in the
>> HOSTS file and maps onto 192.168.1.1)
>>
>> In both cases the error is a (70) Permission Denied error. There is =
some
>> kind of lookup taking place, because when a try a fake name (one that =
is=20
>> not
>> in the HOSTS file) the error returned is (462) The remote server =
machine
>> does not exist or is unavailable.
>>
>> Somehow the name resolution is locked out (??).
>>
>> All this was working OK prior to installing SP2.
>>
>> Turning off the firewall and/or further relaxing DCOM security =
settings=20
>> have
>> no effect on this issue.
>>
>> You may wonder why I want this to work at all, given all the other
>> possibilities, but within our existing code this is the way it was
>> implemented in the past and we want this funcitionality back in order =
not=20
>> to
>> have to rewrite a very huge part of our code.
>>
>> Any idea? Anyone?
>>
>> TIA,
>> Rens Segaar
>> senior software engineer
>> www.beveco.nl
>>
>>=20
>=20
>

[Tony Proctor]

Seems to be a common theme Rens. XP SP2 seemed to tighten up a lot on
security. Is there anything in this similar thread that rings a bell?
http://www.google.ie/groups?hl=en&lr=lang_en&safe=off&threadm=%23RRgypWiEHA.3996%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fas_q%3DSP2%2520permission%2520dcom%2520xp %26safe%3Doff%26as_ugroup%3D*.vb%26lr%3Dlang_en%26 hl%3Den

Tony Proctor

"Rens Segaar" > wrote in message
...
> Hi all,
>
> Finally I got around to start testing one of our major products - heavily
> based on VB6 EXE servers and DCOM - for compatibility with XP SP2. And -
> luckily - I got things going finally, except for one little thing...
>
> Got this ordinary (for testing purposes very simple) VB6 client
application
> and (again for testing purposes very simple) VB6 EXE server. The client
> 'instantiates' the EXE server using the CreateObject() function. Mind you,
I
> got all this working across two computers (without setting everything open
> and with the firewall enabled and the two computer not being in the same
> domain). The following are all local scenarios:
>
> CreateObject(myserver, "") -- OK (logically)
> CreateObject(myserver, "127.0.0.1") -- OK
> CreateObject(myserver, "localhost") -- OK (even when localhost is
> removed from the HOSTS file)
> CreateObject(myserver, "192.168.200.23") -- OK (where the IP
address
> is the address of the local machine)
> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address is
> mapped onto a Microsoft Loopback-adapter)
> CreateObject(myserver, mycomputername) -- OK
>
> CreateObject(myserver, "TestName") -- FAILS (where TestName is in the
> HOSTS file and maps onto 192.168.200.23)
> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in
the
> HOSTS file and maps onto 192.168.1.1)
>
> In both cases the error is a (70) Permission Denied error. There is some
> kind of lookup taking place, because when a try a fake name (one that is
not
> in the HOSTS file) the error returned is (462) The remote server machine
> does not exist or is unavailable.
>
> Somehow the name resolution is locked out (??).
>
> All this was working OK prior to installing SP2.
>
> Turning off the firewall and/or further relaxing DCOM security settings
have
> no effect on this issue.
>
> You may wonder why I want this to work at all, given all the other
> possibilities, but within our existing code this is the way it was
> implemented in the past and we want this funcitionality back in order not
to
> have to rewrite a very huge part of our code.
>
> Any idea? Anyone?
>
> TIA,
> Rens Segaar
> senior software engineer
> www.beveco.nl
>
>

[Rens Segaar]

Tony,

Thanx for your response. I had seen this particular thread passing by in my
search for an answer. I have actually been able to deal with similar
problems and got all of DCOM working (even without setting everything to
ANONYMOUS LOGON remote access permission).

The problem I describe is of a somewhat different nature. It is only a
problem on a local machine and then only if I try to use the local machine
through its own IP address, which is in the HOSTS file.

Anybody having more ideas...

Rens Segaar


"Tony Proctor" > wrote in message
...
> Seems to be a common theme Rens. XP SP2 seemed to tighten up a lot on
> security. Is there anything in this similar thread that rings a bell?
> http://www.google.ie/groups?hl=en&lr=lang_en&safe=off&threadm=%23RRgypWiEHA.3996%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fas_q%3DSP2%2520permission%2520dcom%2520xp %26safe%3Doff%26as_ugroup%3D*.vb%26lr%3Dlang_en%26 hl%3Den
>
> Tony Proctor
>
> "Rens Segaar" > wrote in message
> ...
>> Hi all,
>>
>> Finally I got around to start testing one of our major products - heavily
>> based on VB6 EXE servers and DCOM - for compatibility with XP SP2. And -
>> luckily - I got things going finally, except for one little thing...
>>
>> Got this ordinary (for testing purposes very simple) VB6 client
> application
>> and (again for testing purposes very simple) VB6 EXE server. The client
>> 'instantiates' the EXE server using the CreateObject() function. Mind
>> you,
> I
>> got all this working across two computers (without setting everything
>> open
>> and with the firewall enabled and the two computer not being in the same
>> domain). The following are all local scenarios:
>>
>> CreateObject(myserver, "") -- OK (logically)
>> CreateObject(myserver, "127.0.0.1") -- OK
>> CreateObject(myserver, "localhost") -- OK (even when localhost is
>> removed from the HOSTS file)
>> CreateObject(myserver, "192.168.200.23") -- OK (where the IP
> address
>> is the address of the local machine)
>> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address is
>> mapped onto a Microsoft Loopback-adapter)
>> CreateObject(myserver, mycomputername) -- OK
>>
>> CreateObject(myserver, "TestName") -- FAILS (where TestName is in the
>> HOSTS file and maps onto 192.168.200.23)
>> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in
> the
>> HOSTS file and maps onto 192.168.1.1)
>>
>> In both cases the error is a (70) Permission Denied error. There is some
>> kind of lookup taking place, because when a try a fake name (one that is
> not
>> in the HOSTS file) the error returned is (462) The remote server machine
>> does not exist or is unavailable.
>>
>> Somehow the name resolution is locked out (??).
>>
>> All this was working OK prior to installing SP2.
>>
>> Turning off the firewall and/or further relaxing DCOM security settings
> have
>> no effect on this issue.
>>
>> You may wonder why I want this to work at all, given all the other
>> possibilities, but within our existing code this is the way it was
>> implemented in the past and we want this funcitionality back in order not
> to
>> have to rewrite a very huge part of our code.
>>
>> Any idea? Anyone?
>>
>> TIA,
>> Rens Segaar
>> senior software engineer
>> www.beveco.nl
>>
>>
>
>

[Tony Proctor]

Hmm! Just re-read your question...

All TCP/IP s/w should be resolving addresses the same way, e.g. HOSTS first,
then DNS. I guess you can ping these new TestName/TestName2 names OK, can
you Rens?

It sounds like the names are being resolved OK for DCOM, but maybe different
security implications are associated with a resolution from HOSTS as opposed
to DNS. However, I'm afraid I don't know enough about what was changed in XP
SP2 to suggest what, or why. There are usually differences specifying
127.0.0.1 over localhost or the local machine name because any numeric IP
address is considered part of the Internet zone (i.e. 127.0.0.1 would have
to be added as a trusted site), but I don't think that's relevant here.

Sorry I can't really help

Tony Proctor

"Rens Segaar" > wrote in message
...
> Tony,
>
> Thanx for your response. I had seen this particular thread passing by in
my
> search for an answer. I have actually been able to deal with similar
> problems and got all of DCOM working (even without setting everything to
> ANONYMOUS LOGON remote access permission).
>
> The problem I describe is of a somewhat different nature. It is only a
> problem on a local machine and then only if I try to use the local machine
> through its own IP address, which is in the HOSTS file.
>
> Anybody having more ideas...
>
> Rens Segaar
>
>
> "Tony Proctor" > wrote in
message
> ...
> > Seems to be a common theme Rens. XP SP2 seemed to tighten up a lot on
> > security. Is there anything in this similar thread that rings a bell?
> >
http://www.google.ie/groups?hl=en&lr=lang_en&safe=off&threadm=%23RRgypWiEHA.3996%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fas_q%3DSP2%2520permission%2520dcom%2520xp %26safe%3Doff%26as_ugroup%3D*.vb%26lr%3Dlang_en%26 hl%3Den
> >
> > Tony Proctor
> >
> > "Rens Segaar" > wrote in message
> > ...
> >> Hi all,
> >>
> >> Finally I got around to start testing one of our major products -
heavily
> >> based on VB6 EXE servers and DCOM - for compatibility with XP SP2.
And -
> >> luckily - I got things going finally, except for one little thing...
> >>
> >> Got this ordinary (for testing purposes very simple) VB6 client
> > application
> >> and (again for testing purposes very simple) VB6 EXE server. The client
> >> 'instantiates' the EXE server using the CreateObject() function. Mind
> >> you,
> > I
> >> got all this working across two computers (without setting everything
> >> open
> >> and with the firewall enabled and the two computer not being in the
same
> >> domain). The following are all local scenarios:
> >>
> >> CreateObject(myserver, "") -- OK (logically)
> >> CreateObject(myserver, "127.0.0.1") -- OK
> >> CreateObject(myserver, "localhost") -- OK (even when localhost is
> >> removed from the HOSTS file)
> >> CreateObject(myserver, "192.168.200.23") -- OK (where the IP
> > address
> >> is the address of the local machine)
> >> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address
is
> >> mapped onto a Microsoft Loopback-adapter)
> >> CreateObject(myserver, mycomputername) -- OK
> >>
> >> CreateObject(myserver, "TestName") -- FAILS (where TestName is in
the
> >> HOSTS file and maps onto 192.168.200.23)
> >> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in
> > the
> >> HOSTS file and maps onto 192.168.1.1)
> >>
> >> In both cases the error is a (70) Permission Denied error. There is
some
> >> kind of lookup taking place, because when a try a fake name (one that
is
> > not
> >> in the HOSTS file) the error returned is (462) The remote server
machine
> >> does not exist or is unavailable.
> >>
> >> Somehow the name resolution is locked out (??).
> >>
> >> All this was working OK prior to installing SP2.
> >>
> >> Turning off the firewall and/or further relaxing DCOM security settings
> > have
> >> no effect on this issue.
> >>
> >> You may wonder why I want this to work at all, given all the other
> >> possibilities, but within our existing code this is the way it was
> >> implemented in the past and we want this funcitionality back in order
not
> > to
> >> have to rewrite a very huge part of our code.
> >>
> >> Any idea? Anyone?
> >>
> >> TIA,
> >> Rens Segaar
> >> senior software engineer
> >> www.beveco.nl
> >>
> >>
> >
> >
>
>

[Tony Proctor]

I think I've found something relevant Rens. There's a Microsoft article
called "Authentication may fail with "401.3" Error if Web site's "Host
Header" differs from server's NetBIOS name" (article ID 294382) at
http://support.microsoft.com/default.aspx/kb/294382/EN-US/?

It does appear to be related to the tightening of security in XP SP2. The
suggested workaround is to run the following script from the
c:\inetpub\adminscripts directory:
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"
Tony Proctor

"Rens Segaar" > wrote in message
...
> Tony,
>
> Thanx for your response. I had seen this particular thread passing by in
my
> search for an answer. I have actually been able to deal with similar
> problems and got all of DCOM working (even without setting everything to
> ANONYMOUS LOGON remote access permission).
>
> The problem I describe is of a somewhat different nature. It is only a
> problem on a local machine and then only if I try to use the local machine
> through its own IP address, which is in the HOSTS file.
>
> Anybody having more ideas...
>
> Rens Segaar
>
>
> "Tony Proctor" > wrote in
message
> ...
> > Seems to be a common theme Rens. XP SP2 seemed to tighten up a lot on
> > security. Is there anything in this similar thread that rings a bell?
> >
http://www.google.ie/groups?hl=en&lr=lang_en&safe=off&threadm=%23RRgypWiEHA.3996%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fas_q%3DSP2%2520permission%2520dcom%2520xp %26safe%3Doff%26as_ugroup%3D*.vb%26lr%3Dlang_en%26 hl%3Den
> >
> > Tony Proctor
> >
> > "Rens Segaar" > wrote in message
> > ...
> >> Hi all,
> >>
> >> Finally I got around to start testing one of our major products -
heavily
> >> based on VB6 EXE servers and DCOM - for compatibility with XP SP2.
And -
> >> luckily - I got things going finally, except for one little thing...
> >>
> >> Got this ordinary (for testing purposes very simple) VB6 client
> > application
> >> and (again for testing purposes very simple) VB6 EXE server. The client
> >> 'instantiates' the EXE server using the CreateObject() function. Mind
> >> you,
> > I
> >> got all this working across two computers (without setting everything
> >> open
> >> and with the firewall enabled and the two computer not being in the
same
> >> domain). The following are all local scenarios:
> >>
> >> CreateObject(myserver, "") -- OK (logically)
> >> CreateObject(myserver, "127.0.0.1") -- OK
> >> CreateObject(myserver, "localhost") -- OK (even when localhost is
> >> removed from the HOSTS file)
> >> CreateObject(myserver, "192.168.200.23") -- OK (where the IP
> > address
> >> is the address of the local machine)
> >> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address
is
> >> mapped onto a Microsoft Loopback-adapter)
> >> CreateObject(myserver, mycomputername) -- OK
> >>
> >> CreateObject(myserver, "TestName") -- FAILS (where TestName is in
the
> >> HOSTS file and maps onto 192.168.200.23)
> >> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is in
> > the
> >> HOSTS file and maps onto 192.168.1.1)
> >>
> >> In both cases the error is a (70) Permission Denied error. There is
some
> >> kind of lookup taking place, because when a try a fake name (one that
is
> > not
> >> in the HOSTS file) the error returned is (462) The remote server
machine
> >> does not exist or is unavailable.
> >>
> >> Somehow the name resolution is locked out (??).
> >>
> >> All this was working OK prior to installing SP2.
> >>
> >> Turning off the firewall and/or further relaxing DCOM security settings
> > have
> >> no effect on this issue.
> >>
> >> You may wonder why I want this to work at all, given all the other
> >> possibilities, but within our existing code this is the way it was
> >> implemented in the past and we want this funcitionality back in order
not
> > to
> >> have to rewrite a very huge part of our code.
> >>
> >> Any idea? Anyone?
> >>
> >> TIA,
> >> Rens Segaar
> >> senior software engineer
> >> www.beveco.nl
> >>
> >>
> >
> >
>
>

[Rens Segaar]

Too bad Tony, but again thanx anyway...

.... and BTW you are right in your assumption that pinging TestName and
TestName2 simply works.

Rens Segaar


"Tony Proctor" > wrote in message
...
> Hmm! Just re-read your question...
>
> All TCP/IP s/w should be resolving addresses the same way, e.g. HOSTS
> first,
> then DNS. I guess you can ping these new TestName/TestName2 names OK, can
> you Rens?
>
> It sounds like the names are being resolved OK for DCOM, but maybe
> different
> security implications are associated with a resolution from HOSTS as
> opposed
> to DNS. However, I'm afraid I don't know enough about what was changed in
> XP
> SP2 to suggest what, or why. There are usually differences specifying
> 127.0.0.1 over localhost or the local machine name because any numeric IP
> address is considered part of the Internet zone (i.e. 127.0.0.1 would have
> to be added as a trusted site), but I don't think that's relevant here.
>
> Sorry I can't really help
>
> Tony Proctor
>
> "Rens Segaar" > wrote in message
> ...
>> Tony,
>>
>> Thanx for your response. I had seen this particular thread passing by in
> my
>> search for an answer. I have actually been able to deal with similar
>> problems and got all of DCOM working (even without setting everything to
>> ANONYMOUS LOGON remote access permission).
>>
>> The problem I describe is of a somewhat different nature. It is only a
>> problem on a local machine and then only if I try to use the local
>> machine
>> through its own IP address, which is in the HOSTS file.
>>
>> Anybody having more ideas...
>>
>> Rens Segaar
>>
>>
>> "Tony Proctor" > wrote in
> message
>> ...
>> > Seems to be a common theme Rens. XP SP2 seemed to tighten up a lot on
>> > security. Is there anything in this similar thread that rings a bell?
>> >
> http://www.google.ie/groups?hl=en&lr=lang_en&safe=off&threadm=%23RRgypWiEHA.3996%40tk2msftngp13.phx.gbl&rnum=1&prev=/groups%3Fas_q%3DSP2%2520permission%2520dcom%2520xp %26safe%3Doff%26as_ugroup%3D*.vb%26lr%3Dlang_en%26 hl%3Den
>> >
>> > Tony Proctor
>> >
>> > "Rens Segaar" > wrote in message
>> > ...
>> >> Hi all,
>> >>
>> >> Finally I got around to start testing one of our major products -
> heavily
>> >> based on VB6 EXE servers and DCOM - for compatibility with XP SP2.
> And -
>> >> luckily - I got things going finally, except for one little thing...
>> >>
>> >> Got this ordinary (for testing purposes very simple) VB6 client
>> > application
>> >> and (again for testing purposes very simple) VB6 EXE server. The
>> >> client
>> >> 'instantiates' the EXE server using the CreateObject() function. Mind
>> >> you,
>> > I
>> >> got all this working across two computers (without setting everything
>> >> open
>> >> and with the firewall enabled and the two computer not being in the
> same
>> >> domain). The following are all local scenarios:
>> >>
>> >> CreateObject(myserver, "") -- OK (logically)
>> >> CreateObject(myserver, "127.0.0.1") -- OK
>> >> CreateObject(myserver, "localhost") -- OK (even when localhost is
>> >> removed from the HOSTS file)
>> >> CreateObject(myserver, "192.168.200.23") -- OK (where the IP
>> > address
>> >> is the address of the local machine)
>> >> CreateObject(myserver, "192.168.1.1") -- OK (where the IP address
> is
>> >> mapped onto a Microsoft Loopback-adapter)
>> >> CreateObject(myserver, mycomputername) -- OK
>> >>
>> >> CreateObject(myserver, "TestName") -- FAILS (where TestName is in
> the
>> >> HOSTS file and maps onto 192.168.200.23)
>> >> CreateObject(myserver, "TestName2") -- FAILS (where TestName2 is
>> >> in
>> > the
>> >> HOSTS file and maps onto 192.168.1.1)
>> >>
>> >> In both cases the error is a (70) Permission Denied error. There is
> some
>> >> kind of lookup taking place, because when a try a fake name (one that
> is
>> > not
>> >> in the HOSTS file) the error returned is (462) The remote server
> machine
>> >> does not exist or is unavailable.
>> >>
>> >> Somehow the name resolution is locked out (??).
>> >>
>> >> All this was working OK prior to installing SP2.
>> >>
>> >> Turning off the firewall and/or further relaxing DCOM security
>> >> settings
>> > have
>> >> no effect on this issue.
>> >>
>> >> You may wonder why I want this to work at all, given all the other
>> >> possibilities, but within our existing code this is the way it was
>> >> implemented in the past and we want this funcitionality back in order
> not
>> > to
>> >> have to rewrite a very huge part of our code.
>> >>
>> >> Any idea? Anyone?
>> >>
>> >> TIA,
>> >> Rens Segaar
>> >> senior software engineer
>> >> www.beveco.nl
>> >>
>> >>
>> >
>> >
>>
>>
>
>