• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

DNS Lookup Issues

dclive

Elite Member
Bluescreens and memory dumps and deployment I like; networking I admit I have much to learn.

Here we go....

If I have a server, ei3000, 2003 Server box, and a client, ei1, XP Pro SP2 box, and on the ei1 client I type start/run \\ei3000, a window appears with nothing inside of it - in other words, the typical explorer window that would show all the computer's shares appears, but it's empty.

If I type the FQDN, ei3000.ei.com, I see the ei3000 server computer with all of the computer's shares, as I would expect.

If I type \\ei3000 from computer ei3000, the shares are presented normally; no FQDN is required.

Naturally, this causes all kinds of problems - DFS doesn't work (\\ei.com doesn't give a list of all DFS shares, but does show \\ei3000's shares when you do a start-run on ei3000...); mapped drives (on ei1, I have a drive mapping to, say, \\ei3000\c$ - it's totally empty) have issues, and so forth.

Can anyone offer any suggestions? DNS, DHCP, DFS are all done via EI3000, the 2003 Server box. EI3000 has a single NIC; the NIC's TPCIP properties have DNS pointing back to itself (first), and pointing to my ISP's DNS server (second). DNS is set to forward to my ISP's DNS server. Doing a ping on EI1 successfully resolves and pings EI3000; FQDN is not required. Doing an NSLOOKUP on EI1 successfully resolves EI3000; FQDN is not required. Doing a remote desktop from EI1 to EI3000 works successfully by name.

If I go from EI1 to MCE2005, a Media Center box (not in a domain), it shows its' drives just fine.

🙁

Anyone?
 
Can you post


1)Your DNS Servers IP and DNS Settings

2)Your Clients IP and DNS Settings

3)post nslookup output on the Server ad well as on the client ?

Honestly , it just sounds like you need to add the DNS Suffix on the client computer in DNS Properties of the Client NIC , but that could just be me 🙂

I'm just asking for the INFO , because the information wasn't completely clearly put through 🙂
 
