DFS (Distributed File System) was introduced in Windows 2000 to manage shared resources across a network and to more easily locate and access them. However, its capabilities were limited, particularly in facilitating high availability across distributed environments; generally, users found it cumbersome to replicate shared resources over slow links. DFS in Windows Server 2003 offered only modest improvements. The new DFS R2 with DFS Namespaces addresses a number of critical shortcomings found in previous versions. It now offers byte-level replication, deletion management and email reporting – making it a more robust, reliable and more “network-friendly” replication tool. But it is still incomplete and inadequate for many of today’s more “collaborative” environments where data needs to be shared in real-time, i.e., among branch offices and project teams operating in multiple locations. DFS replication works by way of a “pull” process. As such, it is not real time. The narrowest scheduling window is every 15 minutes, which exposes “live” documents to version conflict. Between the time a document is closed and replicated from point A, a colleague working from point B can make changes to a previous version – 15 minutes can be an eternity when even just two people are collaborating on a project, often against a strict deadline – problems escalate when, as is often the case, project teams are made up of several people operating from several locations. During the initial replication of DFS Replication, you must designate a primary master server. All files on this primary server are deemed to be authoritative; during initial replication, the primary member’s files will always win the conflict resolution that occurs when the receiving members have files that are older or newer compared to the same files on the primary member. Using DFS replication on a scheduled basis narrows the window for version conflict, but doesn’t eliminate it. The surest and simplest way of eliminating version conflicts when using DFS is to add a true file locking solution – one that offers, at a minimum, real-time detection of file use and immediate remote locking. This assures that when a file is open at location A, all other versions – say local copies at various branch offices – are locked down, preventing anyone from opening and revising it. When the file closes, the file lock is immediately released, though there’s one important caveat to bear in mind: using DFS, it takes a minimum of 15 minutes for the released file to be replicated, during which time version conflicts can — and do — occur. A true solution offers both real-time file locking AND real-time replication, thus eliminating version conflict and providing a fail-safe collaborative framework.
