DFS latency when used in WAN environment

[Ron Garon]

We have fully embraced DFS/FRS in our enterprise to help share common data
with a common drive letter among remote facilities. We have a DFS Root
hosted by the corporate office that all facilities map to their W: drive
This W: drive contains links to other DFS roots which are hosted by remote
facilities.
When a user in a remote facility tries to open large CAD assemblies
comprised of over 100 parts from the W: drive it takes over 12 minutes to
complete, even though the files are on his local server. When the DFS
environment is bypassed by opening the same assembly from his local server
using the servers UNC path (the same place DFS previously redirected him)
the time is cut to 5 minutes.
When opening the files the user takes 3 DFS redirects: \\Corp
Root\Remote Root 1\Remote Root 2\folder1\folder2\file.xxx
The Corp Root and the Remote Root 1 are in different facilities accessed
over the WAN using T1 circuits. Remote Root 2 is in his facility and
contains the files he is opening.
As an experiment, two additional servers were built to host the Root
Replicas accessed over the WAN. One for Corp Root and the second for Remote
Root 1. These servers were added to the users local LAN or Site. With Root
replicas for all of the DFS Roots now in his site, the open file command was
cut down to just under 4 minutes, faster than the local UNC call.
My questions are: 1) is it necessary to host root replicas for all of
the DFS Roots in our enterprise in each facility to speed local file access
through DFS? 2) Why is DFS a bottleneck when the Roots are remote but the
files local? 3) If the client downloads the PKT Cache during it's initial
DFS call, which contains all of the redirect information, why does it
continually go over the WAN back to the remote DFS roots during the open
file session?

 

[Arif Saifee [MSFT]]

Let's take the example of \\Corp\Root\Remote Root1\RemoteRoot2\folder1
In this case, the client has to figure out which root server hosts
\\Corp\Root. I assume this is a domain based root. This will cause the
client to contact the nearest *DC* of the domain Corp. The DC will then
redirect it to the root server which hosts the domain based root "Root". So
if the nearest DC is on the WAN, there's your first bottleneck. Next, the
client asks the root server to figure out where the link "RemoteRoot1"
points to. If Remote Root1 points to another domain based root, say
\\Corp\RemoteRoot1", the whole process is repeated to figure out which root
server hosts \\Corp\RemoteRoot1.
The same goes for the other root "Remote Root2".

So the answer to your questions:
1) Yes, to speed up access to a domain based root, it is advisable to put a
root replica and a *DC* in the client's local site.
2) The explanation above should explain the bottleneck.
3) The client should not be going over to get fresh information, if the info
is already in its cache, *except when the cache expires*. The cache has a
default expiry of 300 seconds. Note that if you access a file while the
cache is active, the cache timer is reset. So if the cache was to expire in
10 seconds and someone accessed a file via the cache, the timer will again
read 300 seconds. You can increase the timeout on the link by using the
NetDfsSetInfo() API. Are you saying that the client always goes over the
WAN, no matter what? Can you verify that it only does this when its local
cache expires?


--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

 

[Ron Garon]

Thank you for your response. Please allow me to elaborate. All of the
Roots are domain based and are in the same domain and each in a different
site. Each site has a *DC*. Each server and client is Win2K with SP3.
What we are experiencing is that when a user opens a CAD assembly which is
comprised of over 100 individual parts or files through the DFS file
structure it is VERY slow, even though the data is on the users local
server. Because our goal is to get all users in our enterprise to use the
same drive letter and path for their data, we have implemented a DFS
'hierarchy. When the user in question opens his CAD assembly it is coming
from the following DFS path:

W:\Link_to_DFS_Root_1\Link_to_DFS_Root_2\folder1\folder2\file.xxx

W:\ (this is mapped to the DFS Root at Corporate HQ which is in a remote
site)
Link to DFS Root 1 (this root is also in a remote site)
Link to DFS Root 2 (this root is in the users site)
folder1\folder2\file.xxx

The user is navigating 3 DFS Roots before he gets to the files he wants to
open.

When we perform a dfsutil /pktinfo the entire DFS hierarchy is resolved, but
the open file session is still VERY slow. The cached information is not
expiring during this open file session, so where could the bottleneck be
except for the continual AD and DFS calls? By building a DFS Root Replica
for each root and placing it in the users site did we take away the
continual AD and DFS calls or just move them to the local site?

