Windows Server 2003 DFS
The DFS scalability limits for Windows Server 2003 are published online in a frequently asked questions (FAQ) document. For more information about DFS limits in Windows Server 2003, visit the following Microsoft Web site:
Windows 2000 DFS
- Resource: Maximum number of Fault Tolerant roots supported per domain
Limit: 1 per member computer \ domain controller, no maximum number of roots per domain. - Resource: Maximum number of stand-alone roots supported per computer
Limit: 1 - Resource: Maximum number of links in a domain DFS
Limit: 5000 - Resource: Maximum number of links in a stand-alone DFS
Limit: No hard coded limit. 30,000 links within supported limits; Operating System boot time and DFS Snap-in performance degrade beyond this number. Server response time to referrals not impacted. 100,000 links tested by Microsoft Development but not recommended for production deployments as boot time represents denial of service. - Resource: Maximum number of root replica members
Limit: No hard coded limit, Maximum of 16 recommended. Having too many root replica members may cause scalability issues in a namespace that changes on a daily basis because of the synchronization that needs to occur between the root replicas each time DFS namespace information is changed. - Resource: Maximum number of child replica members
Limit: No hard coded limit.
Stand-alone DFS in Windows 2000 moves the DFS configuration to the Software hive in the registry; the 13-MB registry limit is not a limiting factor. The boot performance of the operating system and modification of the DFS configuration slows dramatically when more than 10,000 links are configured in DFS. There are no reports of performance degradation to the DFS client when the system is running. Customers who need more than 10,000 links must create multiple DFS roots.
In domain-based DFS, the DFS namespace, which includes the DFS root, the links, and the root and link replicas and their site information, is stored as one object in Active Directory. Microsoft recommends that administrators limit the size of this object to 5 MB. Exceeding this size can cause certain administrative actions to not work, such as adding links or adding link replicas. The following formula can be used to determine the size of the object while planning the namespace:
For each DFS root and for each link, the DFS overhead is 180 bytes.
The total space, in bytes, taken up by a root is 180 + (number of characters in DFS name * 4) + (Number of characters in each root replica * 2). The total space, in bytes, taken up by each link is 180 + (number of characters in LinkNameRelativeToDomainName * 4).
For each DFS root or link replica, the DFS overhead is 20 bytes.
The total space, in bytes, taken up by a replica is 20 + (number of characters in replica name * 2).
For each unique server that is added as a replica, site information takes up some space. This space, in bytes, is: 12 + (number of characters in server name + number of characters in site name) * 2.
Finally, comments on DFS root and links, which can be set and viewed in the DFS snap-in, increase the size of the DFS blob. Each character in the comment field is a Unicode character, which is 2 bytes.
The current size of the DFS "blob" appears in the top of the output from the dfsutil /view:domainname.com\dfsroot command.
DFS 4.1
DFS 4.1 is an add-on component that runs on Windows NT 4.0-based workgroup computers, member servers, and domain controllers. To download the DFS components, visit the following Microsoft Web site:
The DFS configuration is stored on a per-computer basis in the Windows NT 4.0 registry.
There is no �256� replica limit. This is a documentation issue that is being fixed in various places. There is no hard limit on the number of DFS targets (or replicas).
Client Optimization
DFS servers store information about the DFS topology in a structure called the Partition Knowledge Table (PKT). The PKT data structure includes the DFS directory name and the list of referral servers that DFS clients actually connect to. DFS clients "walk" the locally cached subset of the PKT from the top down when a directory in the DFS name space is used, and return to the DFS root or child replicas when a TTL timer expires, the client is rebooted, or none of the servers in the client's PKT are available.
After the PKT is cached, the client burden shifts away from the DFS root and child replicas to the referral servers. The scalability question becomes "How many SMB sessions can be supported by the DFS root, child replicas, and referral servers to which DFS clients connect?".
Modification of the AutoDisconnect value for the Windows NT Server service may be appropriate to balance memory overhead associated with servers maintaining idle sessions and session reestablishment from idle clients reconnecting, depending on how frequently the directory in the DFS name space is used and the time the DFS configuration is cached on the client (the TTL value defined on the server).
Use long AutoDisconnect values for paths consistently used several times per day (such as home directories, or when there is only one physical server). Use shorter AutoDisconnect times for infrequently used data or paths representing installation servers on which file copying or program installations might last 10-60 minutes. Consider the additional roles (such as file & printer sharing, Web server, or program server) the server plays and hosts the DFS root.
A busy DFS server might maintain as many as 3000-6000 sessions. The AutoDisconnect value for such a server can be reduced for DFS servers hosting volumes with long TTL values.
For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
138365
How Autodisconnect Works in Windows NT