"boe" <(E-Mail Removed)> wrote in message
news:#hS#(E-Mail Removed)...
> Any guesses as to why when a VPN client clicks on a file to copy it, it
> usually takes about 20 seconds before the file begins to transfer? Are
> throughput seems fine and the ping time seem good but it is the initial
> copying that takes a while. Once the server begins the transfer it is
very
> quick.
Just some rambling thoughts based on the way such
works and the general likelyhoods...
If the Server SHARES are displayed in the Browser then
likely the Server has been contacted and thus it's name
resolve -- it might have passed TTL but that is unlikely --
as you get the list of shares from the Server itself.
So, something else is likely causing the problem --
perhaps authentication?
If it's authentication, then perhaps it is a (further) name
resolution problem since most such authentication delays
are really name resolution issues.
Also this would (likely) be worse if you had multiple
domains -- users in one, server in another -- because
theis requires the Users to follow Kerberos ticket
referrals or for the DCs to follow trusts if external to
the forest.
(Check your DNS thoroughly.)
The following is targetted at DNS for AD, not VPNs, but it
all must work for a Win2000+ Domain plus the VPN clients
must ALSO be able to use it.
DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domain (either directly or indirectly)
Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.
Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.
Perhaps try NetDIAG on the client machines.
--
Herb Martin
>
> Thanks
>
>
|
Similar Threads
Linear Mode
