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

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:

Share settings

Successfully shared

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:

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

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:

  1. Server1 contains a share at \\Server1\share. A DFS share gets created that looks like \\DFS\share which takes information from \\Server1\share.
  2. 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.
  3. Change your GPOs (or whatever is mapping the shares) to \\DFS\share rather than \\Server1\share.
  4. 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.