Compartir a través de

7 Appendix B: Product Behavior

  • Artículo

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

 

  • Windows NT 4.0 operating system

  • Windows NT Server 4.0 operating system

  • Windows 2000 Server operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Server 2003 R2 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system 

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system 

  • Windows 11 operating system

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3: Windows NT Server 4.0 supports only stand-alone DFS namespaces.

<2> Section 1.5: Windows relies on manual coordination between human operators to ensure that only one DFS metadata modification is in progress at any time.

<3> Section 1.7: The Windows RPC Protocol returns RPC_S_PROCNUM_OUT_OF_RANGE to notify the client that an RPC method is out of range, as specified in [MS-RPCE].

<4> Section 2.2.2.12: Only Windows Server 2008 operating system and later support ABDE mode.

<5> Section 2.2.3.5: Only Windows Server 2008 operating system and later support ABDE mode.

<6> Section 2.2.3.7: Windows-based servers return a null GUID for stand-alone DFS namespaces.

<7> Section 2.2.3.10: This level is supported only in Windows Server 2008 operating system and later.

To identify the DFS metadata format in use, two mandatory attributes are defined in the schema to hold the major version (ldapDisplayName = msDFS-SchemaMajorVersion) and minor version (ldapDisplayName = msDFS-SchemaMinorVersion) numbers. The rangeUpper attribute in the attribute schema for these version number attributes determines the format of the DFS metadata supported in the forest. The value of these attributes determines the DFS metadata format in use for an existing DFS namespace. The implementation of a domainv2-based DFS namespace has rangeUpper=2, rangeLower=2 for the NamespaceMajorVersion; and rangeUpper=0, rangeLower=0 for the NamespaceMinorVersion.

A change to an existing, or the addition of a new, mandatory attribute increments the major version and sets the minor version to 0. A change to an existing, or the addition of a new, optional attribute increments the minor version without changing the major version.

The NamespaceMajorVersion and NamespaceMinorVersion determine the format of the DFS metadata supported in the forest. The following table applies only to Windows Server 2008 operating system and later.

NamespaceMajorVersion

NamespaceMinorVersion

Domainv1-based DFS

1

1

Domainv2-based DFS

2

0

Stand-alone DFS

1

2

<8> Section 2.2.3.10: This level is supported only in Windows Server 2008 operating system and later.

To identify the DFS metadata format in use, two mandatory attributes are defined in the schema to hold the major version (ldapDisplayName = msDFS-SchemaMajorVersion) and minor version (ldapDisplayName = msDFS-SchemaMinorVersion) numbers. The rangeUpper attribute in the attribute schema for these version number attributes determines the format of the DFS metadata supported in the forest. The value of these attributes determines the DFS metadata format in use for an existing DFS namespace. The implementation of a domainv2-based DFS namespace has rangeUpper=2, rangeLower=2 for the NamespaceMajorVersion and rangeUpper=0, rangeLower=0 for the NamespaceMinorVersion.

A change to an existing, or the addition of a new, mandatory attribute increments the major version and sets the minor version to 0. A change to an existing, or the addition of a new, optional attribute increments the minor version without changing the major version.

The NamespaceMajorVersion and NamespaceMinorVersion determine the format of the DFS metadata supported in the forest. The following table applies only to Windows Server 2008 operating system and later.

NamespaceMajorVersion

NamespaceMinorVersion

Domainv1-based DFS

1

1

Domainv2-based DFS

2

0

Stand-alone DFS

1

2

<9> Section 2.2.3.10: Only Windows Server 2008 operating system and later support ABDE mode.

<10> Section 2.2.4.3: Only Windows Server 2008 operating system and later support ABDE mode.

<11> Section 2.3.3.1.1: Windows 2000 Server performs a case-sensitive comparison of the name. Windows Server 2003 operating system and later perform a case-insensitive comparison of the name.

<12> Section 2.3.3.1.1.2: Windows Server 2003 operating system and later use the same name for the ShortPrefix field and the Prefix field. Windows 2000 Server stores an 8.3 name in the ShortPrefix field.

<13> Section 2.3.3.1.1.2: Only Windows Server 2003 operating system and later support DFS referral site costing.

<14> Section 2.3.3.1.1.2: Only Windows Server 2003 operating system and later support DFS root scalability mode.