BTW - Thank you for the FRS Monitoring tool SONAR.EXE. It is very useful
!!

Let's take the example of \\Corp\Root\Remote Root1\RemoteRoot2\folder1
In this case, the client has to figure out which root server hosts
\\Corp\Root. I assume this is a domain based root. This will cause the
client to contact the nearest *DC* of the domain Corp. The DC will then
redirect it to the root server which hosts the domain based root "Root". So
if the nearest DC is on the WAN, there's your first bottleneck. Next, the
client asks the root server to figure out where the link "RemoteRoot1"
points to. If Remote Root1 points to another domain based root, say
\\Corp\RemoteRoot1", the whole process is repeated to figure out which root
server hosts \\Corp\RemoteRoot1.
The same goes for the other root "Remote Root2".

So the answer to your questions:
1) Yes, to speed up access to a domain based root, it is advisable to put a
root replica and a *DC* in the client's local site.
2) The explanation above should explain the bottleneck.
3) The client should not be going over to get fresh information, if the info
is already in its cache, *except when the cache expires*. The cache has a
default expiry of 300 seconds. Note that if you access a file while the
cache is active, the cache timer is reset. So if the cache was to expire in
10 seconds and someone accessed a file via the cache, the timer will again
read 300 seconds. You can increase the timeout on the link by using the
NetDfsSetInfo() API. Are you saying that the client always goes over the
WAN, no matter what? Can you verify that it only does this when its local
cache expires?


--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

We have fully embraced DFS/FRS in our enterprise to help share common data
with a common drive letter among remote facilities. We have a DFS Root
hosted by the corporate office that all facilities map to their W: drive
This W: drive contains links to other DFS roots which are hosted by remote
facilities.
When a user in a remote facility tries to open large CAD assemblies
comprised of over 100 parts from the W: drive it takes over 12 minutes to
complete, even though the files are on his local server. When the DFS
environment is bypassed by opening the same assembly from his local server
using the servers UNC path (the same place DFS previously redirected him)
the time is cut to 5 minutes.
When opening the files the user takes 3 DFS redirects: \\Corp
Root\Remote Root 1\Remote Root 2\folder1\folder2\file.xxx
The Corp Root and the Remote Root 1 are in different facilities accessed
over the WAN using T1 circuits. Remote Root 2 is in his facility and
contains the files he is opening.
As an experiment, two additional servers were built to host the Root
Replicas accessed over the WAN. One for Corp Root and the second for Remote
Root 1. These servers were added to the users local LAN or Site. With Root
replicas for all of the DFS Roots now in his site, the open file command was
cut down to just under 4 minutes, faster than the local UNC call.
My questions are: 1) is it necessary to host root replicas for all of
the DFS Roots in our enterprise in each facility to speed local file access
through DFS? 2) Why is DFS a bottleneck when the Roots are remote but the
files local? 3) If the client downloads the PKT Cache during it's initial
DFS call, which contains all of the redirect information, why does it
continually go over the WAN back to the remote DFS roots during the open
file session?

 

[Arif Saifee [MSFT]]

Hi,
If you liked SONAR, you'll love ULTRASOUND, the new version.

Now back to the dfs issue. Once the dfs path is resolved in the client's
cache, the time taken for the access to work should be minimal - in fact,
the time taken is just the time to look up the path in the cache (and no
network activity happens here).
Can you take a network sniff of the access which takes time, after the path
has been resolved in the cache?

--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

Thank you for your response. Please allow me to elaborate. All of the
Roots are domain based and are in the same domain and each in a different
site. Each site has a *DC*. Each server and client is Win2K with SP3.
What we are experiencing is that when a user opens a CAD assembly which is
comprised of over 100 individual parts or files through the DFS file
structure it is VERY slow, even though the data is on the users local
server. Because our goal is to get all users in our enterprise to use the
same drive letter and path for their data, we have implemented a DFS
'hierarchy. When the user in question opens his CAD assembly it is coming
from the following DFS path:

W:\Link_to_DFS_Root_1\Link_to_DFS_Root_2\folder1\folder2\file.xxx

W:\ (this is mapped to the DFS Root at Corporate HQ which is in a remote
site)
Link to DFS Root 1 (this root is also in a remote site)
Link to DFS Root 2 (this root is in the users site)
folder1\folder2\file.xxx

