Name resolution is not enough

[mike singer]

We are seeing some servers where the ability to resolve the name is not
enough to get windows networking going. Only by using WINS (or lmhosts) is
networking reliable. What is truly needed to get rid of NetBIOS once and
for all. Here is an example of what I am seeing. I have done search and
replaces to change the server name and domain names and the IP address but
other than that, the following is what I am seeing. As another note, some
days things work great. Thanks in advance:

C:\>ping computer

Pinging computer.root.domain.com [10.10.10.10] with 32 bytes of d

Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126

Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>dir \\computer\c$
The network path was not found.

C:\>dir \\10.10.10.10\c$
Volume in drive \\10.10.10.10\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\10.10.10.10\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free

C:\>rem add entry into lmhosts

C:\>dir \\computer\c$
Volume in drive \\computer\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\computer\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free


C:\>

 

[nut cracker]

why are you trying to enumerate remote resources based on hidden,
administrative shares? Thats just crazy-talk.

It would be much wiser to map a drive resource (creates a persistent session
with credentials, semaphors, etc) and perform your interrogations against
that. It is much more reliable and will have equal or better performance.

NuTs

 

[mike singer]

The output was to demonstrate the issue. I could demonstrate it as well
with any type of resource. Essentially something is happening that is
making the system use NetBios instead of Kerberos and and then the
redirector isn't figuring out that the DNS hostname is the same as the
netbios name like it is supposed to. I was not asking for a religious
debate on the merits of admin shares, just insite on a problem I am having.

why are you trying to enumerate remote resources based on hidden,
administrative shares? Thats just crazy-talk.

It would be much wiser to map a drive resource (creates a persistent session
with credentials, semaphors, etc) and perform your interrogations against
that. It is much more reliable and will have equal or better performance.

NuTs

We are seeing some servers where the ability to resolve the name is not
enough to get windows networking going. Only by using WINS (or lmhosts) is
networking reliable. What is truly needed to get rid of NetBIOS once and
for all. Here is an example of what I am seeing. I have done search and
replaces to change the server name and domain names and the IP address but
other than that, the following is what I am seeing. As another note, some
days things work great. Thanks in advance:

C:\>ping computer

Pinging computer.root.domain.com [10.10.10.10] with 32 bytes of d

Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126

Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>dir \\computer\c$
The network path was not found.

C:\>dir \\10.10.10.10\c$
Volume in drive \\10.10.10.10\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\10.10.10.10\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free

C:\>rem add entry into lmhosts

C:\>dir \\computer\c$
Volume in drive \\computer\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\computer\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free


C:\>

 

[Jeff Cochran]

We are seeing some servers where the ability to resolve the name is not
enough to get windows networking going. Only by using WINS (or lmhosts) is
networking reliable. What is truly needed to get rid of NetBIOS once and
for all.

Wait a few more releases of the operating system most likely. Despite
all indications, NetBIOS is just too pervasive to get rid of it.
Fortunately, providing NetBIOS resolution through WINS is pretty
simple.

Jeff

 

[Jetro]

Did you search the Internet about 'TCP/IP NetBIOS Helper Service'?

 

[Matt Hickman]

We are seeing some servers where the ability to resolve the name is not
enough to get windows networking going. Only by using WINS (or lmhosts) is
networking reliable. What is truly needed to get rid of NetBIOS once and
for all. Here is an example of what I am seeing. I have done search and
replaces to change the server name and domain names and the IP address but
other than that, the following is what I am seeing. As another note, some
days things work great. Thanks in advance:

C:\>dir \\computer\c$
The network path was not found.

C:\>dir \\10.10.10.10\c$
Volume in drive \\10.10.10.10\c$ has no label.
Volume Serial Number is C81D-B304

if you do :

dir \\computer.root.domain.com\c$

that should work fine too.

Both the IP address and FQDN methods are reliable. They might
not be the way you are used to doing things, but they work.

 

[J.C. Hornbeck [MSFT]]

Hi Mike,
What kind of clients are you using? What is their node type? What kind of
name resolution exists already (e.g. DNS, WINS, etc.). Are Offline Files
enabled?