1. DNS server is the same as the 2003 server (it's DNS, DHCP, etc.). The IP is 192.168.3.4. Router is 192.168.3.1. DNS settings are primary (127.0.0.1), no secondary.

2. Client IP is 192.168.3.126; DNS is 192.168.3.4, DHCP is 192.168.3.4, default GW is 192.168.3.1.

3. nslookup of server, from client:
C:\>nslookup ei3000
*** Can't find server name for address 192.168.3.4: Non-existent domain
*** Default servers are not available
Server: UnKnown
Address: 192.168.3.4

Name: ei3000.ei.com
Address: 192.168.3.4


nslookup of client, from server:
M:\>nslookup ei1
Server: localhost
Address: 127.0.0.1

Name: ei1.ei.com
Address: 192.168.3.126

I'm using ei.com, but I'm not actually ei.com (it's a made up name, and it conflicts with www.ei.com, whoever actually registered it on the public internet, but since queries should be handled internally by my internal DNS server, it shouldn't be an issue...right?)
 
And on the client NIC if I add "append these dns suffixes in order" and add ei.com, still no go.... nothing changes.

Again, basic issue: Start/run/ei3000 (servername) on client results in empty window showing no shares on server. Start/run/ei3000.ei.com (FQDN servername) on client results in window showing all normal shares on server.

Why is it different? How do I get just ei3000 to work and to resolve to the right name?
 
Oh, and I do have a reverse lookup zone, and it *looks* OK...ei1 is in there with its' appropriate IP address, and ei3000 itself isn't directly listed there, but the second entry is (same as parent folder) .. Name Server (NS) ... ei3000 - and 2x clicking on it shows the correct IP address, with an asterisk stating it was found via DNS query.

It appears this is a client problem. MCE2005, another machine I have that's been largely untouched for months and months, *can* type start\run, key in ei3000, and *does* get a listing of all the shares on the machine (after authenticating against the server).

So why would a machine that is not a part of the domain be able to see the shares, but a machine that is part of the domain (ei1) not be able to see ei3000's shares, without manually keying in the FQDN?
 
To use Netbios names I believe you need either WINS or an updated (accurate) LMHosts file.

I would either start WINS or take a look into the LMHosts file. Use Nbtstat -c to see the Netbios names and their resolved IP addresses.

I don't believe this is a DNS issue at all because FQDN's work fine. This is a NetBIOS thing and windows client's will look for a WINS or LMHosts file before looking to DNS.
 
Unfortunately, I am not sure I can agree with that. This works sometimes, so it's something that is happening on either the client or the server. I've got another client machine, ei4, that I'm having the same issue on, and historically this did work for some time until something happened. NSLOOKUP *does* know that ei3000 is 192.168.3.4, and ping does know that ei3000 is 192.168.3.4, so name lookup is working, but something else is going wrong.
 
I can also state that this happens at some times and not others - in other words, rebooting can cause it to then work for the duration of that bootup, and then after a reboot it might be back to not pulling anything up by typing //ei3000 (//servername). VERY frustrating.

All clients are built via the RIS process, and all are very similar, but don't use identical NIC drivers nor do they have identical hardware.

All get DNS information from the same DHCP server, ei3000.

VERY frustrating.

However, normal services that depend heavily on DNS and DHCP (say, Microsoft's RIS - Remote Installation Services - used to build all of these machines) works just fine. So does group policy and software installation via group policy.

Any suggestions?
 
Originally posted by: nukexbi
To use Netbios names I believe you need either WINS or an updated (accurate) LMHosts file.

I would either start WINS or take a look into the LMHosts file. Use Nbtstat -c to see the Netbios names and their resolved IP addresses.

I don't believe this is a DNS issue at all because FQDN's work fine. This is a NetBIOS thing and windows client's will look for a WINS or LMHosts file before looking to DNS.

Here is NBTSTAT output: (On my NIC I've turned off NetBIOS over TCPIP; the problems haven't changed.)

M:\>nbtstat -c

VMware Network Adapter VMnet8:
Node IpAddress: [192.168.56.1] Scope Id: []

No names in cache

VMware Network Adapter VMnet1:
Node IpAddress: [192.168.75.1] Scope Id: []

No names in cache

Local Area Connection:
Node IpAddress: [192.168.3.126] Scope Id: []

NetBIOS Remote Cache Name Table

Name Type Host Address Life [sec]
------------------------------------------------------------
EI3000.EI.COM <20> UNIQUE 192.168.3.4 80

Does that help with anything?
 
you need netbios for browsing.

make sure it is enabled on every single computer. Otherwise you'll get exactly the symptoms you're seeing.

this isn't a DNS problem, it is a netbios/browsing problem.

also, rebooting machines will only make your problem worse. It can take hours for all the browsing stuff to get settled. If you want rock solid "network neighboorhood" you'll enable WINS on your server and point all the clients to that for netbios name resolution.
 
Originally posted by: spidey07
you need netbios for browsing.

make sure it is enabled on every single computer. Otherwise you'll get exactly the symptoms you're seeing.

this isn't a DNS problem, it is a netbios/browsing problem.

Why would it alternate, working and not working, over reboots, even when I haven't changed anything?

In any case, I've explicitly enabled NetBIOS over TCPIP on both server and client.

No change. 🙁 From the client, keying in \\ei3000 still shows the machine as "empty" with no shares. Keying in \\ei3000.ei.com shows all of the shares.
 
Full IPCONFIG /all Info:

M:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : ei1
Primary Dns Suffix . . . . . . . : ei.com
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : ei.com
ei.com

Ethernet adapter VMware Network Adapter VMnet8:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for
VMnet8
Physical Address. . . . . . . . . : 00-50-56-C0-00-08
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.56.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet1:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for
VMnet1
Physical Address. . . . . . . . . : 00-50-56-C0-00-01
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.75.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : ei.com
Description . . . . . . . . . . . : NVIDIA nForce Networking Controller
Physical Address. . . . . . . . . : 00-30-1B-35-2D-1E
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.3.126
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.3.1
DHCP Server . . . . . . . . . . . : 192.168.3.4
DNS Servers . . . . . . . . . . . : 192.168.3.4
Lease Obtained. . . . . . . . . . : Sunday, February 26, 2006 2:51:53 PM

Lease Expires . . . . . . . . . . : Monday, March 06, 2006 2:51:53 PM

(from EI1)

and from EI3000, the server:

Windows IP Configuration

Host Name . . . . . . . . . . . . : ei3000
Primary Dns Suffix . . . . . . . : ei.com
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : Yes
DNS Suffix Search List. . . . . . : ei.com

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VIA Rhine II Compatible Fast Ethernet Ada
pter
Physical Address. . . . . . . . . : 00-0E-A6-73-44-D3
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.3.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.3.1
DNS Servers . . . . . . . . . . . : 127.0.0.1

 
Originally posted by: dclive
Originally posted by: spidey07
you need netbios for browsing.

make sure it is enabled on every single computer. Otherwise you'll get exactly the symptoms you're seeing.

this isn't a DNS problem, it is a netbios/browsing problem.

Why would it alternate, working and not working, over reboots, even when I haven't changed anything?

In any case, I've explicitly enabled NetBIOS over TCPIP on both server and client.

No change. 🙁 From the client, keying in \\ei3000 still shows the machine as "empty" with no shares. Keying in \\ei3000.ei.com shows all of the shares.

Because that is the nature of "network neighboorhood". It is enherently flaky. what you are desribing is so common I could probably write a book about it. Also many people troubleshoot this by restarting machines and that makes it worse. then they pull out their hair and yell and scream when if they just let things settle down (it can take hours) all will be ok.

post the output of "net config server" and "net config workstation" of every computer. Somebody out there isn't running netbios over TCP.

If you search "troubleshoot microsoft browser netbios" you'll find tons of info from google.

But running WINS on your server will take care of it and is probably what you should do anyway rather than any more frustration.

now, repeat after me...
Thou shalt not use network neighboorhood, thou shalt use UNC or FQDN when referencing another computer.
🙂
 
I see your problem. NODE TYPE

You need the clients and servers to be netbios broadcast nodes. You set this via DHCP, option 8 I believe.

Or you just load up WINS, make everybody a hybrid node and never have this problem ever again.
 
Originally posted by: spidey07
I see your problem. NODE TYPE

You need the clients and servers to be netbios broadcast nodes. You set this via DHCP, option 8 I believe.

Or you just load up WINS, make everybody a hybrid node and never have this problem ever again.

I went to option 46 and set note type to 0x8, hybrid, and did an ipconfig /release and ipconfig /renew, no change in behavior.

C:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : ei1
Primary Dns Suffix . . . . . . . : ei.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : ei.com
ei.com

So then I set up a WINS server, kept option 46 as shown above in DHCP, and set option 44 (WINS Server IP Address) so clients will know where the WINS server is.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : ei.com
Description . . . . . . . . . . . : NVIDIA nForce Networking Controller
Physical Address. . . . . . . . . : 00-30-1B-35-2D-1E
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.3.126
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.3.1
DHCP Server . . . . . . . . . . . : 192.168.3.4
DNS Servers . . . . . . . . . . . : 192.168.3.4
Primary WINS Server . . . . . . . : 192.168.3.4
Lease Obtained. . . . . . . . . . : Sunday, February 26, 2006 4:18:07 PM

Lease Expires . . . . . . . . . . : Monday, March 06, 2006 4:18:07 PM

Shares of \\ei3000 still aren't shown on the client.

 
Originally posted by: spidey07
[now, repeat after me...
Thou shalt not use network neighboorhood, thou shalt use UNC or FQDN when referencing another computer.
🙂


I *AM*. Throughout all of this, I've been explicit - I'm using \\ei3000 to 'hit' the client. That typically fails, and \\ei3000.ei.com works.

Edit: Sorry; don't mean to be mean; just frustrated. I just now rebooted, and it (start/run/\\ei3000<enter>) now brings up all shares, when done from ei1.

Agggh! 🙁
 
I repeat...

it can take hours for things to work properly and it can be inherently flaky.

have you loaded that WINS server yet? It will end all your frustration.

look at your server logs, you'll see a bunch of netbios elections going on.

also, without running a WINS server your node type needs to be broadcast. But i'm sure you've loaded that wins server and pointed your clients to it.
🙂

-edit- oh, read your comments.

whenever a change is made to any network configuration a reboot is normally a good idea even though windows doesn't ask for one. glad it works now.

the reason being is all that stuff about browsing and who has the browse list/announcements, what protocols are running what services, etc is done on startup.
 
See above - WINS server didn't change anything. See message 3 posts above this one and you'll see full details. 🙁
 
Originally posted by: spidey07
-edit- oh, read your comments.

whenever a change is made to any network configuration a reboot is normally a good idea even though windows doesn't ask for one. glad it works now.

the reason being is all that stuff about browsing and who has the browse list/announcements, what protocols are running what services, etc is done on startup.

1. It's worked after reboots before; I have no reason to believe it will consistently work now.
2. No errors are shown in the EI3000 logfiles WRT browsing, elections, or any related items. In fact, there are no errors today (well, couldn't register DNS, please ignore this if you don't have any DNS replicas (and I don't, so I ignored it)..but no other errors.)

🙁
 
I am confident that if you are running a wins server, have node type set to hybrid, have netbios bound to TCP and verifyed with "net config server" and "net config workstation" on all clients and have restarted all machines that you will no longer have a problem.
 
Originally posted by: dclive
Originally posted by: nukexbi
To use Netbios names I believe you need either WINS or an updated (accurate) LMHosts file.

I would either start WINS or take a look into the LMHosts file. Use Nbtstat -c to see the Netbios names and their resolved IP addresses.

I don't believe this is a DNS issue at all because FQDN's work fine. This is a NetBIOS thing and windows client's will look for a WINS or LMHosts file before looking to DNS.

Here is NBTSTAT output: (On my NIC I've turned off NetBIOS over TCPIP; the problems haven't changed.)

M:\>nbtstat -c

Local Area Connection:
Node IpAddress: [192.168.3.126] Scope Id: []

NetBIOS Remote Cache Name Table

Name Type Host Address Life [sec]
------------------------------------------------------------
EI3000.EI.COM <20> UNIQUE 192.168.3.4 80

Does that help with anything?
Nbtstat is used to display NetBIOS over TCP/IP. I would turn it back on.
The only item listed is a FQDN. For things to work smoothly you should see NetBIOS names there.

I think Spidey07 has the right idea with the WINS server. Or you could create a LMHosts file for each computer (as long as everything you need is on the same domain.) I like the idea of using the LMHosts cache as it also reduces broadcast traffic.

Here is the MS link for creating LMHost files:
How To Write a LMHosts File

 
Originally posted by: nukexbi
Nbtstat is used to display NetBIOS over TCP/IP. I would turn it back on.
The only item listed is a FQDN. For things to work smoothly you should see NetBIOS names there.

I think Spidey07 has the right idea with the WINS server. Or you could create a LMHosts file for each computer (as long as everything you need is on the same domain.) I like the idea of using the LMHosts cache as it also reduces broadcast traffic.

Here is the MS link for creating LMHost files:
How To Write a LMHosts File

I have turned NetBios over TCPIP on and off; it makes no difference.

I did make a WINS server; it appeared to make no difference, then I rebooted, and I could then see shares on \\ei3000, but I've been able to rotate between working and not working all weekend, so that doesn't necessarily mean the WINS server presence fixed things.

I'm completely and totally against using LMHOSTS. The entire point of a modern LAN is to centralize management; having to update a textfile on client machines is...anathema. 🙂 Yes, I'm familiar with editing it.

Please understand - I can resolve EI3000 all the time - ping ei3000 ALWAYS resolves successfully.

 
Originally posted by: dclive
Also, it seems MS is saying WINS is obsolete for post-Win2k builds -
http://support.microsoft.com/default.aspx?scid=kb;en-us;323357

In any case:
1. I have a WINS server going now
2. I have hybrid node turned on (0x8 on 46 or 44, IIRC)
3. It appears to be working on this reboot

you are correct, that is the MS official answer.

but if you look at packet traces of micrsoft networking there is a TON of netbios type activity still going on.
 
Originally posted by: dclive
I'm completely and totally against using LMHOSTS. The entire point of a modern LAN is to centralize management; having to update a textfile on client machines is...anathema. 🙂
I suppose you are right. But where I work the domain users are added to the local admins group of their pc.... Centralized management? What's that? 😛 I guess I'm used to it.

 
Back
Top