how do I

[Joey]

Is there a standard procedure to setup DFS for local and remote offices?

For remote offices, I assume the users over there should be configured to
use local DFS server and not from the main office.

So if I decide to setup a new office, Should I be setting up a DFS server on
my main office first, then replicate all the data to the new server and ship
it out?

[Isaac Oben [MCITP,MCSE]]

Hello Joey,

Setting DFS for main and remote offices will depend mostly of how good your
network is. How is your environment currently setup, do you have more than
one site? Yes, having clients accessing dfs locally as opposed to from the
main office,will be best and will reduce your network traffic. You can setup
your dfs root on your main office and then set up replicas on the remote
offices and then use a hub and spoke method to set up replication. You can
setup a one way replication from main office to remote offices, that way,
only changes made to main can replicate to remote. But if you prefer to have
changes on both main and remote, then set up a two way replication.

If you have a domain controller on both the main and the remote location,
will suggest you setup domain based dfs with fault tolerance and forced
users to use dfs based on thier location.

Create main office (root) dfs, then create remote locations and set up your
replication accordingly.

[Joey]

yes looks like we have more than one site.

I am trying to get an understanding on how it is currently setup. looksl
ike we are using a rind topology instead of hub and spoke. what are the
differences? we have a dc on every remote site. what is a dfs referral?

Post by Isaac Oben [MCITP,MCSE]
Hello Joey,
Setting DFS for main and remote offices will depend mostly of how good
your network is. How is your environment currently setup, do you have more
than one site? Yes, having clients accessing dfs locally as opposed to
from the main office,will be best and will reduce your network traffic.
You can setup your dfs root on your main office and then set up replicas
on the remote offices and then use a hub and spoke method to set up
replication. You can setup a one way replication from main office to
remote offices, that way, only changes made to main can replicate to
remote. But if you prefer to have changes on both main and remote, then
set up a two way replication.
If you have a domain controller on both the main and the remote location,
will suggest you setup domain based dfs with fault tolerance and forced
users to use dfs based on thier location.
Create main office (root) dfs, then create remote locations and set up
your replication accordingly.
--
Isaac Oben [MCTIP, MCSE]

Post by Joey
Is there a standard procedure to setup DFS for local and remote offices?
For remote offices, I assume the users over there should be configured to
use local DFS server and not from the main office.
So if I decide to setup a new office, Should I be setting up a DFS server
on my main office first, then replicate all the data to the new server
and ship it out?

[DaveMills]

Post by Joey
Is there a standard procedure to setup DFS for local and remote offices?
For remote offices, I assume the users over there should be configured to
use local DFS server and not from the main office.
So if I decide to setup a new office, Should I be setting up a DFS server on
my main office first, then replicate all the data to the new server and ship
it out?

In a multi site deployment it is important you read the document "How DFS works"
at
http://technet.microsoft.com/en-us/library/cc782417.aspx

The interaction between DCs, DFS servers and the data shares is important to
understand. You need to also understand Domain inter site costing as it is used
to determine which targets are used by the clients.

It is also important to understand that the DFS namespace is not designed to
hold data but only the namespace. The data is held on normal servers referenced
via normal UNC names. What DFS does is bring all the names under a single
namespace (or more than on name space if you wish). The DFS referral process is
designed to resolve the client understanding of the pathname to the actual UNC
name of the share that holds the data and redirect the connection to that share
just as if you had used the UNC name directly. What DFS adds is that you can
have more than one target for the name, i.e. two or more copies on different
servers. DFS Replication can be used to synchronize the multiple copies. You can
move a copy to a new server and just change the referral in the namespace. Even
without multiple copies having the ability to move the data to a new server and
change the referral in DFS is worthwhile. Take for example deploying software
via GPO. It is not possible to move the package to a new UNC but if the pathname
is a DFS pathname such as \\domain\shared\deployment that points to
\\serverA\deploy it is easy to move the shared folder to a new server say
\\serverB\deploy and redefine DFS such that \\domain\shared\deployment now
points to serverB. Your GPOs are happy as the name has not changed. However the
data has physically moved servers.