Mapping NT4 share drives on other segment

I have an Active Directory network with a NT4 file server on a different IP segment. Everything works fine until yesterday, all of a sudden, MOST of the user cannot map drives on that server. Mapping drive using IP address or FQDN is fine but not NetBIOS name. I peek the network traffic Ethereal from my XP and noticed that my XP ONLY try to connect using port 445 but not port 139. It is wierd because both ports should be tried at the same time according to the document. If I add the server to my LHOST, it works. If I remove it, it fails.

Anybody has a clue?

 

What is your node type set at? (Listed in an IPCONFIG /ALL output)

 

Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No

 

If you run DHCP and WINS on the NT4 server (which I would recommend) add the following scope options:

044 "“ WINS/NBNS Servers. Map to IP address of WINS Server
046 "“ WINS/NBNS Node Type. Map to Hybrid "“ 0x8

Once you've made the change on the server, use IPCONFIG /RENEW on the workstations so they get then new settings immediately rather than waiting for the next lease renewal.

 

We use static IP and no WINS. Except that the file server is itself a WINS server but nobody is using it. The strange thing is that this configuration has been working for a year until couple days ago, without any changes.

 

WINS works really well in an NT4 network. It is the best application for Network Neighbourhood performance. I am confident that if you set up your PCs to use it you'll get a significant performance improvement when browsing the network. If you want to stick with static IPs, you can set the systems to use the WINS server. To do this, go into the TCP/IP properties on the network interface and click on the Advanced button. Then on the WINS tab, enter the NT4 Server's IP address. Then the next time the system reboots, it will add an entry to the WINS database. As the database grows, your network performance will improve.

Personally, I'd set up DHCP and use this as an opportunity to switch everyone away from static IPs. DHCP makes changing everyone's IP settings simple. It is much easier to manage a network with DHCP rather than use static addresses.

 

For my case, since such a configuration has been working for years, is it possible that something that has been cached somewhere else expired such that most (not all) of our users cannot use NetBIOS to access shares in a NT4 server? It is wierd that those failed workstations never try to access the server using port 139 until we add the name in the LMHOSTS file.

Following is the Ethereal output:

No. Time Source Destination Protocol Info
18 4.075976 172.28.64.185 10.5.50.1 ICMP Echo (ping) request
20 4.077004 10.5.50.1 172.28.64.185 ICMP Echo (ping) reply
21 4.077131 172.28.64.185 10.5.50.1 TCP 4767 > microsoft-ds [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
22 4.078452 10.5.50.1 172.28.64.185 TCP microsoft-ds > 4767 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
23 4.536314 172.28.64.185 10.5.50.1 TCP 4767 > microsoft-ds [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
24 4.537602 10.5.50.1 172.28.64.185 TCP microsoft-ds > 4767 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
31 5.037021 172.28.64.185 10.5.50.1 TCP 4767 > microsoft-ds [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
32 5.038228 10.5.50.1 172.28.64.185 TCP microsoft-ds > 4767 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
37 6.352081 172.28.64.185 10.5.50.1 ICMP Echo (ping) request
38 6.352611 10.5.50.1 172.28.64.185 ICMP Echo (ping) reply
39 6.352743 172.28.64.185 10.5.50.1 NBNS Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
48 7.851078 172.28.64.185 10.5.50.1 NBNS Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
61 9.353236 172.28.64.185 10.5.50.1 NBNS Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>

 

Yes.

You can spend a lot of time trying to find the precise cause of the problem - a task you are likely not to succeed at - or you can use WINS to get round the problem.

 

Thanx for your advice. Actually, our workaround is to change all logon batches to mount by FQDN.

 

Or come up with another workaround that better suits your situation.

Well done.