<15> Section 2.3.3.1.1.2: Only Windows Server 2003 operating system with Service Pack 1 (SP1), Windows Server 2008 operating system and later support DFS client target failback.

<16> Section 2.3.3.1.1.3.1: Windows Server 2003 operating system and later always set this field to 0x00000002. Windows 2000 Server sets this field to 0x00000001 for DFS root targets and to 0x00000002 for DFS link targets.

<17> Section 2.3.3.1.1.4: Only Windows 2000 Server uses the SiteInformationBLOB. Windows Server 2003 operating system and later preserve this BLOB if it already exists. When creating a new DFS namespace, Windows Server 2003 operating system and later create this BLOB with a SiteEntryCount of 0 and do not create any SiteEntryBLOBs.

<18> Section 2.3.3.1.1.4: Windows 2000 Server determines the site of a DFS root target or a DFS link target when it is added to a domain-based DFS namespace, and stores the target in this BLOB. The NetrDfsManagerReportSiteInfo method, as specified in [MS-SRVS], is issued to the DFS root target server or the DFS link target server that were added to determine the site information.

<19> Section 2.3.4.2: Windows does not preserve unrecognized values.

<20> Section 2.3.4.2: Only Windows Server 2008 operating system and later support Domainv2.

<21> Section 2.3.4.2: Only Windows Server 2008 operating system and later support Domainv2.

<22> Section 2.3.4.2: Only Windows Server 2008 operating system and later support Domainv2.

<23> Section 2.3.4.3: Windows does not preserve unrecognized values.

<24> Section 2.3.4.3: Only Windows Server 2008 operating system and later support Domainv2.

<25> Section 2.3.4.3: Only Windows Server 2008 operating system and later support Domainv2.

<26> Section 3.1.1: Windows 2000 Server operating system and later cache the DFS metadata as an optimization.

<27> Section 3.1.3: Windows 2000 Server operating system and later determine the PDC for the domain and initialize the PDCRoleHolder.

<28> Section 3.1.3: Windows 2000 Server operating system and later cache the DFS metadata as an optimization.

<29> Section 3.1.4: Windows uses only the error code values, as specified in [MS-ERREF].

<30> Section 3.1.4: This method is not supported in Windows NT Server 4.0 and Windows 2000 Server.

<31> Section 3.1.4: This method is supported only in Windows Server 2008 operating system and later.

<32> Section 3.1.4: This method is supported only in Windows Server 2008 operating system and later.

<33> Section 3.1.4: This method is supported only in Windows Server 2008 operating system and later.

<34> Section 3.1.4: For historical reasons, Windows 2000 Server uses method opnums 7, 8, and 9 for local RPC calls to itself. These methods are never called over the network by Windows clients or servers (to another server).

Opnums reserved for local use apply to Windows as follows: opnums 7-9 are only used locally, never remotely, by Windows 2000 Server and not by any other Windows version.

<35> Section 3.1.4.1.1: This method is not implemented in Windows NT Server 4.0.

<36> Section 3.1.4.1.1: Windows Server 2003 operating system and later return ERROR_NOT_SUPPORTED (0x00000032).

<37> Section 3.1.4.1.2: The following table gives the return value of NetrDfsManagerGetVersion for different versions of Windows.

Windows Version

Return Value

Windows NT Server 4.0

0x00000001

Windows 2000 Server

0x00000002

Windows Server 2003

0x00000004

Windows Server 2008

0x00000006

Windows Server 2008 R2

0x00000006

Windows Server 2012

0x00000006

Windows Server 2012 R2

0x00000006

Windows Server 2016

0x00000006

Windows Server operating system

0x00000006

Windows Server 2019

0x00000006

Windows Server 2022

0x00000006

<38> Section 3.1.4.1.2: The RPC interface version has remained constant since Windows NT Server 4.0. Windows 2000 Server adds new methods to the same RPC interface. Also, Windows 2000 Server supports hosting of at most one DFS namespace. Hence, applications could potentially handle version differences by using the returned version information.

<39> Section 3.1.4.1.2: A Windows NT Server 4.0 can host at most one DFS namespace. Windows Server 2003, except for Windows Server 2003 Standard Edition operating system, supports hosting of more than one DFS namespace per server. In default configurations, Windows Server 2003 Standard Edition supports hosting of at most one DFS namespace per server.

