Hiya,
One of my customers has a 3-site network, recently connected by a VPN ISP, using a packet-labelling protocol (I believe it is MPLS), not PPTP, IPSec or similar tunneling protocols. Ping response times across the VPN are good to very good, on the order of 30ms to Site B and 120ms to Site C. They have a single NT4 server at Site A, which all of Site A's clients log into without issue. The clients at Sites B and C have never logged into the server, but the IS Dept. wants them to do so.
Users at the remote sites get the "domain controller could not be found" message every single time. The server does not appear in Network Neighborhood, so the users didn't know how to get to the files on the server. The remote client can ping the server, they can find the server via the "Find Computer" function using it's IP address, and can access the resources (see the files etc).
As a temporary workaround I dropped a shortcut on the remote user's desktop pointing to \\10.10.10.1, the address of the NT server. Once the user has put in his/her password, the "DC not found" message comes up, the user double-clicks this shortcut to access the server files. It is a slow workaround (even on the local subnet it takes 5 seconds or so for the server's folder list to appear, 15-20 secs across the VPN) but it does work reliably.
There is a properly configured LMHOSTS file on the remote system listing the server name, the domain etc. with preloading. I could set up WINS but I thought it doesn't make sense because there is only 5 clients or so at each of Sites B and C so LMHOSTS would be easy to administer.
So I end with these questions:
How can I make the remote clients be able to log in to the server without getting the "DC not found" message?
If LMHOSTS is present and configured correctly, are the systems listed in it supposed to show up in Network Neighborhood?
Does WINS work properly over routers? I've heard both yes and no.
Is there some sort of timeout setting that determines how long a client waits for the DC to respond? I would think that if it is a timeout issue (unlikely with 30ms pings) that extending the timeout value might resolve the problem.
One of my customers has a 3-site network, recently connected by a VPN ISP, using a packet-labelling protocol (I believe it is MPLS), not PPTP, IPSec or similar tunneling protocols. Ping response times across the VPN are good to very good, on the order of 30ms to Site B and 120ms to Site C. They have a single NT4 server at Site A, which all of Site A's clients log into without issue. The clients at Sites B and C have never logged into the server, but the IS Dept. wants them to do so.
Users at the remote sites get the "domain controller could not be found" message every single time. The server does not appear in Network Neighborhood, so the users didn't know how to get to the files on the server. The remote client can ping the server, they can find the server via the "Find Computer" function using it's IP address, and can access the resources (see the files etc).
As a temporary workaround I dropped a shortcut on the remote user's desktop pointing to \\10.10.10.1, the address of the NT server. Once the user has put in his/her password, the "DC not found" message comes up, the user double-clicks this shortcut to access the server files. It is a slow workaround (even on the local subnet it takes 5 seconds or so for the server's folder list to appear, 15-20 secs across the VPN) but it does work reliably.
There is a properly configured LMHOSTS file on the remote system listing the server name, the domain etc. with preloading. I could set up WINS but I thought it doesn't make sense because there is only 5 clients or so at each of Sites B and C so LMHOSTS would be easy to administer.
So I end with these questions:
How can I make the remote clients be able to log in to the server without getting the "DC not found" message?
If LMHOSTS is present and configured correctly, are the systems listed in it supposed to show up in Network Neighborhood?
Does WINS work properly over routers? I've heard both yes and no.
Is there some sort of timeout setting that determines how long a client waits for the DC to respond? I would think that if it is a timeout issue (unlikely with 30ms pings) that extending the timeout value might resolve the problem.
