I'm confused

I'm not sure what to do here. I've got three servers hosting my DFS
namespaces. They all have the same data (hopefully) and we use them for high
availability and data backup purposes.

Should I define the DFS namespaces and replication on all three servers,
using the DFS Management snap-in, or can I just define them on one server?

Tom

--
ASUS A8N32-SLI Deluxe MB
AMD Athlon 64 X2 CPU 4800+
4GB RAM
nVidia GeForce 8500 GT Video
250 GB SATA II hard drive
Pinnacle PCTV 7010iX TV Tuner

Tom,
Based on you description, it appears that you have three namespace servers
(i.e. three servers hosting DFS root) - is this correct? If so, how did you
make this determinatiion? If that was the case, you should be able to simply
point to the namespace they host via "Add Namespaces to Display" in the DFS
Management console - without the need to define them.
Once the namespace appears in the console, you can manage its behavior on
all servers that form the DFS hierarchy (note that the replication can be
managed only on the folder level)

hth
Marcin

"Tom Mason" <> wrote in message
news:B37B66CD-E438-47B2-AEFA-...
> I'm not sure what to do here. I've got three servers hosting my DFS
> namespaces. They all have the same data (hopefully) and we use them for
> high availability and data backup purposes.
>
> Should I define the DFS namespaces and replication on all three servers,
> using the DFS Management snap-in, or can I just define them on one server?
>
> Tom
>
> --
> ASUS A8N32-SLI Deluxe MB
> AMD Athlon 64 X2 CPU 4800+
> 4GB RAM
> nVidia GeForce 8500 GT Video
> 250 GB SATA II hard drive
> Pinnacle PCTV 7010iX TV Tuner

On Tue, 9 Dec 2008 00:07:23 -0800, "Tom Mason" <> wrote:

>I'm not sure what to do here. I've got three servers hosting my DFS
>namespaces. They all have the same data (hopefully) and we use them for high
>availability and data backup purposes.
>
>Should I define the DFS namespaces and replication on all three servers,
>using the DFS Management snap-in, or can I just define them on one server?
>
On one because the system replicates the DFSRoot to all the DFS servers.

BUT you should not have ANY data in the DFS root, only folders and links within
the folders. The links point to the actual server location that house the data.
This may be a share on the same server. For example I may have DFSRoot on
ServerA and a data folder also on ServerA shared as \\ServerA\Data$. Then in the
DFS console and may add a folder called "data" in the root and add a link to the
real data share.

In the console I create a DFSRoot folder called say DFSRoot
Then I add a folder called "Data" in the DFSRoot
Now I link the Data folder to ServerA\Data$
(or it could be to ServerX\Data$)

Now my client sees \\domain\dfsroot\data and when he opens it sees the contents
of \\ServerA\Data$ (or ServerX\Data$)

The data does not actually reside in the DFS root. So now I buy ServerB which
has massive performance and a TBit data connection <grin>. All I need to do is
copy the data from ServerA\Data$ to a new share ServerB\FasterData$ say. Then
redefine the link in DFS. The client still sees \\domain\dfsroot\data but now is
being directed to ServerB\Fasterdata$ and is very happy that the data can be
accessed so much faster.

The real benefits are from the ability to move data from one server to the other
with no need to reconfigure the clients. If you have many targets you can move
the data to many different servers and spread the load without any requirement
to reconfigure the clients.

In addition you can set up multiple targets and enable replication between them.
However each set of links can have its own replication group and be configured
independently of each other.

So UserHome may be replicated on 3 servers while Public is replicated on 5
servers. All to suit you network topology and server resources.

The way you have it you have almost no control and in addition will need to bay
great attention to the limits on the DFSRoot folder for the number of files and
folders it can support.


>Tom
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.