If your organization has similar information located on multiple servers throughout your domain, it can be confusing for users who access the data. This problem can be overcome using Microsoft’s Distributed File System (DFS).
There are many reasons to use DFS. For example:
- You can improve server load balancing by redistributing shared folders.
- You can accommodate large numbers of users who have to access multiple shared folders or users who require uninterrupted access to shared folders.
- You can improve access for those who need to reach the organization’s Web site for internal or external use.
Let’s take a closer look at DFS and the advantages it offers.
Overview of DFS
Microsoft’s DFS is a new concept in Windows 2000. Administrators can make it easier for users to access and manage files that are physically distributed across a network. For users, it’s transparent and no longer requires them to know the physical location of files in order to access them. Even when you change the physical location of a shared folder, user access to the folder is not affected. Multiple drive mappings are no longer needed when you employ DFS. And scheduled maintenance of a server is simplified for administrators because the server can be taken offline without disrupting user access. Thus, if you select the root for the Web site as a DFS root, you can move resources within the DFS without breaking any HTML links.
Establishing a DFS root
You can establish a DFS root as a stand-alone root or a domain-based root. A stand-alone DFS root doesn’t use Active Directory and can have only a single level of DFS links. It can’t have root-level DFS shared folders.
A domain-based DFS root must reside on a domain member server and will have its DFS topology automatically published to Active Directory. It doesn’t have a limited hierarchy, allowing multiple levels of DFS links.
DFS includes a client-based component in addition to the server-based component. An administrator defines the length of time a DFS client caches referrals to a DFS root or link. Computers that run the DFS client must be members of the domain for the DFS root.
The contents of folders will always be available to users by replicating that content to other root shares or DFS shared folders in the domain. Replication of a DFS root to another server in the domain also ensures that the distributed file system associated with that DFS root will be available to domain users in the event that the host server becomes unavailable. Replication simply copies the contents of one DFS root to another root share, or from one DFS shared folder to another DFS shared folder.
A DFS link target folder must be a Windows 2000 folder in order for the target folder to have subfolders. Currently, you can assign a maximum of 1,000 DFS links to a DFS root. The maximum number of DFS shared folders allowed in a set of shared folders is 32.
DFS should be installed on an NTFS file system to take advantage of the extra security. Automatic replication will not work if the DFS is installed on a FAT file system. The schedule you set up for synchronization should take into consideration the load balancing on your servers. For instance, you would not want to synchronize your servers during periods of heavy traffic. Be sure to save the DFS console once you have created the DFS root. If the content in a DFS shared folder changes frequently, you should use a shorter cache time-out period to make sure that the clients refresh the data.
When implementing Windows 2000 in your organization, be sure to plan ahead and take advantage of the new advanced features like DFS.
If you’d like to share your opinion, start a discussion below or send the editor an e-mail.