drive map NTW4 to NTSvr4\different IP groups

Posted on 1998-03-31
Last Modified: 2013-12-23
I resently upgraded to NT 4 Workstation from Win95 and wish to map drives to some NT Servers i have. I could connect to the servers under 95 but now can't see them. The servers have  internet IP addresses and i have an
internal 192 address. I am running TCP\IP and NetBEUI, the servers are running the same protocols.
I can ping the servers using their addresses and with their names. Yet i can't see them in the network neighbourhood. I can see all the other Win95 pc's on the network, but not my servers.
If i can ping them then why can't i connect to them? if i try  it manually using "net use \\realtime1\rt1_cdriv" it
comes up with error 53.
Question by:adriand033198
  • 3

Author Comment

ID: 1571701
Adjusted points to 50

Author Comment

ID: 1571702
Adjusted points to 100

Expert Comment

ID: 1571703
Try the following:
Start-Run- enter: \\servername
You should get a list of all network shares of this server.
at the DOS-Prompt enter: net view -> you get a list of all servers and WS in your domain/workgroup,
net view \\servername -> same as the first test (see above )

Accepted Solution

biyiadeniran earned 110 total points
ID: 1571704
When you attempt to connect to a Fully Qualified Domain Name (FQDN) from a
Windows NT computer, you may receive the following error message:
   System error 53 has occurred. The network path was not found.
NOTE: You may also receive this error if you misspell the name of the
remote computer.
When you attempt to establish a NetBIOS over TCP/IP connection (such as a
file share or print share) to a remote computer, your computer must:
 - Locate the IP address for the remote computer.
 - Establish a TCP/IP connection to the remote computer.
 - Establish a NetBIOS session to one of the NetBIOS names registered on
   the remote computer.
Windows NT 4.0 computers use the following logic when using a FQDN for this
process: (for example, when you type "net use \\\public")
 - Use a DNS or hosts file to locate the IP address for
 - Establish a TCP/IP connection to that IP address.
 - Try to establish a NetBIOS session to the NetBIOS name "host1".
 - If that fails, send an Adapter Status Query to the IP address, and parse
   the returned NetBIOS name table for the server name.
 - Establish a NetBIOS session to the server name.
For cases when the hostname does not match the NetBIOS (server) name, this
process relies upon the Adapter Status Query, which is a UDP datagram sent
to UDP port 137. In some cases, such as certain firewall environments, the
Adapter Status Query may fail.
To resolve this problem, obtain the following fix or wait for the next
Windows NT service pack.
This fix should have the following time stamp:
   10/22/97  12:25p  263,824 Rdr.sys  (i386)
   10/22/97  12:22p  510,352 Rdr.sys  (alpha)
An updated version of Rdr.sys offers a new registry parameter to slightly
change the above logic:
 - Use a DNS or hosts file to locate the IP address for
 - Establish a TCP/IP connection to that IP address.
 - Try to establish a NetBIOS session to the NetBIOS name "host1".
 - If that fails, try to establish a NetBIOS session to the NetBIOS name
   "*SMBSERVER      ".
Please see the following article in the Microsoft Knowledge Base for more
information on the *SMBSERVER name and why it is registered on Windows NT
   ARTICLE-ID: Q161431
   TITLE     : Connecting to NetBIOS Resources Using DNS Names or IP
The new registry parameter that allows control of this behavior is:
   Value: FqdnUsesSmbServerName
   Key: HKLM\CurrentControlSet\Services\Rdr\Parameters
   Value Type: REG_DWORD - Boolean
   Valid Range: 0,1 (False,True)
   Default: 0 (False)
   Description: Setting this parameter to "1" causes your computer to try a
                NetBIOS session to the name "*SMBSERVER      " instead of
                using an Adapter Status Query when the hostname part of a
                FQDN does not match the NetBIOS computername on the target
NOTE: Service Pack 3 must be applied to Windows NT 4.0 prior to applying
this fix.


Author Comment

ID: 1571705
Thanks alot. I figured it out from what you said. The domain name was just set incorrectly, stupid mistake A. Well sometimes it is the simplest thing, but thanks for making my brain look in the right place.

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Sometimes you might need to configure routing based not only on destination IP address, but also on a combination of destination IP address (or hostname) and destination port number. I will describe a method how to accomplish this with free tools. …
This article is in response to a question ( here at Experts Exchange. The Original Poster (OP) requires a utility that will accept a list of IP addresses …
Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…
Many functions in Excel can make decisions. The most simple of these is the IF function: it returns a value depending on whether a condition you describe is true or false. Once you get the hang of using the IF function, you will find it easier to us…

867 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now