Managing Shared Network Resources

On PC networks, machines can share network resources, which is both good and bad. Users can share resources when they need to without consuming valuable server resources or running through time-consuming procedures, but this capability often complicates users' attempts to locate shares and administrators' efforts to manage these resources. Windows 2000 includes two features that simplify network resource sharing: resource publishing and Distributed File System (Dfs). To publish resources, you create printer or share objects in Active Directory (AD) so that users can search for them instead of browsing for them. Because of the sheer number of shared folders that exist on most networks and how often new shares appear, it's not practical to publish all the shared folders on your network. Doing so is difficult from an administrative perspective and can cause unwanted replication. Often, the better solution is Dfs.

Dfs
To access shared folders, users need to either map a drive to the share or know the name of the machine that the folder resides on. These methods don't scale well on a large network or with infrequently accessed resources, so users often resort to browsing for the resources or determining the machine name manually. Dfs simplifies the search process by creating a logical directory tree that's independent of the physical locations of the shared folders themselves, uniting shared folders from different computers into one namespace. In other words, instead of having 10 shares located on 10 servers, which would require users to know both the server and share name to gain access, you create one Dfs root with links pointing to the individual shares. So, when users need to access any of the original shared folders, they connect to the Dfs root and see all shares as if they resided on one machine. Dfs simplifies network access to resources regardless of a resource's actual location and lets administrators manage all resources from one location.

Standalone DFS and Domain DFS
You set up and manage Dfs using the Microsoft Management Console's (MMC's) Distributed File System snap-in. To create a new Dfs root, start the Create New Dfs Root Wizard. The wizard lets you create two Dfs root types: standalone and domain Dfs roots. A standalone Dfs root has some risks associated with it. Users who typically access shared folders by connecting to the Dfs root server lose access if the server becomes unavailable. The shares still exist on the servers on which they physically reside, but because your users access them through the Dfs root, you are vulnerable to a single a point of failure. The Partition Knowledge Table is a repository of information about the Dfs topology and its mappings to physical shares. On a standalone tree topology, the system stores the Partition Knowledge Table in the Registry, so the only way to restore a failed Dfs root is to restore the Registry. When you create a domain Dfs root, the system stores the Partition Knowledge Table in AD, eliminating the single point of failure.

After you establish your initial Dfs root, you can create additional root replicas to provide redundancy for your Dfs tree. You can also create replicas of individual Dfs links to provide redundancy and limited load balancing.

Client Access
Users can type \serverdfs_root to view the Dfs topology and see a list of all the shares in the tree. When users chose the Dfs link they want to access, the system refers their network client to the physical location of the actual share. To speed access, the client caches the referral so they can bypass the Dfs root the next time they try to access that share. Of course, this feature requires a Dfs-aware network client, which Win2K includes. Windows NT 4.0 Service Pack 3 (SP3) supports access to standalone Dfs roots, as does Windows 98. To allow Windows 95 clients to access Dfs roots and NT 4.0 clients to access to domain Dfs roots, you need the appropriate AD client. To learn how to get the client, visit the Microsoft Web site.