When to use mount points for Windows servers

Windows mount points are a common practice in the Exchange world, yet are sometimes misunderstood elsewhere. Here are a few more use cases for mount points.

In my tip about using Windows mount points in lieu of drive letters, a number of readers commented that they had a tough time applying this configuration. Here are several cases where using mount points make sense instead of assigning fixed drive letters:

  • Exchange server database groups: In many large Exchange server configurations, this is a best practice. It is supported for most Exchange configurations, as outlined in this KB article.
  • Windows distributed file system (DFS) shares with many large directories: In this configuration, a folder within a DFS share would correspond to a logical unit number (LUN) on a storage system. This will allow a single DFS share in the Active Directory namespace to have folders that can be managed on a SAN as a single LUN, and not burden the Windows server with too many local disk drive assignments. Further, the DFS share (or the file contents) could be relocated to another server at the SAN controller, saving precious time in large data moves.
  • A means to avoid the use of Windows dynamic disks: In most cases, Windows Server administrators still format drives as basic disk. While the dynamic disk is a way to extend capacity on demand, many administrators keep basic disks in use for application support, consistency, or consequence of default configuration.
  • When working with an application that has a fixed drive letter requirement, yet a dynamic growth requirement: This is sometimes referred to as "fill and spill" for a single drive letter and many folders underneath that drive letter. Each folder would be a mount point, allowing dynamic growth by keeping the same drive letter as a parent identifier.
There are operational considerations to using mount points. The primary point is that the parent drive (which actually has a drive letter) does not report the mount point as a total amount of space for the drive; the used and available space will only show that of the parent drive with the drive letter assigned. Figure A shows a Windows Server 2008 R2 system with three mount points of 1 TB each in the E:\ drive. Figure A

Click the image to enlarge.

In the image, you can see that the three 1 TB drives are assigned as mount points with the name Mount1, Mount2, and Mount3. When viewing the properties of the E:\ drive (the parent for the 1 TB drives), the free and used space is not represented. Further, you can also see the symbolic link represented as a junction point in the command prompt window when doing a DIR command of the E:\ drive. Mount1, Mount2, and Mount3 are the names assigned to the mount points when they were installed.

With mount points, you have a configuration that can scale to large amounts of storage within a single drive letter; this can be especially important if you are receiving the storage from many SAN locations or need to have it contained to a specific drive letter.

If you use mount points, tell us how you use them by posting to the discussion.

Stay on top of the latest Windows Server 2003 and Windows Server 2008 tips and tricks with our free Windows Server newsletter, delivered each Wednesday.

Automatically sign up today!


Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.


I have tried setting up a mount point on a DFS share in a test environment (2008 server R1), mounting the volume directly in/on the replicated folder. After starting and verifying the replication I brutally removed the volume from the mount point to see what happened, and DFS basically seemed to think that I'd deleted all files, and removed them from the replicating partner as well. The question is if 2008 R2 is more aware of mount points, or if Microsoft is planning to implement it in any future releases. Insight is welcome!

Who Am I Really
Who Am I Really

and workstations (especially helpful in peer work groups) anyone remember from DOS: - Assign - Join I used to use these to trick applications & games etc. into installing onto a separate partition or even other drives, it sure made those old game run faster working off of 2 disks & the CD rather than having all of the data on one I once had a win2K workstation with a very small & almost stuffed C:\ drive I used a mount point to another partition and moved the entire Office 2000 suite program data from Program Files\... and it didn't even whine once windows whined at first when I grabbed the folder and dropped it onto the root of the C:\ and then re-created the same folder as a mount point within Program Files and "moved" everything back to the "new location" which office assumed was still on the C: drive I mainly use mount points now on my home network (Peer Work Group no real server) to provide single entry points to access all my data on other machines: - create a single shared folder then mount every drive/partition in sub-folders inside the share - bingo all drives & files / Data etc. on the system accessible in the one share.


Linux has been doing it for years. It provides great flexibility, and the end-user doesn't "need to know" the details. When we start on a new project, it often gets its own physical drive. Sometimes, a single customer area will have its own physical drive. With mount points, it's all magic, handled behind-the-scenes by the OS: Consider for example, an IIS server - You could create "C:\IIS\" as your data area, and then mount separate physical drives as "C:\IIS\WWW" and "C:\IIS\FTP" and "C:\IIS\MAIL" Or continuing the same logic, you could mount different customers onto separate physical drives, such as "C:\IIS\WWW\CUSTOMER1", "C:\IIS\WWW\CUSTOMER2" and so on. If some area gets too big, you might even mount "C:\IIS\WWW\CUSTOMER1\BLOGS" to expand their space. The same idea applies in-house, if a project grows too big - the "D:\DATA\PROJECT1" directory could be moved onto a separate drive, and then mounted back into the same place in the directory structure. End-users don't even know it happened; suddenly, they're not crunched for space any more. Their applications, bookmarks, and directory references are not even aware of the change. Mount points provide limitless flexibility, good compartmentalization, and the technical details are transparent to the end-user. Access is controlled through standard security policies. And "running out of drive letters" becomes a thing of the past.

Photogenic Memory
Photogenic Memory

I was speaking to customer whose Exchange cluster recognized the mount points but couldn't access it after a sudden power-loss. Somehow ADS lost authentication. I think? Weird? The problem involved cluster services not starting under an authenticated ADS account. The solution was to select it's properties and re-add the user account and password. Voila. All fixed. I guess Exchange clusters are very brittle?

Editor's Picks