Client for Open Enterprise Server 2 SP4 (IR6)
Open Enterprise Server 2015 SP1
When both CIFS and NCP protocols are enabled on an OES 2015 SP1 or later server, the following error can be seen when attempting to connect to \\<ipaddress>\<volume> using Windows Explorer or from the Windows "Search" or "Run" box:
\\<ipaddress>\<volume> refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.
A workaround is available in Client for Open Enterprise Server 2 SP4 (IR7).
In order to correct the problem, in addition to installing Client for OES 2 SP4 (IR7), you must also "opt-in" to the workaround behavior by creating a DWORD value named "UNCPathFilterBehavior" set to 0x00000001, under the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NCFSD] registry key.
If the "UNCPathFilterBehavior" set to 0x00000000, or if this value does not exist in the registry at all, then the workaround behavior will NOT be engaged.
When both CIFS and NCP are enabled on the OES server, both the Microsoft Client for Microsoft Networks and the Client for Open Enterprise Server can access resources hosted on the server. In addition to this, Windows also utilizes a Microsoft DFS Client to determine whether the UNC path represents a Microsoft DFS Tree root, before deciding whether the Microsoft Client for Microsoft Networks or the Client for Open Enterprise Server should be used to access the requested NCP path.
Starting in Open Enterprise Server 2015 SP1, the CIFS service began declaring all CIFS-shared volumes to be âDFS Rootâ paths too, if "Distributed File Services (DFS) Support" is selected in the CIFS configuration. This was done intentionally as part of the strategy to help support traversing NSS-based DFS junctions when accessing the NSS volume through the CIFS protocol.
Although this strategy creates positive effects for the CIFS-only client scenario and NSS DFS support, this creates a somewhat âunnaturalâ situation for the Microsoft Windows MUP and Microsoft DFS Client to have to contend with, if and when there is an NCP client available (Client for Open Enterprise Server) in addition to the Microsoft Client for Microsoft Networks.
In an actual pure-Microsoft environment, the DFS Root path does not have the same volume/share name as an actual non-DFS share on that same server. (e.g. The Microsoft DFS path might be //DFSRoot/UsefulAlias, but upon resolving the DFS target of that path, the Microsoft DFS Client will determine that âUsefulAliasâ actually redirects to //ServerName/ActualShare.)
But in this Open Enterprise Server 2015 SP1 CIFS configuration, both the DFS Root name and the actual share name are intentionally the same. (e.g. The Microsoft DFS path //ServerName/NSSVolumeName, upon being resolved to itâs DFS target path by the Microsoft DFS Client, will determine that the DFS target path is also //ServerName/NSSVolumeName.)
Which is a situation Windows MUP, Microsoft DFS Client and the Microsoft Client for Microsoft Networks is able to withstand, if the Microsoft Client for Microsoft Networks is the only redirector able to communicate with the server in question. But when the Client for Open Enterprise Server is also present, and therefore Windows MUP has another redirector able to access the same server and UNC paths, this leads to failure because Windows ends up assuming that Microsoft DFS calls can be made over the NCP protocol, which is not true.
What the workaround behavior enables is that for any UNC path where an NCP connection can be successfully established, the Client for Open Enterprise Server will report back to Windows MUP in such a way that declares all further UNC path resolution attempts must occur over NCP. Meaning the Microsoft Client for Microsoft Networks should not be given further opportunities to resolve UNC paths to this particular server.
The effect this creates is that the Microsoft DFS Clientâs attempt to utilize //ServerName/IPC$ or //ServerName/PIPE will fail, and the Microsoft DFS Root behavior that is being presented by the Open Enterprise Server 2015 SP1 and later servers will be âignoredâ by this client workstation, because all network file system access to that server will be occurring over NCP instead of CIFS.