So we had this problem, several of our Windows 2008 R2 fileservers were running full and due to technical issues (old hardware) replacing the disks became VERY expensive.
So alternatives, I started to thing – hey, lets create an “ISCSI drive” on a remote datacenter server, mount the ISCSI drive into the directory structure as a mountpoint named “Archive” or something. Now users could put “old” archival data here, thus removing it from the server but still being available – clever 😀 A few issues crept up however, when creating an ISCSI target on a Windows 2008 R2 server this is “terminated” as a VHD file – this proved annoying (eg for backup etc), besides a friend of mine pointed out that they had tried something similar once – sadly if connectivity was sketchy this could cause the fileserver to hang as it was unable to connect to the iscsi target.
My friend however pointed out that he had had success with using “Links”, right – I have heard of these Junction points and symbolic links, but never really found any real good use for it. But it turn out you can create a symbolic link from the directory structure on one server, pointing to a share on a different server.
So eg. O:\ could have a lot of directories, however we also make a Symbolic Link there named “Archive” – if you now perform a dir you will find all the subdirectories, however you will also find O:\Archive which looks just like a directory (the icon gets a screwy arrow but thats all) however it’s not, it is instead a “pointer” to a share on a different server (this share we can easily backup and maintain).
So the command to use is;
MKLINK /D <NAME> \\<SERVERNAME>\Sharename
eg, MKLINK /D HyperVisor5 \\SECRETSERVER\aarhus
HyperVisor5 is the name the directory will get locally the /D indicate it is a directory junction, and the link will point to \\SECRETSERVER\aarhus (aarhus is the share name on the SECRETSERVER)..
Ohh that was easy you say, yeah – well – it did not work 🙁
When a workstation attempted to access a mapped drive (eg. O:\Archive) it would get the above error.
And the solution was simple enough, you need to execute this command on the workstation that has the problem;
(the command above the yellow one show the state of your computer)
And now your workstation can browse the directory (which is actually a pointer to a share on a different server) just like it was on the local server.
This should also be controllable via Group Policy, however I have not had the chance to test it yet;
The symlink evaluation settings can also be controlled via Group Policy. Go to Computer Configuration > Administrative Templates > System > Filesystem and configure “Selectively allow the evaluation of a symbolic link”.