The user is navigating 3 DFS Roots before he gets to the files he wants to
open.

When we perform a dfsutil /pktinfo the entire DFS hierarchy is resolved, but
the open file session is still VERY slow. The cached information is not
expiring during this open file session, so where could the bottleneck be
except for the continual AD and DFS calls? By building a DFS Root Replica
for each root and placing it in the users site did we take away the
continual AD and DFS calls or just move them to the local site?

BTW - Thank you for the FRS Monitoring tool SONAR.EXE. It is very useful
!!

Let's take the example of \\Corp\Root\Remote Root1\RemoteRoot2\folder1
In this case, the client has to figure out which root server hosts
\\Corp\Root. I assume this is a domain based root. This will cause the
client to contact the nearest *DC* of the domain Corp. The DC will then
redirect it to the root server which hosts the domain based root "Root". So
if the nearest DC is on the WAN, there's your first bottleneck. Next, the
client asks the root server to figure out where the link "RemoteRoot1"
points to. If Remote Root1 points to another domain based root, say
\\Corp\RemoteRoot1", the whole process is repeated to figure out which root
server hosts \\Corp\RemoteRoot1.
The same goes for the other root "Remote Root2".

So the answer to your questions:
1) Yes, to speed up access to a domain based root, it is advisable to

put

a
root replica and a *DC* in the client's local site.
2) The explanation above should explain the bottleneck.
3) The client should not be going over to get fresh information, if the info
is already in its cache, *except when the cache expires*. The cache has a
default expiry of 300 seconds. Note that if you access a file while the
cache is active, the cache timer is reset. So if the cache was to expire in
10 seconds and someone accessed a file via the cache, the timer will again
read 300 seconds. You can increase the timeout on the link by using the
NetDfsSetInfo() API. Are you saying that the client always goes over the
WAN, no matter what? Can you verify that it only does this when its local
cache expires?


--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

We have fully embraced DFS/FRS in our enterprise to help share common data
with a common drive letter among remote facilities. We have a DFS Root
hosted by the corporate office that all facilities map to their W: drive
This W: drive contains links to other DFS roots which are hosted by remote
facilities.
When a user in a remote facility tries to open large CAD assemblies
comprised of over 100 parts from the W: drive it takes over 12 minutes to
complete, even though the files are on his local server. When the DFS
environment is bypassed by opening the same assembly from his local server
using the servers UNC path (the same place DFS previously redirected him)
the time is cut to 5 minutes.
When opening the files the user takes 3 DFS redirects: \\Corp
Root\Remote Root 1\Remote Root 2\folder1\folder2\file.xxx
The Corp Root and the Remote Root 1 are in different facilities accessed
over the WAN using T1 circuits. Remote Root 2 is in his facility and
contains the files he is opening.
As an experiment, two additional servers were built to host the Root
Replicas accessed over the WAN. One for Corp Root and the second for Remote
Root 1. These servers were added to the users local LAN or Site.

With
Root

replicas for all of the DFS Roots now in his site, the open file

command
was

cut down to just under 4 minutes, faster than the local UNC call.
My questions are: 1) is it necessary to host root replicas for all of
the DFS Roots in our enterprise in each facility to speed local file access
through DFS? 2) Why is DFS a bottleneck when the Roots are remote

but
the

files local? 3) If the client downloads the PKT Cache during it's initial
DFS call, which contains all of the redirect information, why does it
continually go over the WAN back to the remote DFS roots during the open
file session?

 

[Ron Garon]

Please let us know when ULTRASOUND is available. We will capture some
traffic and send you the results. Thank you for you help.

Hi,
If you liked SONAR, you'll love ULTRASOUND, the new version.

Now back to the dfs issue. Once the dfs path is resolved in the client's
cache, the time taken for the access to work should be minimal - in fact,
the time taken is just the time to look up the path in the cache (and no
network activity happens here).
Can you take a network sniff of the access which takes time, after the path
has been resolved in the cache?

--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

Thank you for your response. Please allow me to elaborate. All of the
Roots are domain based and are in the same domain and each in a different
site. Each site has a *DC*. Each server and client is Win2K with SP3.
What we are experiencing is that when a user opens a CAD assembly which is
comprised of over 100 individual parts or files through the DFS file
structure it is VERY slow, even though the data is on the users local
server. Because our goal is to get all users in our enterprise to use the
same drive letter and path for their data, we have implemented a DFS
'hierarchy. When the user in question opens his CAD assembly it is coming
from the following DFS path:

