GET-IT: TEAMS DAY | 1-Day Free Virtual Conference all about Teams. Here on - 8/12/20 GET-IT: TEAMS DAY - 8/12/20

DFS Replication Dilemna

Home Forums Server Operating Systems Windows Server 2012 / 2012 R2 DFS Replication Dilemna

Viewing 1 post (of 1 total)
  • Author
  • Avatar

    Hello all. I find myself in a bit of a bind with DFS Replication. I have made limited use of DFS and FSR in the past.

    It’s a fairly simple setup. The office has about 900GB – 1TB of files in four shares, and growing. The end users wanted the best possible reliability and seamless fault tolerance.

    So, I set up DFS Replication to replicate the data between two servers, and published the replication sets in a DFS Namespace. So if one server fails, operations can continue as usual while the problem is rectified. It is working quite well, in fact I am pleasantly surprised how well, but there is a problem.

    The majority of the edits and updates are on AutoCAD drawings. AutoCAD evidently uses lock files to prevent contention between users. AutoCAD creates a .DWL file in the folder with the drawing when it is first opened. It looks for lock files when opening files; if another user tries to open the file, AutoCAD will see the .DWL and only allow the second user to open the file read only.

    I believe the problem is that the .DWL files are not always visible to the second user, presumably because DFS has routed the two users to different servers. If the second user opens the file before the .DWL has replicated, a second .DWL will be created, and confusion will ensue when replication occurs, possibly causing one user or the other to lose their work.

    I found a product called Peersync that addresses this problem, but it is quite expensive so I am considering alternatives.

    It occurred to me to configure one server as read-only. This would be not be entirely seamless; if I understand correctly, in the event the read-write server failed, the users would only have read-only access to files on the remaining server. However that is probably close enough to suit their needs. I am not sure what I have to do to make this change.

    I also considered having the users access the shares directly on one server under normal circumstances, and only use the DFSN names in the event of an emergency. Since the DFSN UNCs are long and unfamiliar, I think they’d comply.

    I am open to any and all comments and suggestions, including using some tool other than DFS Replication and DFS Namespaces. The goal is to provide access to the file shares even in the event of a single server failure. Thanks in advance for your remarks.

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.