<40> Section 3.1.4.1.2: Windows clients use the returned value to determine when to call NetrDfsEnum versus NetrDfsEnumEx. For more information, see section 3.2.4.1.4.

<41> Section 3.1.4.1.2: Windows Server 2003 with SP1, Windows Server 2003 operating system with Service Pack 2 (SP2), Windows Server 2003 R2 operating system and later support NetrDfsMove (Opnum 6).

<42> Section 3.1.4.1.3: Windows 2000 Server does not support a domain-based DFS namespace in the NetrDfsAdd method.

<43> Section 3.1.4.1.3: Windows Server 2003 operating system and later do not verify whether link targets exist. Windows 2000 operating system and Windows NT 4.0 do verify whether link targets exist unless DFS_RESTORE_VOLUME is specified.

<44> Section 3.1.4.1.3: Windows 2000 and Windows NT 4.0 do use this test.

<45> Section 3.1.4.1.3: Windows 2000 Server requires that the DFS_ADD_VOLUME flags parameter be specified when a new link is being created; Windows Server 2003 operating system and later do not require this.

Windows-based servers check whether a folder or a file that has the same name as the link appears in the object store under the root and take the following actions:

  • If no folder or file exists, create the link folder.

  • If an empty folder with the same name as the link exists, do not create a new link folder.

  • If a non-empty folder or a file with the same name as the link exists, rename the non-empty folder or the file to DFS.GUIDLinkName, and create a new link folder. An example of a renamed non-empty folder or file is DFS.cf13c05f-5c10-4879-9acb-04ced8f46c7aTemplates, where cf13c05f-5c10-4879-9acb-04ced8f46c7a is the GUID and Templates is the LinkName.

  • Set the reparse point to the leaf folder of the link path. For example, if the link path is HR\Documents, set the reparse point to the Documents folder.

<46> Section 3.1.4.1.3: The msDFS-Commentv2 field in the Windows Server 2008 operating system and later metadata is updated with the value that is passed on as input.

<47> Section 3.1.4.1.3: NetrDfsAdd in Windows 2000 Server supports only a stand-alone DFS namespace. Windows 2000 Server returns ERROR_NOT_SUPPORTED (0x00000032) if NetrDfsAdd is called on a domain-based DFS namespace.

<48> Section 3.1.4.1.3: In Windows Server 2003 operating system and later, NetrDfsAdd supports both stand-alone and domain-based DFS namespaces.

<49> Section 3.1.4.1.4: Windows 2000 Server does not support a domain-based DFS namespace in the NetrDfsRemove method.

<50> Section 3.1.4.1.4: This method does not support domain-based DFS namespaces in Windows 2000 Server; NetrDfsRemove2 is used instead. Windows 2000 Server will return ERROR_NOT_SUPPORTED (0x00000032) if NetrDfsRemove is called on a domain-based DFS namespace.

<51> Section 3.1.4.1.4: In Windows Server 2003, the NetrDfsRemove method is functionally equivalent to NetrDfsRemove2.

<52> Section 3.1.4.1.5: Windows 2000, Windows Server 2008 operating system and later allow the target state of a root target or a link target to be set to either DFS_STORAGE_STATE_ONLINE or DFS_STORAGE_STATE_OFFLINE. Windows Server 2003 does not allow the target state of a root target to be set to DFS_STORAGE_STATE_OFFLINE.

Windows 2000 Server does not support DFS_VOLUME_STATE_RESYNCHRONIZE for the State field of DFS_INFO_101 for a Level parameter value of 101.

<53> Section 3.1.4.1.5: Windows Server 2008 operating system and later allow setting the target state of a root target or a link target to either DFS_STORAGE_STATE_ONLINE or DFS_STORAGE_STATE_OFFLINE. Windows Server 2003 does not allow setting the target state of a root target to DFS_STORAGE_STATE_OFFLINE.

<54> Section 3.1.4.1.5: A Level value of 102 is not supported on Windows NT Server 4.0.

Level parameter values 103-106 are not supported on Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003 RTM.

Level parameter values 107 and 150 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003.

<55> Section 3.1.4.1.5: On Windows NT Server 4.0 and Windows 2000 Server, the server returns error code ERROR_INVALID_LEVEL.

<56> Section 3.1.4.1.5: Windows 2000 Server does not support a domain-based DFS namespace in the NetrDfsSetInfo method.

