Win 2003 High Availability Solutions, File Share Resource

The previous article in our series dedicated to Windows 2003 Server based high availability solutions began an overview of clustering resources, presenting their general characteristics and interdependencies, as well as describing features of the most basic ones (such as IP Address, Network Name, Physical Disk, Print Spooler, DHCP, and WINS Services). We also explained the concept of a resource group and a virtual server. We continue the discussion here, focusing this time on the File Share resource.

Like its non-clustered equivalent, File Share resource provides access via a network to portions of server disk volumes designated for sharing. While its primary advantage, compared to a traditional file share, is high availability, it is important to remember that this benefit applies exclusively to its ability to remain online in case of a failure of its hosting server, but it does not imply storage resiliency. Without employing additional mechanisms that offer volume redundancy (such as fault-tolerant RAID configurations or some type of data replication), you will still face downtime following a disk loss. Even with these extra precautions, data remains vulnerable to file system corruption, so make sure not to neglect performing regular backups.

Although the concept of File Share resource might seem quite straightforward, several caveats apply during even most basic implementations. First, File Share must coexist within the same group with Physical Disk, IP Address (which has the “Enable NetBIOS for this address” check box marked) and be dependent on its Network Name resource, which together form a virtual server.

Creating dependency on Network Name and Physical Disk is not enforced (unless the share is designated as DFS root, which must have a Network Name specified as its subordinate), but it is a common practice. This not only ensures share does not remain online if the virtual server hosting it becomes unavailable (which would preclude access to it anyway), but also establishes proper sequence in which resources are activated and deactivated (i.e., the dependent resource will follow its dependencies when starting and precede with them during shutdown).

Besides identifying dependencies, when creating File Share resource, you are prompted (as part of the New Resource wizard) to provide name, path (pointing to an existing, non-shared folder on a Physical Disk resource), share-level permissions (most likely, you will want to modify default, which grants Read access to Everyone), caching setting (with default Manual caching for all documents), and maximum number of simultaneous user connections.

These settings are identical to those configurable when creating a traditional, non-clustered share. However, remember that on clustered shares, permissions (both on share and NTFS level) should be assigned to Active Directory domain groups (local, global or universal), rather than server local groups defined on the node that is the current owner of the resource group. Such an assignment would become invalid following a failover to another node. Furthermore, the account used by the Cluster Service must have at least READ rights to the share.

In addition to setting up a standard file share, you can also configure it as a parent folder for any number of automatically shared subdirectories. This is extremely convenient when setting up home or profile directories for a large number of users. If you enable it, all first-level subfolders of a clustered File Share Resource become automatically shared.

You also have an option of hiding them from browsing. Simply check a single check box, which causes “$” to be appended to their names. Both settings are available from the Advanced File Share Properties dialog box that appears after clicking on Advanced command button on Parameters tab of the File Share Properties dialog box in the Cluster Administrator. For these changes to take effect, recycle the File Share resource by taking it offline and then bringing it online. Alternatively, you can accomplish the same results with CLUSTER command line utility by executing the following, where “FileShare” is the name of the File Share resource:

CLUSTER res "FileShare" /priv ShareSubDirs=1
CLUSTER res "FileShare" /priv HideSubDirShares=1

The last remaining option in the Advanced File Share Properties dialog box enables the creation of a stand-alone Distributed File System (DFS) root. DFS is a technology that simplifies access to shared folders scattered across multiple servers. With DFS, users see one customized, virtual, directory structure — independent of actual location. Individual virtual subfolders (referred to as “links” in DFS nomenclature) within this structure can be redundant, by pointing to a number of identical copies (known as “targets”) of the same folder on separate systems.

In general, there are two types of DFS installations, depending on the location where configuration information is stored. Stand-alone types use a registry of a single server hosting the root folder of a directory structure (and, for that reason, called “root server”). For domain-based types, information is written into Active Directory and, subsequently, replicated to one or more designated root servers. In this arrangement, it is possible to have multiple computers serving this role. Besides the extra redundancy, domain-based DFS installations also offer the ability to replicate the content of its targets. While the same functionality can be delivered in stand-alone implementations, this requires incorporating additional mechanisms external to DFS, such as custom scripts and third-party utilities for target content replication, or server clustering for high availability of a stand-alone DFS root.

For more information about DFS, refer to Distributed File System Technology Center on the Microsoft Web site.

Clustered share resources are not capable of serving as the root of a domain-based DFS (which, as we pointed out in the previous paragraph, is inherently redundant anyway) but can operate as a stand-alone DFS root. As with any standard share, it is also possible to set it up as a target. Unlike on Windows 2000 platforms, there is no longer a limit of a single stand-alone DFS root per server. Multiple stand-alone roots can be hosted on the same cluster, without regard for the resource groups to which they belong or nodes on which they are hosted. Each share name must be unique across all cluster nodes, and locations in shared storage directory structure cannot overlap. Thus, it is not possible to create a clustered DFS root whose path contains a portion of a path of another DFS root, for example, S:DFSRoot1 and S:DFSRoot1DFSRoot2.

