Hi Dave,

File Replication Service (FRS) replicates the content of DFS link targets -- not the structure.
FRS is a multi-master (almost) real-time replication solution. Depending on your connection
topology, whenever you made a change or create a new file/folder under your link target
share it gets replicated out to its partners.

Let me know if this doesn't clarify the questions in your mind.


--
Huseyin Dursun [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights

Please post FRS related queries in newsgroup microsoft.public.windows.server.dfs_frs



"Dave" <(E-Mail Removed)> wrote in message news:018801c3a312$d32d3540$(E-Mail Removed)...
> I am having a hard time getting a definite answer to the
> following question:
>
> If you set up a DFS root including a DFS replica, what
> gets replicated? Is it just the DFS root and the
> structure or is the the actual data that is including in
> the DFS links?
>
> For example, I can create a DFS root which includes DFS
> links to 4 shares on my network. These 4 shares house
> approximately 25 gigs of data. If I set up a DFS replica
> to a different server, does all 25 gigs get replicated to
> this new location or does only the DFS structure get
> replicated? If the data does get replicated, then DFS
> replica appears to be nothing more that a mirror,
> correct? If so, What is the best practice to keep your
> active DFS root and its replica "synched up" Obviously,
> it would be impossible for both to be identicle unless
> both places get updated in a "real time" scenario. I
> would also suspect that your newtork performance would
> suffer since data is copied to 2 locations instead of
> one.
>
> Thanks for any replies.

Thanks for the response. My biggest concern is with
network performance. Does your network performance,
bandwidth, etc suffer due to this replication?

My goal is this. I plan on buying a NEW drive for one of
my DC's. Its goal will be exclusively to house the DFS
replica. It will do nothing else! I currently have a
Shared folder that is 120 gig in size. I plan on making
this shared folder my DFS root. It will have 3 DFS links
within it. All 3 links are also located in this "master"
share. Once it is successfully set up I will then create
a DFS replica poniting back to my the new drive which
will also be 120 gig in size. The DFS root and the DFS
replica will both be on seperate servers. Does this sound
like a valid configuration?

Thanks,
dave



>-----Original Message-----
>Hi Dave,
>
>File Replication Service (FRS) replicates the content of
DFS link targets -- not the structure.
>FRS is a multi-master (almost) real-time replication
solution. Depending on your connection
>topology, whenever you made a change or create a new
file/folder under your link target
>share it gets replicated out to its partners.
>
>Let me know if this doesn't clarify the questions in
your mind.
>
>
>--
>Huseyin Dursun [MSFT]
>This posting is provided "AS IS" with no warranties, and
confers no rights
>
>Please post FRS related queries in newsgroup
microsoft.public.windows.server.dfs_frs
>
>
>
>"Dave" <(E-Mail Removed)> wrote in message
news:018801c3a312$d32d3540$(E-Mail Removed)...
>> I am having a hard time getting a definite answer to
the
>> following question:
>>
>> If you set up a DFS root including a DFS replica, what
>> gets replicated? Is it just the DFS root and the
>> structure or is the the actual data that is including
in
>> the DFS links?
>>
>> For example, I can create a DFS root which includes
DFS
>> links to 4 shares on my network. These 4 shares house
>> approximately 25 gigs of data. If I set up a DFS
replica
>> to a different server, does all 25 gigs get replicated
to
>> this new location or does only the DFS structure get
>> replicated? If the data does get replicated, then DFS
>> replica appears to be nothing more that a mirror,
>> correct? If so, What is the best practice to keep your
>> active DFS root and its replica "synched up"
Obviously,
>> it would be impossible for both to be identicle unless
>> both places get updated in a "real time" scenario. I
>> would also suspect that your newtork performance would
>> suffer since data is copied to 2 locations instead of
>> one.
>>
>> Thanks for any replies.

The dfs root needs to be a new share, not an existing one. I think you may
have made the same mistake in understanding that I did, which was not
understanding that the root is *just* a placeholder for the link structure.
The share that is the root target will have physical folders in it
representing the links, but they are only a virtual representation.

Also, the terminology as of XP/2003 is to create a second root target, not a
replica. This is important, because the old (Win2k) terminology of replica
I think implied that you need FRS replication, which is most definitely not
the case (you don't want it explicitly turned on)

So, you would create a new share on the existing 120GB drive to serve as a
target for the root. You would create the links in that root which would
target the existing share(s). Then you would recreate that on the 2nd drive
and turn on replication on the links. The root placeholder folders are
automagically replicated when you create the second root target.

"Dave" <(E-Mail Removed)> wrote in message
news:054101c3a31e$f7a44470$(E-Mail Removed)...
> Thanks for the response. My biggest concern is with
> network performance. Does your network performance,
> bandwidth, etc suffer due to this replication?
>
> My goal is this. I plan on buying a NEW drive for one of
> my DC's. Its goal will be exclusively to house the DFS
> replica. It will do nothing else! I currently have a
> Shared folder that is 120 gig in size. I plan on making
> this shared folder my DFS root. It will have 3 DFS links
> within it. All 3 links are also located in this "master"
> share. Once it is successfully set up I will then create
> a DFS replica poniting back to my the new drive which
> will also be 120 gig in size. The DFS root and the DFS
> replica will both be on seperate servers. Does this sound
> like a valid configuration?
>
> Thanks,
> dave
>
>
>
> >-----Original Message-----
> >Hi Dave,
> >
> >File Replication Service (FRS) replicates the content of
> DFS link targets -- not the structure.
> >FRS is a multi-master (almost) real-time replication
> solution. Depending on your connection
> >topology, whenever you made a change or create a new
> file/folder under your link target
> >share it gets replicated out to its partners.
> >
> >Let me know if this doesn't clarify the questions in
> your mind.
> >
> >
> >--
> >Huseyin Dursun [MSFT]
> >This posting is provided "AS IS" with no warranties, and
> confers no rights
> >
> >Please post FRS related queries in newsgroup
> microsoft.public.windows.server.dfs_frs
> >
> >
> >
> >"Dave" <(E-Mail Removed)> wrote in message
> news:018801c3a312$d32d3540$(E-Mail Removed)...
> >> I am having a hard time getting a definite answer to
> the
> >> following question:
> >>
> >> If you set up a DFS root including a DFS replica, what
> >> gets replicated? Is it just the DFS root and the
> >> structure or is the the actual data that is including
> in
> >> the DFS links?
> >>
> >> For example, I can create a DFS root which includes
> DFS
> >> links to 4 shares on my network. These 4 shares house
> >> approximately 25 gigs of data. If I set up a DFS
> replica
> >> to a different server, does all 25 gigs get replicated
> to
> >> this new location or does only the DFS structure get
> >> replicated? If the data does get replicated, then DFS
> >> replica appears to be nothing more that a mirror,
> >> correct? If so, What is the best practice to keep your
> >> active DFS root and its replica "synched up"
> Obviously,
> >> it would be impossible for both to be identicle unless
> >> both places get updated in a "real time" scenario. I
> >> would also suspect that your newtork performance would
> >> suffer since data is copied to 2 locations instead of
> >> one.
> >>
> >> Thanks for any replies.

What happens if the data that is part of the DFS root
goes down such as in a HD crash? Does the replica become
the active data directory? Or is it simply just a non-
active backup of your data?

Also if it does become the active data directory, what
happens when the original DFS root comes back online,
does it failover?

Thanks,
Dave


>-----Original Message-----
>The dfs root needs to be a new share, not an existing
one. I think you may
>have made the same mistake in understanding that I did,
which was not
>understanding that the root is *just* a placeholder for
the link structure.
>The share that is the root target will have physical
folders in it
>representing the links, but they are only a virtual
representation.
>
>Also, the terminology as of XP/2003 is to create a
second root target, not a
>replica. This is important, because the old (Win2k)
terminology of replica
>I think implied that you need FRS replication, which is
most definitely not
>the case (you don't want it explicitly turned on)
>
>So, you would create a new share on the existing 120GB
drive to serve as a
>target for the root. You would create the links in that
root which would
>target the existing share(s). Then you would recreate
that on the 2nd drive
>and turn on replication on the links. The root
placeholder folders are
>automagically replicated when you create the second root
target.
>
>"Dave" <(E-Mail Removed)> wrote in
message
>news:054101c3a31e$f7a44470$(E-Mail Removed)...
>> Thanks for the response. My biggest concern is with
>> network performance. Does your network performance,
>> bandwidth, etc suffer due to this replication?
>>
>> My goal is this. I plan on buying a NEW drive for one
of
>> my DC's. Its goal will be exclusively to house the DFS
>> replica. It will do nothing else! I currently have a
>> Shared folder that is 120 gig in size. I plan on making
>> this shared folder my DFS root. It will have 3 DFS
links
>> within it. All 3 links are also located in
this "master"
>> share. Once it is successfully set up I will then
create
>> a DFS replica poniting back to my the new drive which
>> will also be 120 gig in size. The DFS root and the DFS
>> replica will both be on seperate servers. Does this
sound
>> like a valid configuration?
>>
>> Thanks,
>> dave
>>
>>
>>
>> >-----Original Message-----
>> >Hi Dave,
>> >
>> >File Replication Service (FRS) replicates the content
of
>> DFS link targets -- not the structure.
>> >FRS is a multi-master (almost) real-time replication
>> solution. Depending on your connection
>> >topology, whenever you made a change or create a new
>> file/folder under your link target
>> >share it gets replicated out to its partners.
>> >
>> >Let me know if this doesn't clarify the questions in
>> your mind.
>> >
>> >
>> >--
>> >Huseyin Dursun [MSFT]
>> >This posting is provided "AS IS" with no warranties,
and
>> confers no rights
>> >
>> >Please post FRS related queries in newsgroup
>> microsoft.public.windows.server.dfs_frs
>> >
>> >
>> >
>> >"Dave" <(E-Mail Removed)> wrote in message
>> news:018801c3a312$d32d3540$(E-Mail Removed)...
>> >> I am having a hard time getting a definite answer to
>> the
>> >> following question:
>> >>
>> >> If you set up a DFS root including a DFS replica,
what
>> >> gets replicated? Is it just the DFS root and the
>> >> structure or is the the actual data that is
including
>> in
>> >> the DFS links?
>> >>
>> >> For example, I can create a DFS root which includes
>> DFS
>> >> links to 4 shares on my network. These 4 shares
house
>> >> approximately 25 gigs of data. If I set up a DFS
>> replica
>> >> to a different server, does all 25 gigs get
replicated
>> to
>> >> this new location or does only the DFS structure get
>> >> replicated? If the data does get replicated, then
DFS
>> >> replica appears to be nothing more that a mirror,
>> >> correct? If so, What is the best practice to keep
your
>> >> active DFS root and its replica "synched up"
>> Obviously,
>> >> it would be impossible for both to be identicle
unless
>> >> both places get updated in a "real time" scenario. I
>> >> would also suspect that your newtork performance
would
>> >> suffer since data is copied to 2 locations instead
of
>> >> one.
>> >>
>> >> Thanks for any replies.
>
>
>.
>

"Dave" <(E-Mail Removed)> wrote in news:061901c3a327
$24f565a0$(E-Mail Removed):

>
> What happens if the data that is part of the DFS root
> goes down such as in a HD crash? Does the replica become
> the active data directory? Or is it simply just a non-
> active backup of your data?
>
> Also if it does become the active data directory, what
> happens when the original DFS root comes back online,
> does it failover?
>
> Thanks,
> Dave
>
<..rest snipped..>

Hi Dave,

I think one of the problems here is down to terminology - terms like
"share" are overloaded and the terms used have changed (and are clearer)
in W2k3.

Anyway, the first thing to do is to separate Dfs from FRS. Dfs will run
quite happily without FRS and the thing to do is to get yourself a
functioning Dfs configuration before you start adding the FRS component.

From the Dfs MMC, create a new Dfs Root (I'll assume a domain-based Dfs
root here). This will create the Dfs Root Share at the location you
specify. I use "G:\DfsRoot" as my DfsRoot folder name and "Dfs" as my
share name (but I've obviously no imagination!)

Next, from the Dfs MMC, add *existing* shares as LINKS in the Dfs Root.
This creates logical copies of the existing shared folders in the Dfs
Root folder (they're actually "reparse points" in the file system).

So, if you had an existing file structure with two shared folders (S1
and S2) like this:

G:\
|
|- S1
|
|- S2

....you would now see:

G:\
|
|-DfsRoot
| |
| |-S1
| |
| |-S2
|
|-S1
|
|-S2


And your clients can connect to "\\domain.com\dfs\s1" and so on.

Note that you CAN manually create folders and files in the filesystem
under G:\DfsRoot - but DON'T do this - it will only confuse things!

Now you can add a redundant Dfs Root and additional links in the MMC to
dfs\s1 and dfs\s2 (on another server probably). If you weren't using
FRS you would manually copy the contents of dfs\s1 to another share on
another server and add this share as another link to dfs\s1. Clients
who connect to dfs\s1 will now be redirected to one of the two
alternative shares. It will be down to you to manuually sync the
contents of the two shares to ensure clients see a consistent file
structure.

OK, so that's the Dfs part.

Assuming you do want to use FRS to replicate the information between the
two (or more) redundant links... In this case you should set up the Dfs
exactly as above. Then create the shares on the second server (but
DON'T copy any data into the shares). Add the shares as additional
links to in the Dfs MMC and tell it you want to replicate the data. Now
FRS will kick in and copy the data for you. Any on-going changes to the
data on either server will be synched by FRS to the partner replica(s).

NOTES! You can enable replication at the Dfs Root folder level - but
the strong recommendation (generally) is NOT to do this. Just replicate
the individual links that are children of the Dfs Root.

Also, if you have LOTS of data you can pre-stage files - refer to the
Knowledge Base for more info. I replicate 30GB on a LAN and I didn't
bother pre-staging.

Other comments:

Before you start using FRS, download Ultrasound and read the included
online help file - it will explain all this stuff much better that I can
and a lot more besides! Once you start using FRS use Ultrasound to
monitor your file replication.

In answer to your questions above: when you have a redundant Dfs Root
then the participants are effectively peers - so it doesn't make sense
to think about one partner becoming the "active data directory". All
partners will be online and client requests will be forwarded to
different partners accordingly. If one of the partners is unavailable
(maybe because of a HD crash) then clients will be redirected to an
alternative partner (the clients won't have to disconnect and reconnect
for this to happen).

If a partner is offline for a long time and is then brought back online
then the data between the partners will no longer be in sync. In this
case you'll need to use FRS recovery procedures (there are lots of KBs
about this) to restore things properly.

General advice is NOT to try to help FRS along by copying data around
amongst the replicas yourself - this will only break things.

Regards
Chris

Chris, excellent overview. I would just add this little bit regarding your
paragraph below for Dave's benefit.

It may help your understanding to realize that the roots do not have to be
on the same server as any of the links. DFS by it's nature is a *virtual*
structure. Besides the fault tolerance (replication), the other main
purpose I see is to consolidate shares scattered all over the place into one
structure. So, you could have the root on ServerA, a link underneath that
root targeting a share on ServerB, and another link targeting a share on
ServerC. And all that could be duplicated on servers D,E, and F for high
availability. (Resisting launching into Dr. Seuss...) Any server in a dfs
structure can crash so long as there is at least one dfs root running and at
least one target (replica) for the desired link (given AD and DNS is still
running of course).

Also, anyone starting off on DFS should download the Win2k3 documentation
and read it. It is much better than the Win2k stuff. I bugged Jill for a
while to create a FAQ or quick-start guide providing a step-by-step version
of Dave's summary, but I don't think they have the resources to do it.

"Chris Warwick" <(E-Mail Removed)> wrote in
message news:Xns942A5FD931F33chrisjwarwickvbiay@217.32.252.50...
> "Dave" <(E-Mail Removed)> wrote in news:061901c3a327
> $24f565a0$(E-Mail Removed):
>
>
> In answer to your questions above: when you have a redundant Dfs Root
> then the participants are effectively peers - so it doesn't make sense
> to think about one partner becoming the "active data directory". All
> partners will be online and client requests will be forwarded to
> different partners accordingly. If one of the partners is unavailable
> (maybe because of a HD crash) then clients will be redirected to an
> alternative partner (the clients won't have to disconnect and reconnect
> for this to happen).

Chris, thanks for the response. I would like to get your,
or anyone else's, opinion on why I want to implement DFS.

First, my current network design is pretty simple. For
example, I currently have only ONE share on my File
server. Within this "Root" share I have only 4
subdirectories, such as:

(Main Share)D:\Network
- Users
- Software
- Dialout
- Departments
each of the subdirectories map a drive in my login
script. For Example, the Users directory maps to a G:\
drive. The Software directory maps to a S:\ drive, etc.

So based on my current configuration, you can see I
really do not have a configuration that would beg to use
DFS. However, since I have all my eggs in one basket, so
to speak, I want to implement DFS for the sole purpose of
creating a dfs replica. This way my data can be copied to
a different location and I'd have a backup of it. This is
the only reason I would want to use DFS. I do not plan on
having mulitple shares spread across my Domain.

SO if I implement DFS, my DFS root would be my "Network"
share and the dfs links would be the 4 subdirectories
within it. I also assume that I would not have to do
anything to my current login scripts, correct? They would
continue to work even though those directories are now
part of a DFS? Or do I need to edit my login scripts to
point to the DFS root?

Once my DFS root is functioning properly, what is the
best step to make the replica. I understand that I can go
into the properties of my DFS root and choose to make a
DSFS replica. Once I do this do I simply choose the
location of where I want the replica to reside? Or do I
nned to go and create another DFS root where I want the
replica stored? Or should I not even bother with DFS
since my share is on A server running RAID 5 and gets
backed up daily?

Thanks for the reponses,
Dave





>-----Original Message-----
>"Dave" <(E-Mail Removed)> wrote in
news:061901c3a327
>$24f565a0$(E-Mail Removed):
>
>>
>> What happens if the data that is part of the DFS root
>> goes down such as in a HD crash? Does the replica
become
>> the active data directory? Or is it simply just a non-
>> active backup of your data?
>>
>> Also if it does become the active data directory, what
>> happens when the original DFS root comes back online,
>> does it failover?
>>
>> Thanks,
>> Dave
>>
><..rest snipped..>
>
>Hi Dave,
>
>I think one of the problems here is down to terminology -
terms like
>"share" are overloaded and the terms used have changed
(and are clearer)
>in W2k3.
>
>Anyway, the first thing to do is to separate Dfs from
FRS. Dfs will run
>quite happily without FRS and the thing to do is to get
yourself a
>functioning Dfs configuration before you start adding
the FRS component.
>
>From the Dfs MMC, create a new Dfs Root (I'll assume a
domain-based Dfs
>root here). This will create the Dfs Root Share at the
location you
>specify. I use "G:\DfsRoot" as my DfsRoot folder name
and "Dfs" as my
>share name (but I've obviously no imagination!)
>
>Next, from the Dfs MMC, add *existing* shares as LINKS
in the Dfs Root.
>This creates logical copies of the existing shared
folders in the Dfs
>Root folder (they're actually "reparse points" in the
file system).
>
>So, if you had an existing file structure with two
shared folders (S1
>and S2) like this:
>
>G:\
>|
>|- S1
>|
>|- S2
>
>....you would now see:
>
>G:\
>|
>|-DfsRoot
>| |
>| |-S1
>| |
>| |-S2
>|
>|-S1
>|
>|-S2
>
>
>And your clients can connect to "\\domain.com\dfs\s1"
and so on.
>
>Note that you CAN manually create folders and files in
the filesystem
>under G:\DfsRoot - but DON'T do this - it will only
confuse things!
>
>Now you can add a redundant Dfs Root and additional
links in the MMC to
>dfs\s1 and dfs\s2 (on another server probably). If you
weren't using
>FRS you would manually copy the contents of dfs\s1 to
another share on
>another server and add this share as another link to
dfs\s1. Clients
>who connect to dfs\s1 will now be redirected to one of
the two
>alternative shares. It will be down to you to manuually
sync the
>contents of the two shares to ensure clients see a
consistent file
>structure.
>
>OK, so that's the Dfs part.
>
>Assuming you do want to use FRS to replicate the
information between the
>two (or more) redundant links... In this case you should
set up the Dfs
>exactly as above. Then create the shares on the second
server (but
>DON'T copy any data into the shares). Add the shares as
additional
>links to in the Dfs MMC and tell it you want to
replicate the data. Now
>FRS will kick in and copy the data for you. Any on-
going changes to the
>data on either server will be synched by FRS to the
partner replica(s).
>
>NOTES! You can enable replication at the Dfs Root
folder level - but
>the strong recommendation (generally) is NOT to do
this. Just replicate
>the individual links that are children of the Dfs Root.
>
>Also, if you have LOTS of data you can pre-stage files -
refer to the
>Knowledge Base for more info. I replicate 30GB on a LAN
and I didn't
>bother pre-staging.
>
>Other comments:
>
>Before you start using FRS, download Ultrasound and read
the included
>online help file - it will explain all this stuff much
better that I can
>and a lot more besides! Once you start using FRS use
Ultrasound to
>monitor your file replication.
>
>In answer to your questions above: when you have a
redundant Dfs Root
>then the participants are effectively peers - so it
doesn't make sense
>to think about one partner becoming the "active data
directory". All
>partners will be online and client requests will be
forwarded to
>different partners accordingly. If one of the partners
is unavailable
>(maybe because of a HD crash) then clients will be
redirected to an
>alternative partner (the clients won't have to
disconnect and reconnect
>for this to happen).
>
>If a partner is offline for a long time and is then
brought back online
>then the data between the partners will no longer be in
sync. In this
>case you'll need to use FRS recovery procedures (there
are lots of KBs
>about this) to restore things properly.
>
>General advice is NOT to try to help FRS along by
copying data around
>amongst the replicas yourself - this will only break
things.
>
>Regards
>Chris
>
>
>
>.
>

"Dave" <(E-Mail Removed)> wrote in news:0e8d01c3a3b5$3663bce0
$(E-Mail Removed):

> Chris, thanks for the response. I would like to get your,
> or anyone else's, opinion on why I want to implement DFS.
>
> First, my current network design is pretty simple. For
> example, I currently have only ONE share on my File
> server. Within this "Root" share I have only 4
> subdirectories, such as:
>
> (Main Share)D:\Network
> - Users
> - Software
> - Dialout
> - Departments
> each of the subdirectories map a drive in my login
> script. For Example, the Users directory maps to a G:\
> drive. The Software directory maps to a S:\ drive, etc.
>
> So based on my current configuration, you can see I
> really do not have a configuration that would beg to use
> DFS. However, since I have all my eggs in one basket, so
> to speak, I want to implement DFS for the sole purpose of
> creating a dfs replica. This way my data can be copied to
> a different location and I'd have a backup of it. This is
> the only reason I would want to use DFS. I do not plan on
> having mulitple shares spread across my Domain.

Well, strictly speaking, Dfs only lets you abstract the namespace (which
you don't need to do) - but it also lets you use FRS to create replicas
(and, hence, your backup to a different server/location)

But you could just as easily use Robocopy over-night to copy your data
from one server to another. You can even use the /Mirror option so
files that are deleted in the live data also get deleted in the backup.

The benefits of the Dfs/FRS combo as far as I see them are:

1. Replication runs continuously (or can do) - so you don't have to
worry about losing 10 hours' worth of information if your file server
crashes at 6pm (as you potentially could if you used an over night
backup/copy job).

2. You can have your file server offline during working hours for
maintenance and your clients can still get there file shares from the
replicas.

3. You get automatic load-balancing thrown-in.

(All this assumes you file server is just a file server - if it's also a
DC/DNS/infrastructure server then you'd need to replicate these services
on your other machine too - otherwise the replica file server couldn't
be accessed when the first server was unavailable).

On the downside to the Dfs/FRS combo you have:

1. You have to keep an eye on your FRS setup to make sure it's running
as you want (but you'd have to monitor your backups too...)

2. FRS can't replicate EFS files, so if you're using EFS on these shares
you have to make other plans

3. FRS isn't great for highly volatile files - these generate lots of
FRS replication traffic

4. FRS doesn't (can't) enforce file-locking across replica links - so if
two users update the same file at the same time on different replicas,
the user who saves the file last will have their changes kept - the
other user's changes will be lost.

(There are other pros and cons - these are just the main issues IIRC -
hopefully someone else will throw in other comments :-)



>
> SO if I implement DFS, my DFS root would be my "Network"
> share and the dfs links would be the 4 subdirectories
> within it. I also assume that I would not have to do
> anything to my current login scripts, correct? They would
> continue to work even though those directories are now
> part of a DFS? Or do I need to edit my login scripts to
> point to the DFS root?
>

You could probably arrange to keep your login script as-is. You could
remove the "Network" share (i.e. just stop sharing it) then create a Dfs
Root folder called "D:\DfsRoot" (for argument's sake) and share *this*
with the name "Network" instead. You'd then need to create additional
shares for your Users/Software/Dialout/Departments folders and add these
to the DFS Root. If your login script currently does something like
"Net Use s: \\server\network\software" this would then continue to work
(assuming "network" was the name of your Dfs root folder share and
"software" was a dfs link within that).


> Once my DFS root is functioning properly, what is the
> best step to make the replica. I understand that I can go
> into the properties of my DFS root and choose to make a
> DSFS replica.


You should avoid replicating the Dfs Root folder. Create individual
replicas for each individual link instead.


> Once I do this do I simply choose the
> location of where I want the replica to reside? Or do I
> nned to go and create another DFS root where I want the
> replica stored?

You should probably create another root. In this case the root itself
will be fault tolerant - *BUT* to benefit from this fault-tolerance
you'd need to change your login script to refer to the share above as
"\\domain\network\software" - where domain is the NetBIOS or DNS name of
your domain.


> Or should I not even bother with DFS
> since my share is on A server running RAID 5 and gets
> backed up daily?


Well, that's a question of philosophy I'm afraid! Depends on what
you're worried about and how much insurance premium you're prepared to
pay!


Regards
Chris

Chris, thanks for the input. I really appreciate it. I'll
have to take a bunch of things into consideration.

Thanks,
Dave

>-----Original Message-----
>"Dave" <(E-Mail Removed)> wrote in
news:0e8d01c3a3b5$3663bce0
>$(E-Mail Removed):
>
>> Chris, thanks for the response. I would like to get
your,
>> or anyone else's, opinion on why I want to implement
DFS.
>>
>> First, my current network design is pretty simple. For
>> example, I currently have only ONE share on my File
>> server. Within this "Root" share I have only 4
>> subdirectories, such as:
>>
>> (Main Share)D:\Network
>> - Users
>> - Software
>> - Dialout
>> - Departments
>> each of the subdirectories map a drive in my login
>> script. For Example, the Users directory maps to a G:\
>> drive. The Software directory maps to a S:\ drive, etc.
>>
>> So based on my current configuration, you can see I
>> really do not have a configuration that would beg to
use
>> DFS. However, since I have all my eggs in one basket,
so
>> to speak, I want to implement DFS for the sole purpose
of
>> creating a dfs replica. This way my data can be copied
to
>> a different location and I'd have a backup of it. This
is
>> the only reason I would want to use DFS. I do not plan
on
>> having mulitple shares spread across my Domain.
>
>Well, strictly speaking, Dfs only lets you abstract the
namespace (which
>you don't need to do) - but it also lets you use FRS to
create replicas
>(and, hence, your backup to a different server/location)
>
>But you could just as easily use Robocopy over-night to
copy your data
>from one server to another. You can even use
the /Mirror option so
>files that are deleted in the live data also get deleted
in the backup.
>
>The benefits of the Dfs/FRS combo as far as I see them
are:
>
>1. Replication runs continuously (or can do) - so you
don't have to
>worry about losing 10 hours' worth of information if
your file server
>crashes at 6pm (as you potentially could if you used an
over night
>backup/copy job).
>
>2. You can have your file server offline during working
hours for
>maintenance and your clients can still get there file
shares from the
>replicas.
>
>3. You get automatic load-balancing thrown-in.
>
>(All this assumes you file server is just a file server -
if it's also a
>DC/DNS/infrastructure server then you'd need to
replicate these services
>on your other machine too - otherwise the replica file
server couldn't
>be accessed when the first server was unavailable).
>
>On the downside to the Dfs/FRS combo you have:
>
>1. You have to keep an eye on your FRS setup to make
sure it's running
>as you want (but you'd have to monitor your backups
too...)
>
>2. FRS can't replicate EFS files, so if you're using EFS
on these shares
>you have to make other plans
>
>3. FRS isn't great for highly volatile files - these
generate lots of
>FRS replication traffic
>
>4. FRS doesn't (can't) enforce file-locking across
replica links - so if
>two users update the same file at the same time on
different replicas,
>the user who saves the file last will have their changes
kept - the
>other user's changes will be lost.
>
>(There are other pros and cons - these are just the main
issues IIRC -
>hopefully someone else will throw in other comments :-)
>
>
>
>>
>> SO if I implement DFS, my DFS root would be
my "Network"
>> share and the dfs links would be the 4 subdirectories
>> within it. I also assume that I would not have to do
>> anything to my current login scripts, correct? They
would
>> continue to work even though those directories are now
>> part of a DFS? Or do I need to edit my login scripts
to
>> point to the DFS root?
>>
>
>You could probably arrange to keep your login script as-
is. You could
>remove the "Network" share (i.e. just stop sharing it)
then create a Dfs
>Root folder called "D:\DfsRoot" (for argument's sake)
and share *this*
>with the name "Network" instead. You'd then need to
create additional
>shares for your Users/Software/Dialout/Departments
folders and add these
>to the DFS Root. If your login script currently does
something like
>"Net Use s: \\server\network\software" this would then
continue to work
>(assuming "network" was the name of your Dfs root folder
share and
>"software" was a dfs link within that).
>
>
>> Once my DFS root is functioning properly, what is the
>> best step to make the replica. I understand that I can
go
>> into the properties of my DFS root and choose to make
a
>> DSFS replica.
>
>
>You should avoid replicating the Dfs Root folder.
Create individual
>replicas for each individual link instead.
>
>
>> Once I do this do I simply choose the
>> location of where I want the replica to reside? Or do
I
>> nned to go and create another DFS root where I want
the
>> replica stored?
>
>You should probably create another root. In this case
the root itself
>will be fault tolerant - *BUT* to benefit from this
fault-tolerance
>you'd need to change your login script to refer to the
share above as
>"\\domain\network\software" - where domain is the
NetBIOS or DNS name of
>your domain.
>
>
>> Or should I not even bother with DFS
>> since my share is on A server running RAID 5 and gets
>> backed up daily?
>
>
>Well, that's a question of philosophy I'm afraid!
Depends on what
>you're worried about and how much insurance premium
you're prepared to
>pay!
>
>
>Regards
>Chris
>.
>

"Dave" <(E-Mail Removed)> wrote in message
news:0e8d01c3a3b5$3663bce0$(E-Mail Removed)...
>
> SO if I implement DFS, my DFS root would be my "Network"
> share and the dfs links would be the 4 subdirectories
> within it. I also assume that I would not have to do
> anything to my current login scripts, correct? They would
> continue to work even though those directories are now
> part of a DFS? Or do I need to edit my login scripts to
> point to the DFS root?
>

No, that is exactly how NOT to implement DFS.



> Once my DFS root is functioning properly, what is the
> best step to make the replica. I understand that I can go
> into the properties of my DFS root and choose to make a
> DSFS replica. Once I do this do I simply choose the
> location of where I want the replica to reside? Or do I
> nned to go and create another DFS root where I want the
> replica stored? Or should I not even bother with DFS
> since my share is on A server running RAID 5 and gets
> backed up daily?
>
> Thanks for the reponses,
> Dave
>
>
>
>
>
> >-----Original Message-----
> >"Dave" <(E-Mail Removed)> wrote in
> news:061901c3a327
> >$24f565a0$(E-Mail Removed):
> >
> >>
> >> What happens if the data that is part of the DFS root
> >> goes down such as in a HD crash? Does the replica
> become
> >> the active data directory? Or is it simply just a non-
> >> active backup of your data?
> >>
> >> Also if it does become the active data directory, what
> >> happens when the original DFS root comes back online,
> >> does it failover?
> >>
> >> Thanks,
> >> Dave
> >>
> ><..rest snipped..>
> >
> >Hi Dave,
> >
> >I think one of the problems here is down to terminology -
> terms like
> >"share" are overloaded and the terms used have changed
> (and are clearer)
> >in W2k3.
> >
> >Anyway, the first thing to do is to separate Dfs from
> FRS. Dfs will run
> >quite happily without FRS and the thing to do is to get
> yourself a
> >functioning Dfs configuration before you start adding
> the FRS component.
> >
> >From the Dfs MMC, create a new Dfs Root (I'll assume a
> domain-based Dfs
> >root here). This will create the Dfs Root Share at the
> location you
> >specify. I use "G:\DfsRoot" as my DfsRoot folder name
> and "Dfs" as my
> >share name (but I've obviously no imagination!)
> >
> >Next, from the Dfs MMC, add *existing* shares as LINKS
> in the Dfs Root.
> >This creates logical copies of the existing shared
> folders in the Dfs
> >Root folder (they're actually "reparse points" in the
> file system).
> >
> >So, if you had an existing file structure with two
> shared folders (S1
> >and S2) like this:
> >
> >G:\
> >|
> >|- S1
> >|
> >|- S2
> >
> >....you would now see:
> >
> >G:\
> >|
> >|-DfsRoot
> >| |
> >| |-S1
> >| |
> >| |-S2
> >|
> >|-S1
> >|
> >|-S2
> >
> >
> >And your clients can connect to "\\domain.com\dfs\s1"
> and so on.
> >
> >Note that you CAN manually create folders and files in
> the filesystem
> >under G:\DfsRoot - but DON'T do this - it will only
> confuse things!
> >
> >Now you can add a redundant Dfs Root and additional
> links in the MMC to
> >dfs\s1 and dfs\s2 (on another server probably). If you
> weren't using
> >FRS you would manually copy the contents of dfs\s1 to
> another share on
> >another server and add this share as another link to
> dfs\s1. Clients
> >who connect to dfs\s1 will now be redirected to one of
> the two
> >alternative shares. It will be down to you to manuually
> sync the
> >contents of the two shares to ensure clients see a
> consistent file
> >structure.
> >
> >OK, so that's the Dfs part.
> >
> >Assuming you do want to use FRS to replicate the
> information between the
> >two (or more) redundant links... In this case you should
> set up the Dfs
> >exactly as above. Then create the shares on the second
> server (but
> >DON'T copy any data into the shares). Add the shares as
> additional
> >links to in the Dfs MMC and tell it you want to
> replicate the data. Now
> >FRS will kick in and copy the data for you. Any on-
> going changes to the
> >data on either server will be synched by FRS to the
> partner replica(s).
> >
> >NOTES! You can enable replication at the Dfs Root
> folder level - but
> >the strong recommendation (generally) is NOT to do
> this. Just replicate
> >the individual links that are children of the Dfs Root.
> >
> >Also, if you have LOTS of data you can pre-stage files -
> refer to the
> >Knowledge Base for more info. I replicate 30GB on a LAN
> and I didn't
> >bother pre-staging.
> >
> >Other comments:
> >
> >Before you start using FRS, download Ultrasound and read
> the included
> >online help file - it will explain all this stuff much
> better that I can
> >and a lot more besides! Once you start using FRS use
> Ultrasound to
> >monitor your file replication.
> >
> >In answer to your questions above: when you have a
> redundant Dfs Root
> >then the participants are effectively peers - so it
> doesn't make sense
> >to think about one partner becoming the "active data
> directory". All
> >partners will be online and client requests will be
> forwarded to
> >different partners accordingly. If one of the partners
> is unavailable
> >(maybe because of a HD crash) then clients will be
> redirected to an
> >alternative partner (the clients won't have to
> disconnect and reconnect
> >for this to happen).
> >
> >If a partner is offline for a long time and is then
> brought back online
> >then the data between the partners will no longer be in
> sync. In this
> >case you'll need to use FRS recovery procedures (there
> are lots of KBs
> >about this) to restore things properly.
> >
> >General advice is NOT to try to help FRS along by
> copying data around
> >amongst the replicas yourself - this will only break
> things.
> >
> >Regards
> >Chris
> >
> >
> >
> >.
> >