<57> Section 3.1.4.1.5: The NetrDfsSetInfo method supports only the stand-alone DFS namespace on Windows 2000 Server. NetrDfsSetInfo supports both stand-alone and domain-based DFS namespaces on Windows Server 2003 operating system and later. Level parameter values 103, 104, 105, and 106 are valid only on Windows Server 2003 with SP1, Windows Server 2003 SP2, Windows Server 2003 R2 operating system and later. Level parameter values 107 and 150 are supported only on Windows Server 2008 operating system and later.

<58> Section 3.1.4.1.6: This level is supported only on Windows Server 2008 operating system and later.

<59> Section 3.1.4.1.6: Level 4 is not supported in Windows NT Server 4.0.

Levels 5, 6, and 7 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003 RTM. Level 7 is supported for domain-based DFS only. It is used to determine whether the DFS metadata of the namespace has changed.

Level 50 and 150 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003.

<60> Section 3.1.4.1.6: On Windows NT Server 4.0 and Windows 2000 Server, the server returns error code ERROR_INVALID_LEVEL.

<61> Section 3.1.4.1.6: For a stand-alone namespace in Windows, metadata size is the sum of the following:

  • Size of the name of all the keys in the namespace (all keys under the DFS root key in registry)

  • Size of the values under each key

  • Size of the data of each value

<62> Section 3.1.4.1.7: Level 4 is not supported in Windows NT Server 4.0.

Levels 5 and 6 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003 RTM.

Levels 8 and 9 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003.

Level 200 is not supported in Windows NT Server 4.0 and is only valid on a domain controller (DC).

Level 300 is not supported in Windows NT Server 4.0, or Windows 2000 Server.

<63> Section 3.1.4.1.7: On Windows NT Server 4.0 and Windows 2000 Server, the server returns error code ERROR_INVALID_LEVEL.

<64> Section 3.1.4.1.7: On return, the DfsEnum's DfsInfoContainer member contains an array of information structures specific to the Level requested by the caller. In Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 operating system, the number of entries to return in the enumeration is calculated by dividing PrefMaxLen by the size of the Level-specific information structure, using integer division. If the result is zero, one entry is returned.

This calculation is performed on the server by using the native size of the specified information structure on the server's architecture. As all of the Level-specific information structures contain pointers, such as the DFS_INFO_1 EntryPath member, this condition has an important effect. Because the size of a pointer on a 32-bit architecture differs as compared to a 64-bit architecture, the returned number of entries can be higher or lower than that implied by the native architecture of the client, depending on the native architecture of the server.

<65> Section 3.1.4.1.7: Windows-based servers use the ResumeHandle parameter as an index into the collection of enumerable items. Due to intervening or concurrent updates, a resumed enumeration can return non-unique or incomplete results.

<66> Section 3.1.4.1.7: This method is supported only by Windows NT Server 4.0, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

<67> Section 3.1.4.1.7: The NetrDfsEnum method is used only with Windows 2000 Server because there is no parameter to specify the name of a DFS namespace. In Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2, the DFS server can successfully process this method if it is hosting only one DFS namespace root target.

