Cannot connect to DFS share using fully qualified domain names (176084)



The information in this article applies to:

  • Microsoft Windows NT Server 4.0
  • Microsoft Windows NT Workstation 4.0

This article was previously published under Q176084

SYMPTOMS

Connecting to a Distributed File System (DFS) share by using a Fully Qualified Domain Name (FQDN), such as DIR \\DFS.Microsoft.Com\Share, produces one of the following results:
  • An empty directory is returned when you browse directories under the root DFS share point.
  • When you map a directory under the root DFS share point, you receive the following error message:
    System error 67 has occurred. The network name cannot be found.
Note Microsoft Windows NT 4.0 clients with the current service pack version will be able to connect to a Microsoft Windows 2000 or a Microsoft Windows 2003-based DFS domain root through DNS by using the following syntax: \\domain.com\dfsroot. (The current service pack version is Service Pack 6a (SP6a.)

This will work only if the Windows NT 4.0 client is a member of the same Windows 2000 or Windows 2003-based domain. It will not work if the Windows NT 4.0 client is in a trusted domain.

CAUSE

The "How Users See and Connect to DFS Trees" section of the "Microsoft Distributed File System for Microsoft Windows NT Server 4.0 Administrator's Guide" states the following:

Windows 95 DFS clients have some additional limitations that do not
apply to Windows NT clients:

The Windows 95 client cannot access non-SMB leaf volumes.
The Windows 95 client cannot use the DNS namespace as part of
accessing Windows NT shares
(for example, DIR \\DFS.Microsoft.Com\Public).

Windows NT 4.0 with SP 3, SP 4, or SP5 does not support access to a DFS share from a Domain Name Server (DNS) namespace.

WORKAROUND

Connect to the DFS share using NetBIOS machine names only. This may require use of a WINS server or a LMHOSTS file to resolve the DFS server's machine name to an IP address.

MORE INFORMATION

All clients that belong to the domain that is hosting the DFS namespace have seamless access to the DFS namespace. This is also true for clients that belong to domains that trust the domain that is hosting the DFS namespace.

Clients that belong to a workgroup or that belong to domains that do not trust the domain that is hosting the DFS namespace can only access the DFS namespace if the name resolution mechanism that is in place can locally resolve the domain name.

Clients that have difficulty accessing the DFS namespace can work around the problem by using a different method to access the namespace. These clients can replace the domain name with the name of the server that they are trying to access. The domain name must be replaced with the name of a root target. For example, if \\DomainY\DFSX is the DFS root, and there are two root targets that are named \\Computer1\Target1 and \\Computer2\Target2, the clients that are in the workgroup or the untrusted domains cannot access the namespace by specifying \\DomainY\RootNameDFSX. However, to work around this issue, they can access the actual server name by using either \\Computer1\Target1 or \\Computer2\Target2.

These clients may experience a loss of fault tolerance that is implemented at the DFS root level. This is because they are using a specific computer to traverse the namespace.

The DS client pack supports the DSGetDCName API to connect to the DC and enables the client for DFS fault tolerance. To download the DC client pack, visit the Active Directory clients page at the following Microsoft Web site:Note The DS Client for Windows NT 4.0 requires Service Pack 6a.

REFERENCES

297177 "Network Path Not Found" Error Message If More Than 15 Domain Controllers Host a Domain Root DFS

For more information, visit the following Microsoft Web sites:

Distributed File System (DFS): Best Practices and Troubleshooting Guide:
http://technet2.microsoft.com/windowsserver/en/library/007e4e66-af67-4bfe-bf70-780412aeed6f1033.mspx


How DFS Works: DFS Client and Server Compatibility:


Modification Type:MajorLast Reviewed:6/20/2006
Keywords:kbprb KB176084