W:\Link_to_DFS_Root_1\Link_to_DFS_Root_2\folder1\folder2\file.xxx

W:\ (this is mapped to the DFS Root at Corporate HQ which is in a remote
site)
Link to DFS Root 1 (this root is also in a remote site)
Link to DFS Root 2 (this root is in the users site)
folder1\folder2\file.xxx

The user is navigating 3 DFS Roots before he gets to the files he wants to
open.

When we perform a dfsutil /pktinfo the entire DFS hierarchy is resolved, but
the open file session is still VERY slow. The cached information is not
expiring during this open file session, so where could the bottleneck be
except for the continual AD and DFS calls? By building a DFS Root Replica
for each root and placing it in the users site did we take away the
continual AD and DFS calls or just move them to the local site?

BTW - Thank you for the FRS Monitoring tool SONAR.EXE. It is very useful
!!

"Root".
So put the
info

has

a

default expiry of 300 seconds. Note that if you access a file while the
cache is active, the cache timer is reset. So if the cache was to

expire
in

10 seconds and someone accessed a file via the cache, the timer will again
read 300 seconds. You can increase the timeout on the link by using the
NetDfsSetInfo() API. Are you saying that the client always goes over the
WAN, no matter what? Can you verify that it only does this when its local
cache expires?


--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the

subject

to common
data minutes
to all
of

 

[Net Worker]

Arif,
Where does one get SONAR and dfsutil ?
thanks
G

Hi,
If you liked SONAR, you'll love ULTRASOUND, the new version.

Now back to the dfs issue. Once the dfs path is resolved in the client's
cache, the time taken for the access to work should be minimal - in fact,
the time taken is just the time to look up the path in the cache (and no
network activity happens here).
Can you take a network sniff of the access which takes time, after the path
has been resolved in the cache?

--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

Thank you for your response. Please allow me to elaborate. All of the
Roots are domain based and are in the same domain and each in a different
site. Each site has a *DC*. Each server and client is Win2K with SP3.
What we are experiencing is that when a user opens a CAD assembly which is
comprised of over 100 individual parts or files through the DFS file
structure it is VERY slow, even though the data is on the users local
server. Because our goal is to get all users in our enterprise to use the
same drive letter and path for their data, we have implemented a DFS
'hierarchy. When the user in question opens his CAD assembly it is coming
from the following DFS path:

W:\Link_to_DFS_Root_1\Link_to_DFS_Root_2\folder1\folder2\file.xxx

W:\ (this is mapped to the DFS Root at Corporate HQ which is in a remote
site)
Link to DFS Root 1 (this root is also in a remote site)
Link to DFS Root 2 (this root is in the users site)
folder1\folder2\file.xxx

The user is navigating 3 DFS Roots before he gets to the files he wants to
open.

When we perform a dfsutil /pktinfo the entire DFS hierarchy is resolved, but
the open file session is still VERY slow. The cached information is not
expiring during this open file session, so where could the bottleneck be
except for the continual AD and DFS calls? By building a DFS Root Replica
for each root and placing it in the users site did we take away the
continual AD and DFS calls or just move them to the local site?

BTW - Thank you for the FRS Monitoring tool SONAR.EXE. It is very useful
!!

"Root".
So put the
info

has

a

default expiry of 300 seconds. Note that if you access a file while the
cache is active, the cache timer is reset. So if the cache was to

expire
in

10 seconds and someone accessed a file via the cache, the timer will again
read 300 seconds. You can increase the timeout on the link by using the
NetDfsSetInfo() API. Are you saying that the client always goes over the
WAN, no matter what? Can you verify that it only does this when its local
cache expires?


--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the

subject

to common
data minutes
to all
of

 

[Murali Brahmadesam [MSFT]]

Hi,
Sonar:
http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/sonar-o.asp
Dfsutil from reskit:
http://www.microsoft.com/downloads/...69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

-Murali


--
----------------------------------------------------------------------------
----------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
----------------------------------------------------------------------------
----------------------------------------

Arif,
Where does one get SONAR and dfsutil ?
thanks
G

Hi,
If you liked SONAR, you'll love ULTRASOUND, the new version.

