Distributed File System: Namespace Scalability and Sizing Questions

Artigo
08/08/2011

Updated: August 3, 2011

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2

This FAQ answers questions about namespace scalability and sizing for Distributed File System (DFS) namespaces. For other questions, see DFS Namespaces: Frequently Asked Questions.

Namespace Scalability and Sizing Questions for Windows Server 2003

Can I enable FRS replication on a DFS link whose targets are in different domains?

Yes, if you are a member of the Enterprise Admins group, you can configure FRS replication on a DFS link whose targets are in different domains in the same forest. If you are not a member of the Enterprise Admins group, permissions must be configured as follows:

You must have Read and Create All Child Objects permissions for the computer object of each computer that will be part of the replica set.
You must be a member of the local Administrators group on each computer that will be part of the replica set.
You must have Read and Create All Child Objects permissions for the File Replication Service container and all its child objects. Although the File Replication Service container can exist in every domain, you must add these permissions to the File Replication Service container that is in the domain where the domain-based root is configured.

If any of these permissions are not configured correctly, you will get an Access Denied message when you try to enable replication by using the Configure Replication Wizard in the Distributed File System snap-in.

How can I estimate the size of each namespace and folder target in the DFS Active Directory object?

Each element in the namespace (namespace name, folder target name, target path, and comments) takes up space in the DFS Active Directory object. The amount of space can vary depending on the number of characters used in each element.

The following formula assumes that each element is 10 characters, and that the namespace is using the Windows 2000 Server mode:

Root: Approximately 300 bytes
Each root target: Approximately 150 bytes.
Each link in the root: Approximately 320 bytes.
Each link target: Approximately 120 bytes.

For example, if you create a root (300 bytes) with 3 root targets (150 bytes × 3) and then add 100 links (100 × 320 bytes) with each link having 3 link targets (100 × 120 bytes × 3), the DFS Active Directory object will be approximately 300 + (150 × 3) + (100 × 320) + (100 × 120 × 3) = 67 kilobytes (KB) in size.

How can I work around the DFS size limits?

You can use the following methods:

Keep comments to a minimum. When you add a root target or link target in the Distributed File System snap-in, you can enter comments that describe the target. If you plan to create a large namespace, use minimal comments, if any, because they can increase the overall size of the namespace.
Create multiple namespaces. If you need to create more than 5,000 links in a domain-based DFS namespace, you can create multiple DFS namespaces that meet the recommended sizes, and then link them together. This method is often referred to as cascaded DFS, and links pointing to another namespace are often called interlinks. For more information, see the following question "What are the rules for using interlinks?"
Enable root scalability mode. When root scalability mode is enabled, you can use more than 16 root targets. For more information, see "How many root servers can host a domain-based DFS namespace?"
Migrate root servers running Windows 2000 Server to Windows Server 2003. Root servers running Windows Server 2003 do not add site information to the DFS Active Directory object. As a result, if all root servers run Windows Server 2003, DFS can store more root and link information to the DFS Active Directory object before reaching the recommended 5-MB limit. After you migrate your Windows 2000 root servers to Windows Server 2003, you can remove the static site information from the DFS Active Directory object by using the /PurgeWin2kStaticSiteTable parameter in Dfsutil.exe.

How do I measure the size of an existing DFS namespace?

You can use the command-line tool Dfsutil.exe that is included in the Windows Server 2003 Support Tools. Use the following syntax:

Dfsutil /Root:\\dfsname\root**/View**

How does DFS work across domains and forests?

DFS clients periodically discover new domains in the local forest and in trusted forests. This discovery process, which occurs every 15 minutes by default, runs against a domain controller from the domain that hosts the client's computer account. To avoid real-time queries to domain controllers in the domain, the referrals received during the discovery process are stored in a special table, called the domain cache or SPC cache. As a result of this process, clients can more quickly distinguish queries for fully qualified domain names from fully qualified computer names.

To determine the domains and forests in which a client can access domain-based namespaces, you can view the domain cache on a client computer by using the Dfsutil.exe command-line tool with the /spcinfo parameter. The following text illustrates the output displayed when you use this command.

