1.3 Overview

The DFS: Namespace Management Protocol is one of a collection of protocols that group shares that are located on different servers by combining various storage media into a single logical namespace. The DFS namespace is a virtual view of the share. When a user views the namespace, the directories and files in it appear to reside on a single share. Users can navigate the namespace without needing to know the server names or shares hosting the data. DFS also provides redundancy of namespace service.

Access to a DFS namespace requires the DFS client. The DFS client uses the DFS Referral Protocol, as specified in [MS-DFSC], to ascertain the existence of the DFS namespace and to determine the shares to access on servers that participate in the DFS namespace. The DFS Referral Protocol navigates through the DFS namespace by appropriately issuing referral requests to a domain controller (DC) or to a DFS root target server to resolve the original path to a share on a server that contains the data being accessed. For more information on DFS and the DFS client, see [MSDFS]. For more information on how the DFS Referral Protocol operates within the context of the Server Message Block (SMB) Protocol, as specified in [MS-SMB], which is the transport for DFS referrals, see [MS-DFSC] section 2.

DFS namespace information, such as name, DFS link name, DFS link target, and so on, is stored in the DFS metadata of the namespace. Depending on where the DFS metadata is stored, the DFS namespace is "domain-based" or "stand-alone".

• Domain-Based DFS Namespace: A well-known container in the domain directory, known as the DFS configuration container, holds the DFS metadata for a domain-based DFS namespace. An object exists for each domain-based DFS namespace in the DFS configuration container. DFS metadata of a domain-based DFS namespace is stored as a binary large object (BLOB) in an attribute of the DFS namespace object. A domain-based DFS namespace can have multiple DFS root targets, which offer high availability and load sharing at the DFS root level. The DFS root name of a domain-based DFS namespace has the domain as its first component. A DFS client issues a referral request to a DC in order to identify the DFS root targets of the DFS namespace.

• Stand-Alone DFS Namespace: DFS metadata is stored in an implementation-specific format on the DFS root target server itself. A stand-alone DFS namespace supports only one DFS root target. The DFS root name of a stand-alone DFS namespace has a host name as its first component. A DFS client issues referral requests to the DFS root target server to access the DFS namespace. A stand-alone DFS namespace can be clustered to provide high availability of the DFS namespace.<1> The server hosting a stand-alone DFS namespace can be promoted to a Domain Controller, but the namespace cannot be converted to a domain-based namespace, and it will continue as a stand-alone namespace.

  A server cannot host both domain-based and stand-alone namespace roots with the same name.

The DFS: Namespace Management Protocol is used to configure DFS services. This protocol is used primarily by administrative applications that run on client computers to connect and configure Distributed File System (DFS) servers. It consists of the RPC methods that can be issued from an administrative client computer to the protocol server on a DC or a Distributed File System (DFS) root target server. An administrator can use this protocol to perform various Distributed File System (DFS) namespace administration operations, such as creating or deleting a DFS namespace, adding or removing DFS root targets, adding or removing DFS links, and adding or removing targets to an existing link. The DFS: Namespace Management Protocol includes the following:

• Eleven basic methods for configuring stand-alone DFS namespaces and domain-based DFS namespaces, as specified in section 3.1.4.1.

• Four methods that support extended access to configurations of a DFS namespace, as specified in section 3.1.4.2.

• Three methods for configuring root targets in a domainv1-based DFS namespace, as specified in section 3.1.4.3.

• Three methods for configuring a stand-alone DFS namespace, as specified in section 3.1.4.4.

• Two methods relating to the association between a DFS server and the DC used by a domain-based DFS namespace, as specified in section 3.1.4.5.

Much of the configuration information that is communicated through this protocol is marshaled through two unions: DFS_INFO_STRUCT and DFS_INFO_ENUM_STRUCT. The usage model of these unions is for the client to specify a Level parameter to determine which union case to use. Each level corresponds to a specific DFS_INFO_n structure, where n is the level number. Arrays of DFS_INFO_n structures are marshaled using DFS_INFO_n_CONTAINER structures. Levels 1, 2, 3, 4, 5, 6, 8, and 9 are common, and are shared across both the DFS_INFO_STRUCT and DFS_INFO_ENUM_STRUCT unions. Levels 7, 50, 100, 101, 102, 103, 104, 105, 106, 107, and 150 are unique to the DFS_INFO_STRUCT union, and Levels 200 and 300 are unique to the DFS_INFO_ENUM_STRUCT union.

While a number of methods use the common configuration information structures, not all methods support all levels. The following table lists the levels used in the DFS_INFO_STRUCT and DFS_INFO_ENUM_STRUCT unions, their singleton and array structures, and the methods with which the level can be used.