Now back to the dfs issue. Once the dfs path is resolved in the client's
cache, the time taken for the access to work should be minimal - in fact,
the time taken is just the time to look up the path in the cache (and no
network activity happens here).
Can you take a network sniff of the access which takes time, after the path
has been resolved in the cache?

--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the subject to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

Thank you for your response. Please allow me to elaborate. All of the
Roots are domain based and are in the same domain and each in a different
site. Each site has a *DC*. Each server and client is Win2K with SP3.
What we are experiencing is that when a user opens a CAD assembly

which

is

wants

to

open.

When we perform a dfsutil /pktinfo the entire DFS hierarchy is

resolved,
but

the open file session is still VERY slow. The cached information is not
expiring during this open file session, so where could the bottleneck be
except for the continual AD and DFS calls? By building a DFS Root Replica
for each root and placing it in the users site did we take away the
continual AD and DFS calls or just move them to the local site?

BTW - Thank you for the FRS Monitoring tool SONAR.EXE. It is very useful
!!

Let's take the example of \\Corp\Root\Remote Root1\RemoteRoot2\folder1
In this case, the client has to figure out which root server hosts
\\Corp\Root. I assume this is a domain based root. This will cause the
client to contact the nearest *DC* of the domain Corp. The DC will then
redirect it to the root server which hosts the domain based root "Root".
So
if the nearest DC is on the WAN, there's your first bottleneck.

Next,
the

client asks the root server to figure out where the link "RemoteRoot1"
points to. If Remote Root1 points to another domain based root, say
\\Corp\RemoteRoot1", the whole process is repeated to figure out which
root
server hosts \\Corp\RemoteRoot1.
The same goes for the other root "Remote Root2".

So the answer to your questions:
1) Yes, to speed up access to a domain based root, it is advisable

to
put

a
root replica and a *DC* in the client's local site.
2) The explanation above should explain the bottleneck.
3) The client should not be going over to get fresh information, if the
info
is already in its cache, *except when the cache expires*. The cache

has

a
default expiry of 300 seconds. Note that if you access a file while the
cache is active, the cache timer is reset. So if the cache was to expire
in
10 seconds and someone accessed a file via the cache, the timer will again
read 300 seconds. You can increase the timeout on the link by using the
NetDfsSetInfo() API. Are you saying that the client always goes over the
WAN, no matter what? Can you verify that it only does this when its local
cache expires?


--
Thanks,
Arif Saifee [MSFT]

PS: Please post DFS related queries in the newsgroup
"microsoft.public.win2000.file_system". Please use "DFS" in the

subject

to
make it immediately noticeable.

Disclaimer: This posting is provided "AS IS" with no warranties, and
confers
no rights.

We have fully embraced DFS/FRS in our enterprise to help share common
data
with a common drive letter among remote facilities. We have a DFS Root
hosted by the corporate office that all facilities map to their W: drive
This W: drive contains links to other DFS roots which are hosted by
remote
facilities.
When a user in a remote facility tries to open large CAD assemblies
comprised of over 100 parts from the W: drive it takes over 12 minutes
to
complete, even though the files are on his local server. When the DFS
environment is bypassed by opening the same assembly from his local
server
using the servers UNC path (the same place DFS previously redirected
him)
the time is cut to 5 minutes.
When opening the files the user takes 3 DFS redirects: \\Corp
Root\Remote Root 1\Remote Root 2\folder1\folder2\file.xxx
The Corp Root and the Remote Root 1 are in different facilities
accessed
over the WAN using T1 circuits. Remote Root 2 is in his facility and
contains the files he is opening.
As an experiment, two additional servers were built to host

the
Root

Replicas accessed over the WAN. One for Corp Root and the second for
Remote
Root 1. These servers were added to the users local LAN or Site. With
Root
replicas for all of the DFS Roots now in his site, the open file command
was
cut down to just under 4 minutes, faster than the local UNC call.
My questions are: 1) is it necessary to host root replicas for all
of
the DFS Roots in our enterprise in each facility to speed local file
access
through DFS? 2) Why is DFS a bottleneck when the Roots are

remote
but

the
files local? 3) If the client downloads the PKT Cache during it's
initial
DFS call, which contains all of the redirect information, why does it
continually go over the WAN back to the remote DFS roots during

the
open

file session?