Proper Usage of DFS?

[Eric Fleischman [MSFT]]

Hey Kevin,

Yes, I hear what you're saying. FRS sounds ok in this scenario, however the
mod's in many places is what I'd consider to be problematic.

If you think your users might do this, I'd be nervous to deploy FRS. Any
latency introduced (no matter how large or small, IE if FRS were the most
efficient or the least it would still suffer from this problem) might cause
us to enter this scenario.

What is the business goal you're trying to achieve? High availablity?
"Closeness" of the content to the users? Let me know and we'll try and
tackle this thing either with FRS or another technology as appropriate.

Also, cross posting to DFS_FRS which I meant to do from the start.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

"cst112" <cst112no-s...@yahoo.com> wrote in message
news:vlq49f...@corp.supernews.com...
> The shared information would be fairly static. The biggest thing is
> availability at the different locations.
> One thing that does concern me is if someone does make a change in a file
> and another person has the file open and is changing it at the same time,
it
> would overwrite the first version. Currently the way the information
flows,
> I don't see it as a problem because only certain people have access to
> updating this information.
> So I guess FRS is an option but it certainly isn't the most ideal.
>
> Kevin
>
>
>
> "Eric Fleischman [MSFT]" <efl...@online.microsoft.com> wrote in message
> news:eBXMl#ldDHA...@TK2MSFTNGP12.phx.gbl...
> > I'm sorry Dmitry, but I couldn't disagree with your post more. I think
> that
> > FRS (note that it is FRS, not DFS, that does the file replication; DFS
> isn't
> > replicating anything, it is nothing more than an intelligent redirection
> > system) is an excellent solution so long as you use it approprately, and
> > understand where the strenghts in this technology lie.
> >
> > If your data is highly transactional (user profiles, frequently-changing
> > documents, etc.) FRS is probably not the way to go. The overhead is
high,
> > and we have some technological limitations (such as last-writer wins and
> > changes can be lost of a file is modified in two places at once) that
make
> > this a less-than-idela solution. On the flip side, if you are trying to
> make
> > somewhat-static content, or even content that isn't changing very very
> > frequently, available in many locations FRS is an excellent solution.
> > Examples of this include:
> > 1) Servers that share out software for install by users. This way they
go
> to
> > a single location no matter what office they are in, and it always
selects
> a
> > local mirror (\\products, etc.)
> > 2) A series of documents for archiving - I worked with a customer who
> > archived all of their sales presentations and it was replicated among
> > several servers around the world
> > 3) Documents that change somewhat regularly, but won't be edited on many
> > servers by many users; edit's will be done on a single server in a
single
> > location.
> >
> > Those are the first three that pop in to my head, but there are others.
> Read
> > the FRS whitepapers and KB's.
> >
> > The key to success with FRS with DFS is ensuring your data is not
changing
> > very rapidly, modifying your replication topology as appropriate (many
> > networks have a hub-and-spoke topology yet they leave FRS replication
> among
> > the servers to be the default fully-meshed topology; easily changed for
a
> > better solution with the appropriate tool and it yields faster
replication
> > due to the network is resides on) and modifying both staging and journal
> > sizes for the data set in question.
> >
> > Is FRS *immediate* replication of hundreds of megs/gigs at a time?
> > Absolutely not. I am saying that for many situations it is an excellent
> > solution, is very reliable and is far better than many of your other
> > options.
> > Like all technology FRS should be evaluated for the situation at hand
and
> > should be weighed against other solutions (manual robocopy scripts, no
> > replication at all, etc.). No technology solves all problems and
addresses
> > all situations.
> >
> > ~Eric
> >
> >
> > --
> > Eric Fleischman [MSFT]
> > Directory Services
> > This posting is provided "AS IS" with no warranties, and confers no
rights
> >
> >
> > "Dmitry Korolyov" <d_...@nospamformorons.mail.ru> wrote in message
> > news:eNi87Zld...@tk2msftngp13.phx.gbl...
> > > According to my experience, DFS is not a very good replication
solution.
> > It
> > > replicates way too slow (about 30 minutes for a 400 megabytes over
fast
> > > ethernet). It works fine for aliasing purposes, though.
> > >
> > > Do the files need to be available at all locations?
> > >
> > > --
> > > Dmitry Korolyov
> > > d_...@nospamformorons.mail.ru
> > > To e-mail me, remove "nospamformorons"
> > > from the address.
> > >
> > >
> > > "cst112" <cst112no-s...@yahoo.com> wrote in message
> > > news:vlprpad...@corp.supernews.com...
> > > > I have several servers across a vpn. The connections across these
are
> > > slow
> > > > vpn connections. I have one shared directory on the main server
that
> I
> > am
> > > > sharing with users from all locations. The problem is the
connections
> > are
> > > > really slow. Will using DFS solve this problem.
> > > >
> > > > I can create a DFS and the data on the main server will be
replicated
> on
> > > the
> > > > local servers so it will allow users from remote locations to modify
> and
> > > > edit files without taking a long time and also freezing.
> > > >
> > > > If DFS is not the solution to this, what could be??
> > > >
> > > > Thanks,
> > > > Kevin
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[cst112]

Thanks Eric,

You answered my questions on the technology itself and the limitations.

Kevin

"Eric Fleischman [MSFT]" <efl...@online.microsoft.com> wrote in message

news:uNBIbJmd...@TK2MSFTNGP12.phx.gbl...