<68> Section 3.1.4.1.8: Windows Server 2003 with SP1, Windows Server 2008 operating system and later do not allow the following:

  • The Unicode code points 0x0000 through 0x001F, 0x0022 ("), 0x002A (*), 0x002F (/), 0x003A (:), 0x003C, (<), 0x003E (>), 0x003F (?), or 0x007C (|).

  • The relative path elements "." or "..".

<69> Section 3.1.4.1.8: Windows-based servers perform DFS link move operations atomically for domainv1-based DFS namespaces. Move operations in stand-alone DFS namespaces and domainv2-based DFS namespaces are not atomic.

<70> Section 3.1.4.1.8: If there is a conflict between an existing file and a pathname component in the destination path or DFS link of a move operation, Windows-based servers rename the existing file by appending a ".{GUID}" to the file name, where "{GUID}" is a newly generated GUID.

<71> Section 3.1.4.1.8: Windows-based servers remove intermediate directories in the pathname of a source DFS link if they are empty.

<72> Section 3.1.4.1.8: This method is supported only on Windows Server 2003 with SP1, Windows Server 2003 SP2, Windows Server 2003 R2 operating system and later.

<73> Section 3.1.4.1.9: This method is supported only on Windows Server 2008 operating system and later.

<74> Section 3.1.4.1.10: This method is supported only on Windows Server 2008 operating system and later.

<75> Section 3.1.4.1.10: Windows does not fail calls that specify reserved bits.

<76> Section 3.1.4.1.10: Windows does not support DFS_FORCE_REMOVE on member servers.

<77> Section 3.1.4.1.10: Windows removes local information related to the root.

<78> Section 3.1.4.1.11: This method is supported only on Windows Server 2008 operating system and later.

<79> Section 3.1.4.2.1: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 ignore the DcName parameter.

<80> Section 3.1.4.2.1: The ppRootList parameter is not referenced in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. On success in Windows 2000, the RPC call returns a list of the remaining root targets of the DFS namespace.

To support down-level compatibility with Windows 2000, Windows clients issue a NetrDfsSetDcAddress to each root target listed in ppRootList by specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<81> Section 3.1.4.2.1: This method is supported only by Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

<82> Section 3.1.4.2.1: This method supports both stand-alone DFS namespaces and domain-based DFS namespaces in Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

The DFS_RESTORE_VOLUME bit of the Flags parameter is used only with Windows 2000 Server.

Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 ignore the DcName and ppRootList parameters.

To support down-level compatibility with Windows 2000 Server, Windows clients issue NetrDfsSetDcAddress to each root target listed in ppRootList. NetrDfsSetDcAddress specifies the name of the PDC that is used for the DcName parameter, and the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter. NetrDfsSetDcAddress also specifies a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<83> Section 3.1.4.2.1: Windows NT Server 4.0 does not support this method.

<84> Section 3.1.4.2.1: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 do not verify whether link targets exist. Windows 2000 Server and Windows NT 4.0 do verify whether link targets exist, unless DFS_RESTORE_VOLUME is specified.

<85> Section 3.1.4.2.1: Windows 2000 Server and Windows NT 4.0 do use this test.

<86> Section 3.1.4.2.1: Windows 2000 Server requires that the DFS_ADD_VOLUME Flags parameter be specified when creating a new link; Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 do not.

Windows servers check whether a folder or a file that has the same name as the link appears in the object store under the root and take the following actions:

  • If no folder or file exists, create the link folder.

  • If an empty folder with the same name as the link exists, do not create a new link folder.

  • If a non-empty folder or a file with the same name as the link exists, rename the non-empty folder or the file to DFS.GUIDLinkName, and create a new link folder. An example of a renamed non-empty folder or file is DFS.cf13c05f-5c10-4879-9acb-04ced8f46c7aTemplates, where cf13c05f-5c10-4879-9acb-04ced8f46c7a is the GUID and Templates is the LinkName.

  • Set the reparse point to the leaf folder of the link path. For example, if the link path is HR\Documents, set the reparse point to the Documents folder.

<87> Section 3.1.4.2.2: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 ignore the DcName parameter.

<88> Section 3.1.4.2.2: The ppRootList parameter is not referenced in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. In Windows 2000, a list of remaining root targets of the DFS namespace is returned when the RPC call succeeds.

To support down-level compatibility with Windows 2000, Windows clients issue a NetrDfsSetDcAddress to each root target listed in ppRootList by specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<89> Section 3.1.4.2.2: This method is supported only by Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

<90> Section 3.1.4.2.2: This method supports both stand-alone DFS namespaces and domain-based DFS namespaces in Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

The ppRootList parameter is not used in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

To support down-level compatibility with Windows 2000 Server, Windows clients issue a NetrDfsSetDcAddress to each root target listed in ppRootList by specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<91> Section 3.1.4.2.2: Windows NT Server 4.0 does not support this method.

<92> Section 3.1.4.2.3: While Windows 2000 Server can host at most one root target, Windows Server 2003 operating system and later can host more than one root target on the same server. This precludes meaningful use of the NetrDfsEnum method by Windows Server 2003 and Windows Server 2008 because NetrDfsEnum does not have a parameter to specify the DFS namespace of interest. Hence, the NetrDfsEnumEx method is used on Windows Server 2003 and Windows Server 2008.

<93> Section 3.1.4.2.3: Windows NT Server 4.0 does not support the NetrDfsEnumEx method.

<94> Section 3.1.4.2.3: Level 4 is not supported in Windows NT Server 4.0.

Levels 5 and 6 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003.

Levels 8 and 9 are not supported in Windows NT Server 4.0, Windows 2000 Server, or Windows Server 2003.

Level 200 is not supported in Windows NT Server 4.0, and it is only valid on a domain controller (DC).

Level 300 is not supported in Windows NT Server 4.0 or Windows 2000 Server.

<95> Section 3.1.4.2.3: On Windows NT Server 4.0 and Windows 2000 Server, the server returns error code ERROR_INVALID_LEVEL.

<96> Section 3.1.4.2.3: On return, the DfsEnum's DfsInfoContainer member contains an array of information structures specific to the Level requested by the caller. In Windows 2000 Server operating system and later, the number of entries to return in the enumeration is calculated by dividing PrefMaxLen by the size of the Level-specific information structure, using integer division. If the result is zero, one entry is returned.

This calculation is performed on the server by using the native size of the given information structure on the server's architecture. As all of the Level specific information structures contain pointers, such as the DFS_INFO_1 EntryPath member, this condition has an important effect. Because the size of a pointer on a 32-bit architecture differs as compared to a 64-bit architecture, the returned number of entries can be higher or lower than that implied by the native architecture of the client, depending on the native architecture of the server.

<97> Section 3.1.4.2.3: Windows-based servers use the ResumeHandle parameter as an index into the collection of enumerable items. Due to intervening or concurrent updates, a resumed enumeration can return non-unique or incomplete results.

<98> Section 3.1.4.2.3: To be backward-compatible with the NetrDfsEnum method, in this case the NetrDfsEnumEx method in Windows Server 2003 operating system and later ignores the <ServerName> in DfsEntryPath and returns the required information for the specified Level based on the namespace it hosts.

The NetrDfsEnum method is used only with Windows 2000 Server because there is no parameter to specify the name of a DFS namespace. In Windows Server 2003 operating system and later, the DFS server can successfully process this method if it is hosting only one DFS namespace root target.

<99> Section 3.1.4.2.4: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 ignore the DcName parameter.

<100> Section 3.1.4.2.4: Windows 2000, Windows Server 2008, and Windows Server 2008 R2 allow the target state of a root target or a link target to be set to either DFS_STORAGE_STATE_ONLINE or to DFS_STORAGE_STATE_OFFLINE. Windows Server 2003 does not allow the target state of a root target to be set to DFS_STORAGE_STATE_OFFLINE.

Windows 2000 Server does not support DFS_VOLUME_STATE_RESYNCHRONIZE for the State field of DFS_INFO_101 for a Level parameter value of 101.

<101> Section 3.1.4.2.4: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 allows the target state of a root target or a link target to be set to either DFS_STORAGE_STATE_ONLINE or to DFS_STORAGE_STATE_OFFLINE. Windows Server 2003 does not allow the target state of a root target to be set to DFS_STORAGE_STATE_OFFLINE.

<102> Section 3.1.4.2.4: Level 102 is not supported in Windows NT Server 4.0.

Levels 103-106 are not supported in Windows NT Server 4.0, Windows 2000 Server or Windows Server 2003 RTM.

Levels 107 and 150 are not supported in Windows NT Server 4.0, Windows 2000 Server or Windows Server 2003.

<103> Section 3.1.4.2.4: On Windows NT Server 4.0 and Windows 2000 Server, the server returns error code ERROR_INVALID_LEVEL.

<104> Section 3.1.4.2.4: The ppRootList parameter is not referenced in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. In Windows 2000, a list of remaining root targets of the DFS namespace is returned when the RPC call succeeds.

To support down-level compatibility with Windows 2000, Windows clients issue a NetrDfsSetDcAddress to each root target listed in ppRootList by specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<105> Section 3.1.4.2.4: This method is supported only on Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

<106> Section 3.1.4.2.4: Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 support both stand-alone and domain-based DFS namespaces for NetrDfsSetInfo2 (Opnum 22).

<107> Section 3.1.4.2.4: Windows NT Server 4.0 does not support this method.

<108> Section 3.1.4.3.1: Windows 2000, Windows Server 2008 operating system and later ignore this parameter and use the local NetBIOS host name instead.

<109> Section 3.1.4.3.1: Windows Server 2003 operating system and later ignore the ConfigDN parameter.

<110> Section 3.1.4.3.1: No information is returned through the ppRootList parameter on Windows Server 2003 operating system and later.

To support down-level compatibility with Windows 2000 Server, Windows clients issue a NetrDfsSetDcAddress (Opnum 17) method to each root target listed in ppRootList by specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

Windows NT Server 4.0 does not support this method.

<111> Section 3.1.4.3.1: No information is returned through the ppRootList parameter on Windows Server 2003 operating system and later. To support down-level compatibility with Windows 2000, Windows clients issue a NetrDfsSetDcAddress (Opnum 17) method to each root target listed in ppRootList specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and the NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter. Windows NT 4.0 does not support this method.

<112> Section 3.1.4.3.2: Windows NT Server 4.0 does not support the NetrDfsRemoveFtRoot method.

<113> Section 3.1.4.3.2: Windows does not fail calls that specify reserved bits.

<114> Section 3.1.4.3.2: The ppRootList parameter is not referenced on Windows Server 2003 operating system and later. On Windows 2000, a list of remaining root targets of the DFS namespace is returned when the RPC call succeeds.

To support down-level compatibility with Windows 2000, Windows clients issue a NetrDfsSetDcAddress (Opnum 17) to each root target listed in ppRootList by specifying the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<115> Section 3.1.4.3.2: Windows does not support DFS_FORCE_REMOVE on member servers.

<116> Section 3.1.4.3.2: Windows does remove local information related to the root.

<117> Section 3.1.4.3.2: Windows-based servers do not remove the object of a domain-based DFS namespace if the last DFS root target is being removed. Windows clients remove the object of the DFS namespace on successful return from this method.

<118> Section 3.1.4.4.1: The NetrDfsAddStdRoot (Opnum 12) method can also be used for clustered DFS with Windows Server 2003 operating system and later.

<119> Section 3.1.4.4.1: Windows NT Server 4.0 does not support this method.

<120> Section 3.1.4.4.1: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 return this error code for the described condition.

<121> Section 3.1.4.4.1: Windows 2000 returns this error code for the described condition.

<122> Section 3.1.4.4.2: Windows NT Server 4.0 does not support the NetrDfsRemoveStdRoot method.

<123> Section 3.1.4.4.3: The NetrDfsAddStdRootForced method is used to create a clustered DFS namespace in Windows 2000 Server. This call allows an offline share to host the DFS root.

<124> Section 3.1.4.4.3: Windows Server 2003 operating system and later do not support the NetrDfsAddStdRootForced method. Use the NetrDfsAddStdRoot (Opnum 12) method instead.

<125> Section 3.1.4.4.3: Windows NT Server 4.0 does not support the NetrDfsAddStdRootForced (Opnum 15) method.

<126> Section 3.1.4.5.1: Windows NT Server 4.0 does not support the NetrDfsGetDcAddress method.

<127> Section 3.1.4.5.1: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 ignore the ServerName parameter.

<128> Section 3.1.4.5.1: Windows clients ignore the value returned in the DcName parameter; Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 return a blank name.

<129> Section 3.1.4.5.1: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 always return FALSE in the IsRoot parameter. While Windows Server 2003 Standard Edition supports the ability to host only one DFS namespace, it returns FALSE in the IsRoot parameter even when it is hosting a DFS namespace.

The client-side wrapper of the NetrDfsAddFtRoot (Opnum 10) RPC method in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows Server 2008 R2 uses the NetrDfsGetDcAddress method to determine whether the server to which the RPC is to be issued is already hosting a DFS namespace. If the value returned in the IsRoot parameter is TRUE, the NetrDfsAddFtRoot () method fails at the client. This is meant for Windows 2000 Server, which supports the ability to host at most one DFS namespace. This is why Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 always return FALSE for the IsRoot parameter.

<130> Section 3.1.4.5.1: In Windows 2000 Server, the default time-out value is 2 hours. This value can be overridden by calling NetrDfsSetDcAddress (Opnum 17).

<131> Section 3.1.4.5.1: This method is supported only by Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

<132> Section 3.1.4.5.2: Windows NT Server 4.0 does not support the NetrDfsSetDcAddress method.

<133> Section 3.1.4.5.2: Windows does not fail the call if reserved bits are specified.

<134> Section 3.1.4.5.2: Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 implement it as a method with no effect that returns ERROR_SUCCESS. Windows Server 2012 operating system and later do not implement this method.

<135> Section 3.1.4.5.2: To support down-level compatibility with Windows 2000 Server, Windows clients issue a NetrDfsSetDcAddress (Opnum 17) to each DFS root target returned in the ppRootList parameter from an invocation of NetrDfsAdd2 (Opnum 19), NetrDfsRemove2 (Opnum 20), NetrDfsSetInfo2 (Opnum 22), NetrDfsAddFtRoot (Opnum 10), or NetrDfsRemoveFtRoot (Opnum 11) methods. NetrDfsSetDcAddress (Opnum 17) specifies the name of the PDC used for the DcName parameter, the NET_DFS_SETDC_INIT_PKT and the NET_DFS_SETDC_TIMEOUT flags for the Flags parameter, and a value of 0x00001C20 (7,200 seconds or 2 hours) for the Timeout parameter.

<136> Section 3.2.3: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 R2 operating system and later clients create a separate binding for every method invocation.

<137> Section 3.2.4.1.1: Windows NT 4.0 and Windows 2000 Server never reissue the NetrDfsAdd2 method.

<138> Section 3.2.4.1.2: Windows NT 4.0 and Windows 2000 Server never reissue the NetrDfsRemove2 method.

<139> Section 3.2.4.1.3: Windows NT 4.0 and Windows 2000 Server never reissue the NetrDfsSetInfo2 method.

<140> Section 3.2.4.1.4: For level values other than 200, Windows XP operating system and later and Windows Server 2003 operating system and later clients first call the NetrDfsManagerGetVersion method. If the returned version value is 0x00000004 or greater, the client calls the NetrDfsEnumEx method. If the returned version value is less than 0x00000004, the client calls the NetrDfsEnum method. For level 200, Windows XP operating system and later and Windows Server 2003 operating system and later clients always call the NetrDfsEnumEx method on the PDC.

<141> Section 3.2.4.1.4: The Windows 2000 Server client does not call either NetrDfsEnum or NetrDfsEnumEx for level 200; rather, it determines the list of domain-based DFS namespaces through an LDAP query directly on the DFS configuration container.

<142> Section 3.2.4.1.4: Windows clients rely on human operators to detect inconsistent results in displayed output and to request a new enumeration.

<143> Section 3.2.4.3.1: Only Windows 2000 Server returns other existing DFS root targets of the DFS namespace in the ppRootList parameter. Windows Server 2003 operating system and later do not return any information in the ppRootList parameter.

<144> Section 3.2.4.3.1: Windows clients fail the NetrDfsAddFtRoot operation on the client if an IP address is given as the ServerName parameter. This is because Windows clients attempt to use the ServerName parameter as the security principal when updating the ACL of the object of a domain-based DFS namespace. Because Active Directory does not permit an IP address to be used as a security principal, a Windows client will fail on the ACL update before sending the NetrDfsAddFtRoot request message.

<145> Section 3.2.4.3.2: Windows NT Server 4.0 does not support the NetrDfsRemoveFtRoot method.

<146> Section 3.2.4.3.2: Only Windows 2000 Server returns other existing DFS root targets of the DFS namespace in the ppRootList parameter. Windows Server 2003 operating system and later do not return any information in the ppRootList parameter.

<147> Section 3.3.4: Windows allows DCs to be DFS root targets.

<148> Section 3.3.4.2.1: Level parameter value 200 is not supported in Windows NT 4.0 and only valid on a domain controller (DC).

<149> Section 3.3.4.3.2: Windows Server 2003 operating system and later do not support this method and will fail with ERROR_NOT_SUPPORTED (0x00000032).

On a successful call to the NetrDfsAddFtRoot or NetrDfsRemoveFtRoot methods, Windows clients call the NetrDfsFlushFtTable method on the PDC of the domain of the DFS root target server. For more information, see sections 3.2.4.3.1 and 3.2.4.3.2.

This method is not supported on Windows NT Server 4.0.

<150> Section 5.1: Windows-based servers use the RPC Protocol to retrieve the identity of the caller, as specified in [MS-RPCE] section 3.3.3.4.3. The server uses the underlying Windows security subsystem to determine the permissions for the caller. If the caller does not have the required permissions to execute a specific method, the method call fails with ERROR_ACCESS_DENIED (0x00000005).