Win 2003 High Availability Solutions, Volume Mount Points

By Marcin Policht (Send Email)
Posted Jul 6, 2007


Recent installments of our series describing Windows 2003 High Availability solutions, have looked at more common resource types present in Server Clustering. The most recent one focused on File Share, covering majority of its characteristics, including encryption and quotas. Although they are not configurable directly through any clustering administrative utilities, they are worth mentioning due to a few peculiarities that must be considered to make them fully operational in clustered installations.

We continue our coverage of file-sharing-related features by zooming in on volume mount points and volume shadow copies on Windows 2003 server based clusters.

Discuss this article in the ServerWatch discussion forum

This article will take a closer look at volume mount points and volume shadow copies. The next article will provide an overview of access-based enumeration and clustered implementation of Network File System.

The volume mount points functionality is built into NTFS version 5, which has been available since the release of Windows 2000. Its primary goal is to provide access to content of a disk volume (in any format recognizable by the host operating system, including removable media), without having a drive letter assigned to it. NTFS associates it with a designated empty folder on another, NTFS-formatted, local volume. This eliminates legacy restriction on the number of volumes a single system hosts, where each of required a unique drive letter (the issue common in environments utilizing CD-ROM towers) as well as enabling an increase in the amount of space allocated to a volume without resorting to rebuilding it.

Volume mount points leverage reparse points mechanism, also introduced (in limited capacity — at least compared to equivalent feature that are widely popular across a variety of Unix and Linux flavors) in NTFS version 5, with the more generic purpose of associating an arbitrary location within file system structure with a customized set of features. Whenever designated locations are accessed, their respective features are activated, resulting in a desired behavior. This enables reparse points to serve as the basis for the following:

  • Symbolic Links: File system objects that point to entries in a volume structure, allowing you to redirect standard file system access requests (e.g., read and write) from one location to another. Prior to the release of Vista, Windows supported only symbolic directory links (i.e., those involving folders pointing to other folders or volumes and taking the form of directory junctions and volume mount points), but not file-based ones. This was finally resolved in Vista, which not only includes the MKLINK command line utility, which is capable of managing all of them and incorporating additional improvements, such as extending their scope to remote systems or support for hard links, but also makes DEL and RD commands symbolic link-aware.

  • Directory Junctions: Category of symbolic links that operate on the folder level (i.e., they provide redirection between two folders residing on local NTFS-5-formatted volumes). They play an important role in Windows 2000 and 2003 based Active Directory environments. Each domain controller contains predefined junction points at %windir%SYSVOLSYSVOLdomain_name folder linked to %windir%SYSVOLdomain folder and at %windir%SYSVOLstaging areasdomain_name linked to %windir%SYSVOLstagingdomain where, domain_name is DNS name of the locally installed Windows domain). However, Microsoft seems reluctant to offer any type of standard management tools, leaving users with programming methods (requiring custom coding) and the officially unsupported LINKD.EXE command line utility (included in the freely downloadable Windows Server 2003 Resource Kit). Its slightly more versatile alternative JUNCTION.EXE (which not only allows you to create and delete junction points, but also to enumerate them) has been developed by Mark Russinovich and posted on the Sysinternals section of the Microsoft Web site. Lack of official Microsoft support for directory junctions is likely related to potentially confusing behavior triggered by commands and utilities, including third-party software. Such products are not aware of their idiosyncrasies. This issue has been addressed in Vista with the restriction of Create Symbolic Link privilege to the local Administrator account, and versions of Command Prompt and Windows Explorer are capable of distinguishing symbolic links, as demonstrated by <SYMLINK>/<SYMLINKD> flags and uniquely designed icons. However, junction point management in earlier Windows operating systems still constitutes a challenge.

  • Remote Storage Service: An archival technology present on Windows 2000 and Windows 2003 Server platforms, which offloads files from a primary storage, leaving behind reparse points linked to their new location on a secondary storage devices (recordable media, such as tapes or optical drives). Accessing these reparse points triggers a copy associated with them that files back to the original volume. Remote Storage Services do not support shared cluster disk resources.

Exploring Volume Mount Points on Windows 2003 Server Based Clusters

Following this lengthy introduction into the subject of reparse points and their variations, let's return to our primary area of interest and explore volume mount points on Windows 2003 Server based clusters in more detail. This feature was not supported in clustered installations with earlier versions of Windows. In general, its implementation involves the same procedures that apply to non-clustered systems.

Clusters leverage either the graphical interface of Disk Management MMC snap-in (DISKMGMT.MSC) or MOUNTVOL command line utility. In the case of the former, you must pick the "Change Drive Letter and Paths" option from the context-sensitive menu of a volume that you intend to mount, which appears in the lower, right-hand side portion of the console window. This triggers the display of a dialog box with three command buttons, labeled Add ..., Change ..., and Remove.

The first of them allows you to mount the selected volume on an arbitrarily chosen folder residing on an NTFS formatted drive. To locate it, click the Browse ... button. MOUNTVOL is a bit more cumbersome to use, since it requires knowledge of Volume GUIDs, which you can determine by launching it from the Command Prompt window without any parameters. With MOUNTVOL you can remove obsolete mount points (associated with non-existing volumes) and control automatic mounting behavior, which can be disabled or enabled with /N and /E switches.