If you've got a situation where sometimes it works and sometimes it doesn't
then a quick path to resolution would be to use Network Monitor or some
other packet sniffer to determine exactly what it's doing when it works and
what it's doing when it fails.

--
J.C. Hornbeck, MCSE
Microsoft Product Support

NOTE: Please reply to the newsgroup and not directly to me. This allows
others to add to and benefit from these threads and also helps to ensure a
more timely response. Thank you!

This posting is provided "AS IS" without warranty either expressed or
implied, including, but not limited to, the implied warranties of
merchantability or fitness for a particular purpose.

We are seeing some servers where the ability to resolve the name is not
enough to get windows networking going. Only by using WINS (or lmhosts) is
networking reliable. What is truly needed to get rid of NetBIOS once and
for all. Here is an example of what I am seeing. I have done search and
replaces to change the server name and domain names and the IP address but
other than that, the following is what I am seeing. As another note, some
days things work great. Thanks in advance:

C:\>ping computer

Pinging computer.root.domain.com [10.10.10.10] with 32 bytes of d

Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126

Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>dir \\computer\c$
The network path was not found.

C:\>dir \\10.10.10.10\c$
Volume in drive \\10.10.10.10\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\10.10.10.10\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free

C:\>rem add entry into lmhosts

C:\>dir \\computer\c$
Volume in drive \\computer\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\computer\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free


C:\>

 

[Mike Singer]

Thanks JC. We are seeing this mostly from windows 2000 boxes. The boxes
that are using wins and DNS (which also uses wins resolution) work fine. We
are trying to get rid of wins and go DNS only. This issues only occurs with
servers that are not registering in WINS. Resolution works great but
networking does not always.

Hi Mike,
What kind of clients are you using? What is their node type? What kind of
name resolution exists already (e.g. DNS, WINS, etc.). Are Offline Files
enabled?

If you've got a situation where sometimes it works and sometimes it doesn't
then a quick path to resolution would be to use Network Monitor or some
other packet sniffer to determine exactly what it's doing when it works and
what it's doing when it fails.

--
J.C. Hornbeck, MCSE
Microsoft Product Support

NOTE: Please reply to the newsgroup and not directly to me. This allows
others to add to and benefit from these threads and also helps to ensure a
more timely response. Thank you!

This posting is provided "AS IS" without warranty either expressed or
implied, including, but not limited to, the implied warranties of
merchantability or fitness for a particular purpose.

We are seeing some servers where the ability to resolve the name is not
enough to get windows networking going. Only by using WINS (or lmhosts) is
networking reliable. What is truly needed to get rid of NetBIOS once and
for all. Here is an example of what I am seeing. I have done search and
replaces to change the server name and domain names and the IP address but
other than that, the following is what I am seeing. As another note, some
days things work great. Thanks in advance:

C:\>ping computer

Pinging computer.root.domain.com [10.10.10.10] with 32 bytes of d

Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126
Reply from 10.10.10.10: bytes=32 time<10ms TTL=126

Ping statistics for 10.10.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>dir \\computer\c$
The network path was not found.

C:\>dir \\10.10.10.10\c$
Volume in drive \\10.10.10.10\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\10.10.10.10\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free

C:\>rem add entry into lmhosts

C:\>dir \\computer\c$
Volume in drive \\computer\c$ has no label.
Volume Serial Number is C81D-B304

Directory of \\computer\c$

10/02/2003 01:01p 0 AUTOEXEC.BAT
10/02/2003 01:01p 0 CONFIG.SYS
03/01/2004 04:47p <DIR> Documents and Settings
01/16/2004 02:43p <DIR> Program Files
03/18/2004 08:44p <DIR> quarantine
02/19/2004 02:33p <DIR> WINDOWS
2 File(s) 1,941,754 bytes
4 Dir(s) 3,903,488,000 bytes free


C:\>

 

[Guest]

:

....

are trying to get rid of wins and go DNS only. This issues only occurs with
servers that are not registering in WINS. Resolution works great but
networking does not always.

Does not registering in WINS mean that the node type is remains broadcast, and that fails to open a server where DNS or IP address succeeds?
We have a similar problem, even with the use of LMHOSTS. I wish I understood under which conditions a 2000 client uses broadcast NetBIOS name resolution and nothing else.