[*][dc-01.contoso.com]
[*][CONTOSO]
[*][contoso.com]
[+][contoso.com]
     [-dc-02.contoso.com]
     [+dc-01.contoso.com]
     [-dc-04.contoso.com]
     [-dc-03.contoso.com]
[-][AFRICA]
[-][EUROPE]
[+][CONTOSO]
     [-DC-02]
     [+DC-01]
     [-DC-03]
     [-DC-04]
[-][europe.contoso.com]
[-][africa.contoso.com]

The preceding sample output can be interpreted as follows:

Entries preceded by [*] are provided by the Workstation service.
The [+] next to the domain controller named DC-01 under [contoso.com] and [CONTOSO] indicates that it is the active domain controller for that domain. The client will contact this domain controller as needed to obtain domain name referrals, domain controller referrals, and domain-based root referrals.
The client has already contacted DC-01 to receive domain name referrals for Contoso.com, Europe.Contoso.com, and Africa.Contoso.com.
The client has already contacted DC-01 to receive domain controller referrals for the Contoso.com domain.

If an organization has a large number of trusted domains and forests, it is possible that clients will not be able to access all domain-based namespaces within the trusted domains and forests. This limitation can occur when the list of trusted domains and forests is too large to fit in the client's buffer. By default, DFS clients send a 4-KB (2,048 Unicode character) buffer to a domain controller when requesting domain name referrals. If the list of domains is too large to fit into the 4-KB buffer, DFS clients automatically increase their buffer size to accept the list of domains, up to a maximum of 56 KB.

If the list of domains exceeds 56 KB, DFS puts as many domains in the buffer as it can until the buffer reaches 56 KB. DFS then writes an entry with the ID 14536 in the system event log of the domain controller that provided the domain referral. When populating the buffer, DFS gives preference to local and explicitly trusted domains by filling the buffer with their names first. Consequently, by creating explicit trust relationships with domains that host important DFS namespaces, you can minimize the possibility that those domain names might be dropped from the list that is returned to the client.

When populating the cache, DFS gives preference to local and explicitly trusted domains by filling the cache with their names first. Consequently, by creating explicit trust relationships with domains that host important DFS namespaces, you can minimize the possibility that those domain names might be dropped from the list that is returned to the client.

Important

To make sure that clients can access link targets in other trusted domains or trusted forests, you must use DNS names for all link targets and configure DFS to use fully qualified domain names in referrals. For more information, see How to Configure DFS to Use Fully Qualified Domain Names in Referrals.

How many root servers can host a domain-based DFS namespace?

Use 16 or fewer root targets unless you enable root scalability mode by using the /RootScalability parameter in Dfsutil.exe. When root scalability mode is enabled, DFS root servers get updates from the closest domain controller instead of from the server acting as the primary domain controller (PDC) emulator master. As a result, root scalability mode reduces network traffic to the PDC emulator master at the expense of faster updates to all root servers. With this mode enabled, you can have as many root targets as you need, as long as the size of the DFS Active Directory object (for each root) is less than 5 MB.

Note that the PDC emulator master is not removed entirely from DFS operations. The PDC emulator master is still used as follows:

When you make changes to the namespace, the changes are made on the PDC emulator master also, but the root servers no longer poll the PDC emulator master hourly for those changes. Instead, they poll the closest domain controller. If the root server is a domain controller, the root server uses itself as the source. If the root server is not a domain controller and is in the same site as the PDC emulator master, the root server treats the PDC emulator master as it would any other domain controller.
When the DFS service starts on a root server, the DFS Active Directory object is accessed on the PDC emulator master. On the next polling interval, DFS accesses the closest domain controller, which might or might not be the PDC emulator master.

Do not use root scalability mode if any of the following conditions exist in your organization:

Your namespace changes frequently, and users must have a consistent view of the namespace.
Domain controller replication is slow. Slow replication increases the amount of time it takes for the PDC emulator master to replicate DFS changes to other domain controllers, which in turn replicate changes to the root servers. Until this replication is complete, the namespace remains inconsistent on all root servers.

Note