This feature might be helpful if you are deploying a cluster in a SAN environment and want to prevent dynamic LUN scanning, as they can potentially lead, in cases of a zoning misconfiguration, to corruption of shared disk volumes.

When planning mount points in highly available configurations, take cluster-specific caveats into consideration. In particular, ensure that Physical Disks resources representing volumes involved in mount points — the first hosting an empty folder and the second mounted on it — belong to the same clustered group, with the second dependent on the first one, which is set from the Dependencies tab of the resource Properties dialog box. Do not create mounts between non-clustered and clustered volumes, since they will not function following a failover. Try to dedicate a small size drive to host mount points, since this approach minimizes the duration of its maintenance and recovery operations (such as running CHKDSK), limiting impact on availability of mounted volumes. You might want to also define duplicate, redundant mount points hosted on separate Physical Disk resources within the same clustered group. This arrangement will likely require modifying resource dependencies.

Keep in mind that Windows Explorer's disk space statistics do not take mounted volumes into consideration. Similarly, the scope of common disk utilities (such as CHKDSK.EXE) does not extend beyond the actual volume on which they were initiated. On the other hand, NTBACKUP includes, by default, volumes mounted on folders that its backup operations target — though it does offer an option to bypass their content. Finally, ensure cluster nodes are at Windows 2003 Service Pack 2 level, to avoid problems described in the Microsoft Knowledge Base article 898790. At a minimum, be sure to install the corresponding patch.

Now let's turn our attention to another type of File Share resource-related functionality that can be implemented in the clustered environment. Volume Shadow Copy is a feature introduced in Windows 2003 Server that enables remote users connected via Common Internet File System (CIFS) protocol to retrieve older versions of recently modified files. This is accomplished by creating snapshots that capture status of all files on designated, NTFS-formatted server volumes at specific points in time (typically according to an arbitrary schedule). Any files that have been modified since the previous snapshot are included in the one that follows.

The snapshot contains only block-level incremental changes between two consecutive file versions, which ensures optimum space utilization. Such files can be easily identified and retrieved with a client component (Shadow Copy Restore) built into Windows 2003 Server. Its version for Windows 2000 and Windows XP is available from Microsoft Download Center, which integrates with Windows Explorer interface and takes the form of Previous Versions tab of the Properties dialog box for a specific file (in case its content has been modified since the most recent shadow copy) or its parent folder (in case the file has been deleted). From there, it is possible to view content of existing shadow copies, restore the content to the original location (overwriting the current version), or store it at an alternate location.

Shadow copy mechanism does not constitute a replacement for standard backup procedures. Shadow-copy-protected volumes remain susceptible to media failures, and the number of copies maxes out at 64 along with other disk space limitations that may apply. Such protection, however, can greatly simplify the significant portion of recovery scenarios. It can address corruption of individual files, as well as their unintentional changes and deletions, and it enables them to be handled directly by end users, without involving support staff.

To configure clustered Volume Shadow Copies, launch Computer Management MMC snap-in (COMPMGMT.MSC) on the node which is the current owner of shares you want to protect, expand its System Tools node, and select All Tasks -> Configure Shadow Copies ... from the context-sensitive menu of the Shared Folders subfolder.

In the resulting Shadow Copies dialog box, you have an option of generating (using the Enable button) a scheduled task that will trigger a copy in regular intervals according to predefined settings. If you want to customize them, activate the Settings dialog box (by clicking on Settings ... command button), from where you can modify such parameters as a volume used to store shadow copies, maximum disk space allocated to them (assigned by default at 10 percent of the volume size or 300 MB, whichever happens to be greater), and their schedule (by default, they occur twice a day at 7am and 12pm Monday through Friday).

To improve performance, consider a dedicated volume (and corresponding Physical Disk resource) to host shadow copies (separate from the Physical Disk resource on which the file share resides), although you must ensure they both reside within the same resource group: Their dependency is established automatically once Shadow Copy is enabled. Within the Shadow Copies dialog box can view existing copies for all local volumes on the target server (to which you connected via Computer Management console), revert to any of them, trigger creation of new ones, or delete them with Revert..., Create Now, and Delete Now command buttons, respectively.

Enabling Shadow Copy on a clustered volume automatically adds a Volume Shadow Copy Service Task resource to the same group where the target Physical Disk and dependent on it File Share reside. The new resource depends on the Physical Disk where shadow copies are stored (based on the described earlier setting in Shadow Copies dialog box), has an autogenerated name that consists of ShadowCopyVolume string concatenated with its GUID enclosed within braces, and its role is executing %systemroot%system32vssadmin.exe utility with Create Shadow /AutoRetry=5 /For=Volume identifier switches, where Volume identifier is the volume GUID. For more information on the syntax of vssadmin.exe refer to Microsoft Windows Server TechCenter.

This process also causes target Physical Disk resources and any of dependents to switch temporarily to an offline state. Hence, you must be careful with implementations in a production environment. Also, shadow copies are not volume mount-point-aware — in other words, creating a shadow copy of a volume hosting folders that map to other volumes will not contain any of the data.

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.