Distributed File System

Setup Considerations

System requirements for the Dfs server or for a Dfs client are limited to the amount of memory consumed by the PKT on each of them.

Dfs Server

Dfs service is a core Windows 2000 service that is installed automatically on Windows 2000–based servers. Any server that participates as a Dfs root (either stand-alone or domain-based) must be running Dfs service. All Windows 2000–based domain controllers must also be running Dfs service. The servers that run Dfs service can be domain controllers or member servers such as workgroup servers in the domain.

Dfs service is responsible for maintaining an up-to-date version of the PKT and for handing out referrals to clients that map the logical namespace to physical topology. A server that hosts a stand-alone Dfs root is completely responsible for maintaining the one and only copy of the PKT for the Dfs namespace.

A server that hosts a domain-based Dfs root uses a local copy of the PKT for the Dfs namespace that it obtains from Active Directory. The server synchronizes itself with Active Directory in two ways:

When the server starts up or the Dfs service is restarted, the server goes to a domain controller in the domain and obtains the PKT.
When changes to Dfs are made in Active Directory, all servers that participate in the domain-based Dfs receive the changes when Active Directory propagates the changes throughout the domain.

Dfs Client

For a client to take advantage of Dfs, specific extensions must be added to the file subsystems of the underlying operating systems. The availability and capabilities of these Dfs-aware extensions are as follows:

Windows 2000 Ships in the box and provides full access to stand-alone and domain-based Dfs roots. This includes a shell extension to view the underlying DNS-to-UNC mappings for shared folders in a Dfs namespace.

Windows NT 4.0 Workstation/Server Included in the box with Service Pack 3 to provide access to stand-alone Dfs roots.

Windows 98 Included in the box to provide access to stand-alone Dfs roots. Download the Active Directory Client Pack for Windows 95 or Windows 98 from http://www.microsoft.com for domain-based Dfs.

Windows 95 Download the Active Directory Client Pack for Windows 95 or Windows 98 from http://www.microsoft.com.

TTL Guidelines

Dfs clients cache referrals from the PKT for TTL minutes unless access to the cached Dfs path is gained before the TTL expires or before the client is restarted. Restarting the client removes all PKT caching information and is the only way of forcing Windows NT 4.0–based clients, Windows 98–based clients, and Windows 95–based clients to re-randomize their selected alternates except waiting for the TTL to expire. Windows 2000–based clients can use the Clear History button in the Dfs property sheet of Windows Explorer to flush the cache.

The referral for a Dfs shared folder never expires as long as the Dfs client continues to gain access to the shared folder before the TTL expires. Windows NT 4.0 used a TTL of 7 days. Administrators may use the Dfs administrative console to define the TTL for each Dfs root or link. The default TTL of 5 minutes ensures that new servers are readily found.

Setting the TTL value too short decreases any caching benefits on the part of the client and increases the number of connection attempts to the Dfs server, but ensures an accurate status of available shared folders and root and alternate servers. Increasing the TTL reduces network traffic and queries to the Dfs root, but leaves newly added servers underused until the client requests a new PKT that contains the changes for the Dfs tree.

If you set the TTL expiration too long in a multiserver environment, you risk obsolete referrals. Suppose that you set the TTL for a month, but your clients gain access to the shared folders at least once a week. In this case, the client would never refresh its cache and learn about changes to the Dfs namespace. If you only have a single server, a long TTL is acceptable because, if the server becomes unavailable, all clients refresh their caches automatically to gain access to a replacement server.

Consider the number and stability of the servers being used, how dynamic the data is, and how often clients want or need access to the data. For shares that are represented by a single shared folder, such as home directories, long TTLs on the order of two to seven days might be appropriate. If a single replica represents a volume, the Dfs client's failover mechanism locates the replacement server without interruption to the client. For an environment where new shares are being added or removed constantly, such as a large-scale development project that contains daily builds of an application to which hundreds of users have access, consider using TTLs in the 30-minute to 3-hour range.

To change a TTL value for a Dfs link

Start the Dfs administrative console.
Expand the Dfs tree in the left pane, and right-click the Dfs link that is being changed.
Click Properties on the resulting pull-down menu.
On the General property page, change the referral cache time.

Autodisconnect Guidelines

Use long autodisconnect values for paths that are used several times a day, such as home directories. Use shorter autodisconnect times for infrequently used data or paths that represent install servers, where file copies or application installs might last from 10 to 60 minutes. Take into account the additional roles of the server (for example, file and printer sharing, Web server, application server) in addition to its role of hosting the Dfs root. Here you are trading off increased network traffic that is a result of establishing sessions for maintaining an increased number of sessions on the server.

For more information about how Autodisconnect works, see the Microsoft TechNet link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Search the Technical Support section of this site for Knowledge Base articles and other sources of technical information.