File locking issues on DFSR (Windows 2003/2008)

Posted on August 22, 2010

Are users complaining that shared documents are being overwritten by other users?
Are user not being prompted that a file is Read-Only when opened by another user?
Are you running a distributed file system with replication?

You’ve enter the world of inherited file locking drama!

The issue is Windows Server 2003 and 2008 presently have no centralized file-locking management. When a user is referred to a server within a DFS with replication, the local server locks the locally requested file. The remaining member services are not sent the same notice to lock the same file and as a result, if another user is referred to a different member server, the most recent save wins. There is presently no concrete method in-place to tackle the issue.

By default a DFS configuration uses the "lowest-cost" or "random" referral methods. If you use these types of referrals you will be subject to the file-locking issues.

The good news is depending on your company’s size and requirements you may have a few workarounds.

1) Ask users to inform one another when documents will be in use (painful!!!)
2) Utilize the built-in conflict resolution folders managed by Windows 2003/2008 DFS
3) Override the lowest-cost and random referral orders with static referral order.

I recommend the 3rd option. It allow for fault-tolerance and let’s face it, your time is valuable! Do you really want to dig through conflict folders? Using this method will force users to share the same DFS server for specific folders. Generally depending on the size of your business this isn’t a huge concern. If the primary DFS server is offline the clients will be redirected to the next server in sequence.

If your goal is to also introduce a load-balancing strategy you will have to manually segregate and deploy your DFS carefully. Target major folders or departments to a reserved DFS server.

For example:

If you have 3 departments (Accounting, Sales and Support). The DFSR structure should encompass all of these departments across all servers. The manual load-balancing would be as follows:

-> \\\Accounting (1st static referral order "first among all targets" on serverA)
-> \\\Sales (1st static referral order "first among all targets" on serverB)
-> \\\Support (1st static referral order "first among all targets" on serverC)

All accounting users will be accessing serverA by default, sales serverB and support serverC. All of these folders are replicated throughout the DFS and as a result, if ServerA went down, the next server you statically assign would take over the responsibility.

To access to Override options in your namespace folders:

DFS Management Console -> Namespaces -> default root namespace -> links (right click) -> properties -> advanced tab

Comments (5) Trackbacks (2)
  1. Your suggestion is fine if you are using DFSR for redundancy. But some of us use it for speed over slow links (branch offices). Forcing everyone in my California office to access a server via a relatively slow link is not going to go over well when they can just access to local server.
    So option #3 isn’t the best for our situation. Unfortunately, neither are the other 2, as you pointed out.

  2. In your situation, no it wouldn’t. You should really look at how your data is organized at each location. Relying on DFSR to facilitate a country wide file system isn’t realistic, using it for local redundancy is. Using something like SharePoint makes more sense for the high-traffic documents being used from multiple locations, DFSR and VPN do not.

Leave a comment