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).

 

[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).

 

[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..

 

[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&l...20xp&safe=off&as_ugroup=*.vb&lr=lang_en&hl=en

Tony Proctor

 

[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]

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

 

[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]

Too bad Tony, but again thanx anyway...

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

Rens Segaar