Creating a symlink directory on a network share to a path below a mapped drive letter, local path, or UNC path does not work

Question

Am I correct in assuming I can not create a `symlinkd` to a network share, local path, or a UNC path on a network share that will be accessible by clients?
###Mapped drive letters don't work:
1) navigate to a network share:
pushd \\windows2008server\share\
2) make a hardlink:
mklink /d test_sharedir t:\directory\
dir .\test_sharedir
#Directory of Z:\test_sharedir
#File Not Found
UNC paths don't work:
1) navigate to a network share:
pushd \\windows2008server\share\
2) make a symlink:
mklink /d test_dirunc \\windows2008server\share
dir .\test_dirunc
#Directory of Z:\test_dirunc
#File Not Found
I can create a functional `symlinkd` on a local drive to a mapped drive letter or a UNC path.
Are my assumptions above correct?
We are in the middle of a migration and have created two symlinkd to UNC paths for shared DLLs, one below c:\windows\system32\ (directing to a share containing 64-bit DLLs) and one below c:\windows\syswow64 (directing to a share containing 32-bit DLLs).
On the file server, we have had a path to 32-bit DLLs (from Windows 7 clients: s:\dll\).  I am attempting to rename this directory so that it is accessible via "s:\dll32\" and would like to create a symlinkd that links "s:\dll" to
"s:\dll32" [again where S: is a mapped drive on a Windows 2008 server].  How do I do this?
Thanks,
Matt

Answer 1

Hello Mandy,
The link you sent me is for Netapp CIFS server daemon contained within DataOnTap (the Netapp OS) to follow symlinks.  I am inquiring about the Microsoft products Windows Server and Windows 7.
To gain a better understanding of the Microsoft Windows Server and client (Windows) CIFS stacks and interaction of the stacks, I have referred to Figure 6 "Server Message Block Server Model" within the following (albeit older) document: http://download.microsoft.com/download/2/8/0/2800a518-7ac6-4aac-bd85-74d2c52e1ec6/tuning.doc
You will see the following:
I assume that the Windows Server CIFS server service must be "smart enough" to determine that a CIFS client is attempting access to a SYMLINKD and actually fill the request by following the SYMLINKD.  The CIFS server service does not appear
to operate like this.
1) Am I correct in my assumption that the CIFS client (redirector) and the CIFS server (server) do not following symbolic links (whether they be file or directory)?
2) If not, how do I submit a feature request for this so that it can be reviewed and approved or not approved for inclusion/hotfix release?
Thanks for your time,
Matt Brown
[UPDATE]
Note that you can use a `directory junction` instead of using a SYMLINKD, to link to LOCAL resources (source). However, `directory junctions` do not allow access to resources over UNC.