Win2003 DFS issue

[hobo]

Hi all

I have a problem with a new customer's Windows 2003 server set up I have recently been asked to look at. The customer went live with this set up just before xmas and problems have persisted since day 1.

I'm not a big expert in DFS, have read around a bit but so far nothing which has said "this is not a good idea"

The situation is as follows. Said customer has two sites connected together over the WAN using E3. The primary site has 400 users (Site A), the secondary has about 200 users (Site B).

At the moment they have DFS shares created which is replicated using FRS to both sites.

User's at each site access the file shares via \\dnsname\DFSRoot\Foldername

My concern is as follows. If someone can tell me if I am on the right track or not then I would be grateful.

1. User at site A opens up a file in folder say called "Admin" and edits a file. In reality DFS saves this change to \\SiteA_Server\Sharename\folder\filename

2. User at site B opens up the same file but DFS has looked in \\SiteB_Server\Sharename\folder\filename

Are we now not in a situation where there will be a replication conflict or a user is looking at the wrong version of the file?

I tried to set this up on a VMWare environment and FRS happened pretty much instantaneously but of course in production I have lots of users and I can see situations where FRS may get clogged up with big changes.

If anyone is still following this and can help then I would be most grateful.

Thanks

[cluberti]

You are correct, if the DFS replication doesn't happen and a file exists at both locations, you can get into version conflicts. Since DFS doesn't provide file locking, it *is not* a good solution for regularly edited documents. If your customer really must have DFS for file shares that are significantly active, there are 3rd party software tools to provide file locking, but it's an expensive solution to a poor implementation. DFS will still try to copy the older file (because the newer one will win the conflict) to the \DfsrPrivate\ConflictandDeleted folder inside the folder that the file is located in, but again DFS does not have any distributed file lock tracking mechanisms and is definitely not a good idea for document locations that will be updated frequently by multiple sites. Again, if you must, you should look into 3rd party file locking tools like PeerLock or similar.

There are better alternatives too, however, that aren't file-server related - if you're looking to implement something for collaborative document sharing, Sharepoint is technically Microsoft's solution to this problem, coupled with WAN acceleration technologies at the remote sites and 3rd party solutions for geo-distribution (if you want to distribute the data load rather than centralize it). It's a bit aggressive, and the client may have gone with DFS because it was "free" and bundled with Windows, but DFS was most definitely *not* meant to store regularly updated collaborative data, again because of the aforementioned file locking and version conflict issues. It just isn't good for that - it's good for things like user profiles, DR data, read-only archives, etc, but if you have a "collaboration share" where lots of users are updating lots of files, DFS is most definitely not the first (or second, or third) option I would have considered because it just isn't designed for that kind of workflow.

[fizban2]

just a side note, if you are still using 2003 DFS with FRS, please PLEASE upgrade to 2003 R2 or 2008. DFSR in 2003 R2 no longer uses FRS, the new algorithem used is more efficent and better suited for WAN activity