Files hosted on clustered share can be encrypted. To accomplish this, a computer account of the virtual server hosting a share resource must be trusted for delegation, and accounts of users who want to protect their data must be configured to allow delegation. These are general requirements that must be satisfied to encrypt files on a remote server, unless access is provided through WebDAV, as WebDAV does not rely on delegation. When dealing with clustered File Shares, it is also necessary to publish in Active Directory the Network Name resource of a virtual server that hosts them. This is done by turning on the “Enable Kerberos Authentication” check box on the Parameters tab of the Network Name Properties dialog box in the Cluster Administrator. For more information on this subject, refer to the previous article of this series. Alternatively, you can use CLUSTER command line utility by typing:

CLUSTER res "NetworkName" /priv RequireKerberos=1

“NetworkName” is the name of the virtual server intended for publication in Active Directory. Keep in mind the resource must be offline for this operation to succeed. Once you bring it online, a new computer account with the name matching Network Name resource will be generated in the Computers container in Active Directory — unless the default is changed with REDIRCMP utility.

Next, to designate an Active Directory computer account as trusted for delegation for the purpose of EFS support, launch Active Directory Users and Computers MMC snap-in. This procedure describes an interface specific to Windows 2003 Server domain controller, where you can take advantage of constrained delegation. Use of unconstrained delegation is not recommended. Locate the target server, right-click on its icon, and select Properties from the context-sensitive menu. Once the Properties dialog box is displayed, switch to the Delegation tab, select “Trust this computer for delegation to specified services only” and “Use Kerberos only” options, and click on Add command button.

From the Add Services dialog box, which is displayed next, click on Users or Computers button, type the name of the virtual server in the Select Users and Computers window (or use Advanced … button to search for it, and select it from the list of objects matching criteria you provided), and click on OK to confirm your selection.

At this point, you should see Service Principal Names (SPNs) of all services available on the target server. Pick protected storage (Protected Storage) and cifs (Common Internet File System) entries from the list (press Ctrl key to allow multiselect), and click on OK twice to confirm your actions.

Once the server portion of delegation setup is completed, verify that all of the users who are supposed to be able to use it do not have the “Account is sensitive and cannot be delegated” option checked on the Account tab of their accounts Properties dialog box in Active Directory Users and Computers. Be aware of implications of this setting for highly privileged accounts, since with this setting enabled, servers can perform any action on behalf of that user, including those resulting from mistakes or security breaches.

If you rely on compression for controlling disk space utilization, remember that compression and encryption are mutually exclusive — encryption will result in uncompressed files. Furthermore, if you are concerned about data security, remember that EFS protects it only during disk access, but it does not affect how it is transmitted over the network. Such protection can be provided by IPSec or Web Distributed Authoring and Versioning based shares.

Quotas are also supported on clustered shares, although the number of available features depends on the version of Windows 2003 Server running on cluster nodes. At a minimum, you should be able to implement quotas at the volume level either via Windows Explorer interface or by leveraging Group Policies, as described in Microsoft Knowledge Base article 278365. The only cluster-specific caveat is making sure quotas are assigned to domain user accounts, rather than local ones.

If your clusters are on the Windows 2003 Server R2-level, you can take advantage of File Server Resource Manager once its installed on cluster nodes. This introduces a number of quota-related improvements, such as volume usage calculations that take into consideration actual file size (rather than ignoring space savings gained through compression, which was the case in earlier quota implementations), simplified management (through the use of preconfigured and custom templates), higher granularity (it is possible to assign quotas on volume or folder level without specifying users to which they apply since restricting access can be accomplished via NTFS permissions), enhanced monitoring and alerting (allowing for customizable e-mail notifications to users and administrators), automation (through the ability to launch command or script-in response to quota violation events), and logging (including generating Windows Event log entries).

File Server Resource Manager also offers versatile storage-related reporting (simplifying the resolution of common issues like file duplicates, identifying those least recently accessed, or determining users who occupy most space and exceed their quotas) as well as file screening, which supplements quotas by providing the ability to control storage utilization based on file categories and types.

Another features included in Windows 2003 Server R2 that has a positive impact on File Sharing functionality discussed in this article is DFS Replication. It provides a superior alternative to File Replication Service used in earlier versions of DFS. Benefits include scheduling, throttling and compression of replication traffic.

The next article in this series will look into other types of clustered resources offering improvements to standard file sharing capabilities.