In Windows, is it possible to share a symlink as a network share?

Question

Summary

Is it possible to share a symlink to a network location as a Network Share in Windows? E.G:

D:\folder\Shared\foo on \\server is shared as \\server\foo, where D:\folder\Shared\foo is actually a directory symbolic link to \\other\server\bar.

Or is this an XY Problem?

Background

We have a Windows Server 2008 R2* virtual machine, fs1, with 2 virtual disks. C: is of course the system drive and D: is a data drive. We share multiple folders on D: via SMB using Windows Share and Storage Management. For example:

D:\Shares\Shared\Engineering is shared as \\fs1\Engineering
C:\Shares\Shared\Admin is shared as \\fs1\Admin

These shares are typically mapped as network drives on user workstations. E:\ might be mapped to \\fs1\Engineering, for example.

I want to move these shares off of this virtual disk and onto our new storage location \\abc\def, and I want to do this transparently to the end user (at least for now - eventually the original path will go away but that's out of scope of the question).

*Upgrading to 2016 or 2019 this year.

Where I am Now

Certain subfolders of the shared folders are being migrated by first by copying the data to the target location (\\abc\def) using RoboCopy, then renaming the original path to a backup path, and finally creating a directory symlink to the new target. The process looks roughly like so (some additional flags/options are omitted for brevity):

robocopy D:\Shares\Shared\Admin\Finance \\abc\def\Finance /mir
ren D:\Shares\Shared\Admin\Finance D:\Shares\Shared\Admin\Finance_old
mklink /D D:\Shares\Shared\Admin\Finance \\abc\def\Finance

Then the Finance_old folder gets permissions changed and eventually deleted once we've verified that things are working well.

Note that the root shared folder, D:\Shares\Shared\Admin, is still an actual folder and not a symlink.

This works very well - it can be done with less than 1 second of downtime, and all end user programs continue to work.

Aside: Windows SymLink Permissions

I have already set up a GPO to allow Remote Link to Remote Target symbolic links. source1, source2

The Problem

There are too many subfolders to make symlinks for each one, so instead I'd like to make a single symlink for each shared root folder.

I can successfully create a symlink in the D:\Shares\Shared directory:

mklink /D D:\Shares\Shared\symlink_test \\abc\def\target

I can then successfully add it to Share and Storage Management:

And the share shows up when browsing \\fs1 in Windows Explorer.

But when I try accessing the shared location \\fs1\symlink_test, I get a "Device not ready" error:

Hey it says stuff about permissions!

I have checked all of the permissions, the location should be readable.

I can access \\abc\def\symlink_test directly.
I can access D:\Shares\Shared\symlink_test and it correctly takes me to the target location.

So I don't think it's a permission issue.

Other Info

fs1 is running Windows Server 2008 R2
\\abc\def is actually a Distributed File System namespace
\\abc\def\foo is a folder in the DFS namespace with a target on a Synology NAS \\nas1\foo

By sharing the symlink itself, you're effectively telling the old server to access the remote content and serve it to the clients. As far as I'm aware, the Windows file server isn't capable of doing this, it can only serve out local content. To put that another way, what you're doing now works because the *client* processes the symlink; what you're trying to do won't work because the *server* is processing the symlink. — Harry Johnston, Mar 07 '19 at 21:38
... that said, the obvious thing to try is to make sure that the local system account on `fs1` has access to `\\abc\def` and to all the content it contains. You can use psexec (available from the Microsoft web site) to check, i.e., if something like `psexec -s \\fs1 cmd /c dir \\abc\def`works then the access rights are OK. As I said, I don't think it will work anyway, but you could try. — Harry Johnston, Mar 07 '19 at 21:40
Hmm... I was afraid of that. I did check psexec and the access rights are correct. Looks like I'll have to come up with another solution. I wonder if I can do some DNS hackery... — dthor, Mar 08 '19 at 16:13
resharing network locations is in general Bad Idea™ - you move from client<->server to client<->middleman<->server — warren, Mar 12 '19 at 14:47
@warren isn't that effective what DFS does? The DFS server is the middleman directing the client which server they should access? — dthor, Mar 13 '19 at 19:45
With little data, I suspect you're hitting a double hop situation and failing authentication - as Harry explained. DFS is different because it provides a referral to the client about where to go get the data directly. DFS is a good first step for hiding your underlying topology. Clustering is a more advanced approach for ensuring business continuity. — Matthew Wetmore, Mar 14 '19 at 06:56

score 2 · Answer 1 · answered Mar 07 '19 at 22:35

I would encourage you to take a look at DFS. I've not gone through the setup myself but I've seen admins successfully migrate a share from one Windows CIFS server to another with it.

It looks a bit like this:

Server1 contains a share at \\Server1\share. A DFS share gets created that looks like \\DFS\share which takes information from \\Server1\share.
Server2 gets stood up and added to the DFS replication. Now all the data from \\Server1\share is available at \\server2\share and \\DFS\share.
Change your GPOs (or whatever is mapping the shares) to \\DFS\share rather than \\Server1\share.
Now you can remove \\Server1\share from the DFS and shut it down. Any time you need to migrate the share again, you can add a new server to the DFS replication. Additionally, you can have multiple servers in the DFS continuously for backup (one server dies, the other has the data) or availability (one server at two distant offices) reasons.

Actually that's why most of this is happening: we're moving to DFS so that I never have to worry about this migration again (your point #4). The problem right now is (a) I only have the 1 DFS server, so I can't set up replication, and (b) end users/programs are not ready to change their paths - some use the mapped network drive which I can change via GPO, but others use UNC paths (which is why the symlink helps) — dthor, Mar 08 '19 at 15:53
Can't help with the one server issue other than to suggest a VM or a container if you don't have ready hardware. Once you get a second server up, you could create mess with DNS to get the clients to still access the correct server provided the UNC path isn't an IP. Standardizing all your links to a DNS CNAME is probably your first order of business. Then you can do all kinds of trickery like load balancing and proxies. — duct_tape_coder, Mar 08 '19 at 17:27