Increase available drive space with free space on another system

When a file server runs out of disk space there may be plenty of free disk space available on another server. As a fall-back, many network administrators create a new share and a new drive mapping to point to in the free space on the other server. This results in data being scattered and users being overwhelmed by numerous drive letters.

The Distributed File System (DFS) engine can provide a free and simple-to-implement solution to this issue. DFS is included with Windows 2000 and Windows 2003 Server (and downloadable for Windows NT 4). It provides the ability to mount a share from one server into a folder on another server, which can then be navigated as if it was part of an existing share. These mount-points can be stand-alone or domain-based to provide redundancy.

For this TechByte we will consider the simple example of using DFS to extend usable disk space on a file server ("FILE1") with space from another server ("OTHER2").

Assume that FILE1 has a folder "D:\Shared" which is shared as "\\FILE1\SHARED" and mapped on client PCs as drive S:. The D: drive on FILE1 is full.

Server OTHER2 has considerable free space on its D: drive. Rather than creating a new share and a new drive letter, we we want to make this space available as part of the S: drive. We create a new folder on OTHER2's D:\dfsfile1 and share it as DFSFILE1. It's worth noting that the system with usable free space does not have to be a server, it can be any client on which you can create a share.

A logical division of the data is necessary to determine what will be redirected using DFS. We recommend that you pick a single large folder at the root of the drive if possible. Let us assume there is a large folder called S:\Projects which would be a logical folder to move.

As DFS is merely redirecting the request for a network resource, creating a DFS link does not actually add disk space to FILE1's D: drive. Therefore, some data will have to be moved off of the D: drive to provide space for data in folders other than S:\Projects. The Projects folder and all of its contents (files and subfolders) are moved to \\OTHER2\DFSFILE1. There should no longer be a Projects folder in \\FILE1\SHARED.

When moving this data it is important to consider file permissions and security. The moved files will automatically inherit permissions from the destination folder (\\OTHER2\DFSFILE1). When moving files you can attempt to copy the files while retaining permissions by using a utility like robocopy, however this may not be helpful unless you are copying between domain controllers as the local SAM (and therefore user and group SIDs) on all other systems will be unique. It may be easier to re-create the permission structure (and any required local groups) on the destination server.

On FILE1 we then launch the DFS interface through Administrative Tools -> Distributed File System (or you can run dfsgui.msc). We right-click on the Ditributed File System entry and choose New Dfs Root.... Following the wizard through, we Create a standalone Dfs Root on FILE1. When prompted, we choose to Use an existing share, choosing the SHARED share which is currently being mapped as S:. Creating the DFS root here should not affect the existing share or its data in any way. We follow the wizard through to the end and Finish.

We will now see the new DFS root listed: \\FILE1\SHARED. Right-clicking on this we choose New Dfs Link.... For the Link name we enter Projects -- this will be the name of the virtual folder which will be created in DFS root. In Send the user to this shared folder we enter the full path to the new location of the Projects folder: \\OTHER2\DFSFILE1\Projects and click OK.

From a client workstation, if we now open the S: drive (which is mapped to \\FILE1\SHARED) we will now see a Projects folder again. Double-clicking this folder will actually show the contents of \\OTHER2\DFSFILE1\Projects, however this is transparent from the client, which shows the path as S:\Projects exactly as if it was a local path.

Some things to consider or be aware of:

Users must connect to the Dfs link using the share configured as the DFS root (in our example, \\FILE1\SHARED). If they connect to a different share ( e.g. \\FILE1\D$) and browse down to DFS link folder which exists at a lower level, the redirected folder will appear blank.
If using a mapped drive letter as we are in this example (S:) some clients may need to disconnect and re-connect the drive letter.
The DFS link will appear as a local folder on the DFS root server (FILE1), however it cannot be accessed as a local path. Attempting to open the folder as a local path will result in an Access is denied message. The redirected files can still be accessed from the DFS root server via the share path the same as it can from any other client.
As the redirected files are not be available via a local path, back-ups of the DFS root server will not back up files across the DFS link. Be sure you are backing up the server which contains the linked files as well as the root.
There will be some degradation in network performance when requesting files via DFS, so it's best not to use this sort of configuration for high-performance scenarios.
The additional space "added" through the DFS link will not be included in the total drive space or the free space on the root volume.

Some helpful links:

Author: ASAK
Created: Dec 16 2005
Categories: Windows 2000 Server - Windows 2003 Server
TechByte #113

Warning: By visiting this site and/or by using any information contained herein, you agree to the Techbytes.ca terms of use.