After much thought and some reading I now have a--very tentative--theory
about what may be happening but absolutely no idea what to do about it.
I suspect that ping--and the name resolution used by terminal server in
Win2k has changed with Win2K SP4.
My memory (which is far from perfect however) tells me that prior to
installing SP4 a ping command on the server to a client returned
something like the following:
Pinging sample_client [172.XX.XXX.XX] with 32 bytes of data:
where 172.XX.XXX.XX was the "tunnel" ip assigned by VPN on the server.
The ping worked and so did terminal server by machine name.
Now a ping returns the FQDN as follows:
Pinging sample_client.mydomain.mydnsdomain.XXX.XX [192.168.1.XXX] with
32 bytes of data:
where 192.168.1.XXX is the DHCP address supplied to the client by a home
router.
Tracing route to paquette_home.edpol.edu.uwo.ca [192.168.1.100]
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms vnn-nnn-nnn-nn-m1.l1uc00-1.nn.nn.nn
[129.xxx.xx.x]
2 <10 ms <10 ms <10 ms Vmm-mmm-mm-m-M2.l1nsc00-1.mm.mm.mm
[129.yyy.yyy.yy]
3 * * * Request timed out.
4 * * * Request timed out.
etc.
where 129.xxx.xx.x and 129.yyy.yyy.yy are domain-name servers.
So my current best theory is that with SP4, ping--and terminal server--
add the full DNS qualification to the basic NETBios name which causes
h-mode name resolution to bypass NETBios name resolution entire. Thus
the fact that WINS has the correct VPN-assigned address for the client
becomes irrelevant. NETBios name resolution is simply skipped because
the name is over 15 characters long.
Three questions:
1. Does anyone know if SP4 for Win2k alters the way ping and
applications search on machine names so as to add domain qualifiers?
2. Does my theory of what is happening sound pausible?
3. What, if anything, short of unistalling SP4, this is, if I'm correct
that SP4 is the culprit here, can be done to avoid having the domain
qualifiers added before sending a machine name fo name resolution?
(I assume remote access from the server to client folders and files
still works because remote file access is a separate "file-server"
process which doesn't add the domain qualifiers.)
Thanks for any help on this!!!!
Jerry Paquette wrote:
> For many years I have had VPN set up, first on my NT server, now on my
> Win2K server. It has worked very well in conjunction with WINS to
> provide, among other things, both file browsing into remote clients from
> the server and terminal service client connections into certain clients.
>
> I recently had to go back to a two-month-old image and restore one of
> the clients although that shouldn't have any effect on other clients
> relationship with VPN/WINS. I also installed SP4 on the server.
>
> Now WINS won't do name resolution back to clients--well, more precisely,
> it will do it for folder and file browsing but not for pinging and
> terminal service client connection. The WINS server active
> registrations shows correct VPN provided ip for client workstation and
> file server (as below) and file browsing works even after disconnects
> and reconnects which use different IPs from my static DHCP server. But
> I can no longer ping to client (ping on name resolves to ip of
> local--remote home routers not VPN ip as it always did in the past).
>
> Any idea what's wrong here?
>
> Example WINS active resgistration entries:
>
> SAMPLE_CLIENT [00h]WorkStation 172.XX.XXX.XX
> SAMPLE_CLIENT [20H]FileServerc 172.XX.XXX.XX
>
> The ip's are correct VPN ips and can be pinged to and terminal server
> sessions can be established on them.
>
|