Windows Server 2008 Create Symbolic Link, updated Security Policy still gives privilege error

Run cmd as administrator and use UNC path.

The following command worked for me as administrator:

mklink /D C:\temp11111 \\server\share\foldername\

And also check whether your command contains appropriate quotes (").

Try creating the link to \\servername\sharename\Public\Quick Books Data\Finance Drive instead of the mapped drive Q:. On my Windows 7 x64, it turns out, both methods work, however.

Also make sure that you have established a session with the remote server (verify with net use) unless it's an old style Windows share which doesn't require credentials.

Furthermore ensure that the ACLs are set correctly on the symlink itself with icacls /L. Running it without /L will not yield the expected results. This requires admin rights just like creation of the symlink will.

Edit 1:

Contrary what I wrote in an earlier revision of this answer it turns out the object and I/O manager are able to understand mapped network drives (look for \Device\LanManRedirector symlinks in WinObj under one of the object directories beneath \Sessions\0\DosDevices). Just tested it.

I also looked it up in Windows Internals, 5th edition, by Russinovich et al. (pages 924 and following), because you got me curious. You might want to check with fsutil behavior query SymLinkEvaluation how symlinks are configured on your system. Default would be (also on Vista SP2):

>fsutil behavior query SymLinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.

Just tested that it works to symlink the UNC path or the mapped drive letter as long as the ACL is set correctly on the share as well as on the symlink. Setting the ACL on the symlink too restrictive will cause failure, however. I tested it both for an old-style share and one that requires credentials (in my case on a domain, while I am not on that domain).

To list the ACL use:

icacls <symlink-name> /L

However, I also tested on Vista SP2 x64 just now and I am running into the problem you're running into if I use the drive letter as destination path, although the symlink evaluation policy is set the same as for Windows 7 SP1 x64 on which I tested.

Edit 2:

In WinDbg I was tracking what's going on. I first decided to check the mup driver which I know owns the LanManRedirector among other device objects. My kernel debuggee was a Vista SP2 that exposed the same behavior you see.

First of all I created a network drive mapping L: to \\server\share and then two symlinks: C:\Users\user\drv-name pointing to L:\\ and C:\Users\user\unc-name pointing to \\server\share.

Knowing that symlinks are reparse points, I decided to list all functions of the NTFS driver (dt ntfs!* -v) and pick the most promising to set breakpoints on:

kd> bp Ntfs!NtfsGetReparsePoint
kd> bp Ntfs!NtfsReparsePointName
kd> bp Ntfs!NtfsInitializeReparseFile
kd> bp Ntfs!_imp_FsRtlValidateReparsePointBuffer
kd> bp Ntfs!NtfsReparsePointString
kd> bp Ntfs!NtfsCreateReparsePointInternal
kd> bp Ntfs!NtfsGetReparsePointValue

of course neglecting that the file system drivers are a very delicate thing. Which Windos reminded me of with an insistent bug-check 0x24.

Unfortunately after the system came up again, both symlinks worked even on that Vista SP2 virtual machine. This means I have no way of reproducing the issue in any consistent manner. It means I cannot dig any deeper for the time being.