The number of root targets running Windows 2000 should be limited to 16 for any one namespace. After you enable root scalability mode in a namespace with root servers running Windows 2000 and Windows Server 2003, root servers running Windows 2000 Server still obtain updates from the PDC emulator master.

What are the DFS size limits and recommendations for Windows Server 2003?

The following table describes the DFS size limits and recommendations for Windows Server 2003.

DFS Size Limits and Recommendations: Microsoft Supported DFS, Offline Files, and FRS Deployments

Description	Limit or Recommendation*	Explanation
Number of characters in path limit	Fewer than 260 characters	Win32 application programming interfaces (APIs) have a maximum path limit of 260 characters. Applications fail when trying to access a namespace that goes beyond that limit. If the path length of a DFS namespace exceeds the Win32 API limit of 260 characters, users must map part of the namespace to a drive letter and access the longer namespace through the mapped drive letter.
Number of DFS roots per server running Windows Server 2003 Standard Edition	One, unless a hotfix is installed	Windows Server 2003 Standard Edition, is limited to one root per server. To create multiple domain-based namespaces on a server running Windows Server 2003 Standard Edition, install the hotfix described in article 903651 in the Microsoft Knowledge Base on the Microsoft Web site.
Number of DFS roots per server running Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition	Varies	There is no limit to the number of DFS roots you can create on a server running Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition. However, as you increase the number of roots per server, the DFS service takes longer to start and uses more memory.
Number of root targets per domain-based DFS root	No fixed limit	If you do not enable root scalability mode, we recommend using 16 or fewer root targets to limit traffic to the server acting as the primary domain controller (PDC) emulator master.
Number of links per DFS namespace	5,000 for domain-based DFS 50,000 links for stand-alone DFS	When the number of links exceeds the recommended limit, you might experience performance degradation when making changes to the DFS configuration. For stand-alone DFS, namespace initialization after server startup might also be delayed.
Size of each DFS Active Directory object (applies to domain-based DFS namespaces only)	5 megabytes (MB)	The size of the DFS Active Directory object is determined by the number and path length of roots, links, comments, and targets in the namespace. We recommend using no more than 5,000 links in a domain-based namespace to prevent the DFS Active Directory object from exceeding 5 MB. Limiting the size of the Active Directory object is important because large domain-based DFS configurations can cause significantly increased network traffic originating from updates made to those roots, links, and targets.
Maximum amount of data that the File Replication Service (FRS) can replicate in a domain-based DFS namespace		It is important that you review the FRS design guidelines before enabling replication. See the chapter "Designing and Deploying File Servers," in the Microsoft Windows Server 2003 Deployment Kit. Doing so will help you optimally deploy and configure FRS for your environment.

* The figures in this table are based on information gathered in a test environment. The numbers in an operational DFS configuration might exceed the numbers described here and still provide acceptable performance.

What are the rules for using interlinks?

Windows Server 2003 supports creating links that point to other DFS namespaces. This kind of link is often referred to as an interlink. Instead of specifying a shared folder as a link target, you can specify a DFS root or link within another namespace, allowing you to create a hierarchy of namespaces, also called a cascaded DFS. Linking to other namespaces is often done in the following scenarios:

To increase DFS scalability. Organizations can combine the availability benefits of domain-based DFS namespaces with the scalability of stand-alone DFS namespaces. For example, if an organization needs to create 10,000 links but does not want to divide these between two domain-based DFS namespaces, the organization can take the following steps:
- Create a stand-alone DFS namespace with 10,000 links.
- Create a domain-based DFS root.
- Under the domain-based DFS root, create a link that points to the stand-alone DFS namespace.
To more easily delegate administration. If multiple groups within an organization want to manage their own namespaces, they can do so and still present a single cascaded DFS namespace to their users.

When linking to other namespaces, you must follow these guidelines to make certain that clients can be redirected properly if a target is unavailable:

If you plan to specify a domain-based DFS namespace as a link target (either the root or a link within that namespace), you cannot specify alternate link targets. (Windows Server 2003 enforces this restriction.)
If you plan to specify a stand-alone DFS namespace as a link target (either the root or a link within that namespace), you can specify alternate link targets to other stand-alone DFS paths. Do not specify domain-based DFS roots or shared folders as alternate targets.