Creating Highly Available File and Printer Shares

www.lanzarotecaliente.com (press control & click here)

Operating System

Creating Highly Available File and Printer Shares with Windows 2000 Cluster ServiceBy Richard SasserMicrosoft CorporationPublished: June 2001

Contributors: Elden Christensen, Guy Henderson, Mike Lawson, John Marlin, Matt Mucker

Abstract

This white paper presents scenarios for creating highly available file and printer shares with the Cluster service feature in the Microsoft® Windows® 2000 operating system. Although by no means a comprehensive list of every possible scenario, it should provide a sufficient range of examples for administrators to implement Cluster service in the way that best serves their users’ needs.

http://www.lanzarotecaliente.com/




The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2001 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows NT, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.Other product and company names mentioned herein may be the trademarks of their respective owners.Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

Contents

Introduction............................................................................................1

Basic Terms and Concepts...................................................................2

Naming Conventions 2

Shared-Nothing Architecture 2

Resources 2

Dependencies 3

Groups 4

Failover and Failback 4

Virtual Server 5

Creating a Virtual Server 6

File Shares..............................................................................................7

Introduction: File Shares in Windows 2000 Cluster Service 7

Creating a File Share 7

Configuring the Resource-Specific Parameters 7

A Word About Permissions 8

Normal File Shares 9

Security 10

Server Consolidation—Scenario 1 10

Share Subdirectories Shares 12

Security 13

Server Consolidation—Scenario 2 13

Dfs Shares 14

Security 15

Scenario 15

Printer Shares.......................................................................................16

Introduction 16

Creating a Spooler Resource 16

Adding Printers 17

Adding Additional Drivers 18

Scenario 18

Implementation 18

Procedural Overview 18

Conclusion............................................................................................20

For More Information...........................................................................21

Appendix...............................................................................................22

Cluster Setup 22

Installation Notes 22

Creating a Virtual Server 23

Cluster Application Wizard 23

Resource by Resource 28

Creating a File Share Resource 33

Printers 35

Creating a Print Spooler Resource with the Cluster Application Wizard 35

Adding a Printer 41

Adding Drivers to the Other Node 47

Configuring Failback 49

IntroductionFile and print are among the most critical operating system services for end users on any computer network. Consequently, enabling administrators to create highly available file and print shares is one of the key goals of the Cluster service feature in the Microsoft® Windows® 2000 Advanced Server operating system. Since clustering is new to Windows and requires administrators to shift from a machine-centric view of Windows, this document was created to cover basics for proper implementation of Windows 2000 Cluster service, including the shared-nothing architecture of Cluster service, group structure, and virtual servers. File shares and print spoolers are addressed by type, and the Appendix provides a detailed illustration of the cluster setup referred to throughout this document.

Basic Terms and ConceptsThis section covers the basic terms and concepts that are used throughout this document.

Naming ConventionsNewcomers to clustering in Windows may become confused by the variance in naming conventions. During the beta of the Cluster service, the product was code-named Wolfpack. Once the product was released, the “official” name for the product was Microsoft Cluster service, sometimes referred to as MSCS. Various Knowledge Base articles may also refer to the technology as Cluster Server or Server Clustering. This is the same technology.

This type of clustering should not be confused with Network Load Balancing or Component Load Balancing.

Shared-Nothing ArchitectureCluster service uses a shared-nothing model of clustering. This model does not allow cluster members to access resources on other members of the cluster, as a shared-everything model would. It also avoids the overhead and inherent scalability limits that would be imposed by a shared-everything model. In terms of file and printer shares, this means that a file share is owned by only one node. To split file share load among multiple servers, the file shares themselves must be split into different virtual servers.

ResourcesA resource provides a service to a client, such as a file share, an Internet Protocol (IP) address, or a network name. Resources are the smallest management unit of Cluster service. Resources can depend on other resources and are organized into groups.

Creating Highly Available File and Printer Shares with Windows 2000 Cluster Service 1

DependenciesA dependency is a relationship between resources similar to service dependencies. Dependencies additionally define the order that resources are brought online and offline, and are typically represented as dependency trees. Figure 1 illustrates a standard dependency tree for a file share resource. In this illustration, should an administrator attempt to take the disk resource offline, the file share resource will come offline, and then the disk resource will come offline. The network name resource will not go to an offline state because there is no direct dependency on the disk for the network name. Conversely, if we then try to bring the file share resource online when the initial state of all the resources is offline, the disk and IP address will be brought online, then the network name, and then the file share resource. Note that there is no explicit dependency between the file share resource and the IP address. This is because dependencies are said to be transitive. This is not technically correct, but it provides a good description of the empirical behavior of a dependency.

Figure 1. Typical file share dependency tree

Given the above information, it would appear that a dependency is strictly a one-way relationship. This is not the case, however—a point which is best illustrated here by the print spooler resource. When adding a printer to a virtual server it is absolutely necessary to run the wizard from the network name for which the print spooler has a dependency. Applications, network name resources, and generic services also exhibit some similar behavior.


Note: For more information on dependencies, see the following Microsoft Knowledge Base articles: Q171791 Creating Dependencies in Microsoft Cluster Server Q198893 Effects of Checking "Use Network Name for Computer Name" in MSCS Q195462 WINS Registration and IP Address Behavior for MSCS 1.0

GroupsA group is a logical collection of resources that must all run on the same node to function properly. If the Information Store and Message Transfer Agent in Microsoft Exchange Server were to run on different servers, this would obviously generate some problems. This information also implies one very important fact: A group is the unit of failover in the cluster. Entire groups of resources move from one node to the other, not individual resources. The easiest way to build groups is around storage. Most applications and services require storage to function, as in the example of Exchange. Since dependencies can only be created within the same group, every application or resource that uses that disk needs to be in the same group as the disk resource. Groups are also generally organized as virtual servers, though more than one virtual server can exist in a group.

Failover and FailbackFailover is the process by which a group moves from one server to another. Failover can occur for several reasons:

The administrator has moved a group to a new server.

A resource in the group has exceeded its failure threshold.

The group is configured for failback and the original owner of the group has returned to service.

The third reason provides the definition for failback—that is, the group fails back to a preferred owner if so configured. Preferred owners are configured as a group property. Failback can be configured to occur either immediately or within a specific time period.

Note: For more information on failover and failback, consult the following Knowledge Base articles: Q197047 Failover/Failback Policies on Microsoft Cluster Server Q171277 Microsoft Cluster Server Cluster Resource Failover Time


http://support.microsoft.com/support/kb/articles/q171/2/77.asp





Virtual ServerA virtual server is a combination of two resources (for instance, an IP address resource and a network name resource) that work together to present a namespace to a client. Figure 2 illustrates the resources and dependency tree for a virtual server. Note that there is no reason that a group cannot contain multiple virtual servers, but this means that all virtual servers in the group can be owned by only one node at a time. Organizing groups into virtual servers provides finer granularity and better scalability, especially in scenarios where additional nodes are to be added later. Figure 3 illustrates the namespaces that will be presented to a client by the cluster nodes.

Note: Virtual servers are based on NetBIOS and thus have certain limitations. For more information, consult the following Knowledge Base article: Q235529 MSCS Virtual Server Limitations in Windows 2000 Domain

Figure 2. Virtual server dependency tree

Figure 3. Namespaces presented to clients by cluster nodes



Creating a Virtual ServerThere are two ways to construct a virtual server. Although a virtual server may be created manually, the easiest method is to use the Cluster Application Wizard (see Appendix). The Cluster Application Wizard creates a virtual server with the option to configure a cluster server application. Creating a virtual server manually requires that an IP address and network name resource be configured in the appropriate group.


File Shares

Introduction: File Shares in Windows 2000 Cluster ServiceAlthough clustered file shares behave exactly like normal file shares, creating and administering them is a bit different because they run on multiple machines. Clustered file shares must be created in Cluster Administrator from Administrative Tools. They cannot be created on a clustered drive from Windows Explorer. And depending on the type of share, administering permissions is a bit more complicated.

There are three types of file shares in Cluster service: normal, share subdirectories, and Microsoft Dfs (distributed file system) root. The normal file share functions exactly as a regular server message block share. The share subdirectories share is a specialized type of cluster resource that can be used to quickly and efficiently create a large number of shares. The Dfs root share functions exactly as a stand-alone Dfs root. Each share is addressed in turn.

Creating a File ShareCreating a file share is a simple matter of creating a new resource in the group. There is one peculiarity of the file share resource related to dependencies: Unless it is of a Dfs type, the file share resource does not require a dependency on either a storage class resource or a network name. If the data is to be stored on a shared disk, then the file share should have a dependency tree similar to that in Figure 1 above—that is, a dependency on a network name and the storage resource where the data is located. The reason that these dependencies are not required is for replication. It may be of use to place replicated data on local drives and create a file share that points to a local resource. In this particular case, Dfs is superior and provides for multiple replicas on different servers with a more robust feature set.

Configuring the Resource-Specific ParametersFigure 4 below shows the dialog box that allows you to configure the file share parameters.


Figure 4. File share parameters

A file share resource has the following parameters:

Share name—The name of the share on the network.

Path—The path to the share.

Comment—Comment field for browsing.

User Limit—Limit the number of users for a share.

Permissions—Share level permissions are administered here.

Advanced—The different types of file shares are selected here. The default share is normal.

Figure 5. Advanced file share properties

A Word About PermissionsTwo types of security can be used for file shares in Windows 2000. Share level security is enforced by the LanManServer service, which is basically an authentication mechanism that a client uses to prove its identity to a server. Both printer shares and file shares have strong ties to the LanManServer service, but Cluster


service simply provides a mechanism to dynamically register file and printer shares and detect their states. This leads to a minor inconsistency: The LanManServer service is not scoped, so when a cluster node owns a set of resources, it advertises all of these resources on all network names that it currently owns. This means that share names must be unique across the entire cluster. Microsoft plans to address this issue in a future version of Windows.

Note: For more information, consult the following Knowledge Base article: Q170762 Cluster Shares Appear in Browse List under Other Names

Share level security is enforced by the LanManServer service. The security descriptor for the share is stored in the registry under HKEY_LOCAL_MACHINE\System\Current Control Set\Services\LanManServer\Shares\Security. Locally logging in completely bypasses share level security because it does not access the files through the share. Share level permissions are administered from the file share parameters dialog box in Cluster Administrator.

NTFS security or file system security is considerably more robust because it is stored in an access control list on the disk itself. NTFS security applies whether or not a network connection is used to access the data. NTFS security is administered from Windows Explorer.

Note: The Cluster service account must have at least read permissions to the directory to create the share.

A final important point regarding permissions on clustered shares: Permissions should never be assigned to local groups on member servers. These permissions will have no meaning when the clustered disk resource is moved to another server. Permissions should always be assigned to a domain resource. In mixed-mode domains, this means that rights must be assigned to a global group, unless the cluster nodes are domain controllers. If the servers are domain controllers, access to domain local groups provides a more centralized means of administering permissions at the cost of the additional overhead of the Active Directory™ service, which is not inconsiderable. Additionally, for this strategy to be completely effective, all nodes of the cluster must be domain controllers.

In native-mode domains in Windows 2000, security can be handled entirely from universal groups, which are far more robust.

In most cases, the recommended method of applying security is to use NTFS level security and leave share level security open. Simultaneously administering both types of security is needlessly time-consuming and can create additional troubleshooting overhead. Windows 2000 will use the more restrictive of the two types of security if both are applied.

Note: If the share level permissions dialog box fails to display global resources appropriately, please refer to the following Knowledge Base article: Q278710 No Global Groups Are Available Creating File-Share Permissions

Normal File SharesA normal file share is the default type when a file share is first created. It has no special properties and is just like a share on a normal server except that it is accessed through the virtual network name in the group. Normal file shares do not have required dependencies, but if located on the shared storage, they should at a





minimum have dependencies on the shared storage, with the preferential addition of dependencies on the network name and IP address.

SecurityThe normal file share is the easiest to generate a security model for because of its lack of special behavior. Share level permissions are administered from Cluster Administrator. NTFS permissions are administered from Windows Explorer.

Server Consolidation—Scenario 1In this scenario, reskit.com has three servers that will be migrated to the cluster. The servers and their shares are listed in Table 1 below.

Table 1. Server Consolidation—Scenario 1

Server Name Department Shares

SEA-NA-FILE-01 Development CodeSpecs

SEA-NA-FILE-02 Support ProposalsContracts

SEA-NA-FILE-03 Management AccountsProposalsGroup

Performance analysis indicates that servers 01 and 02 are both high-traffic servers, but server 03 has relatively low traffic.

One possible problem: The support server and the management server both have “Proposals” shares. These shares must be unique across the cluster (see the section A Word About Permissions above), so they will be renamed “SupProposals” and “ManProposals.”

ImplementationEach server will be re-created on the cluster as a virtual server. Each virtual server will have its own group so that load may be distributed across servers. To improve performance, the groups containing the high-traffic servers, 01 and 02, will each have a failover policy that prefers that they are owned by different nodes. The group that contains server 03 will be left at default and moved as need dictates. Failback will be configured to occur between 23 and 0 hours.

Procedural Overview1. The data for the file shares on SEA-NA-FILE-01 is migrated to storage class resource drive X.

2. The old server is renamed or removed from the network to prevent name conflicts.

3. The Cluster Application Wizard is used to build the virtual server SEA-NA-FILE-01 for the group containing drive X.


4. Two file share resources are added to the group, corresponding to the file shares on the older server. Since the data is located on a shared volume, dependencies are selected for the network name and disk resource.

5. To configure failback policy for group SEA-NA-FILE-01:

a. In Cluster Administrator, right-click the group, and then click Properties.

b. On the General tab, click Modify to add SEA-NA-CLN-01 as the preferred owners.

c. Move SEA-NA-CLN-01 to the right side.

d. Click the Failback tab, and then click Allow failback.

e. Click Failback, enter between 23 and 0 hours, and then click OK.

Figure 6 below shows the group configuration for the SEA-NA-FILE-01 group. Arrows indicate dependencies.

Figure 6. Group configuration for SEA-NA-FILE-01

SEA-NA-FILE-02 is configured almost identically on drive Y, with the exception of different names and file share parameters. The only major difference is that the SEA-NA-FILE-02 group is configured with a preferred owner of SEA-NA-CLN-02.

SEA-NA-FILE-03 is configured almost identically on drive Z, with the exception of different names and file share parameters. There is no failback policy configured for this group.


Security ImplementationReskit.com is a mixed-mode domain; therefore global groups are created in each domain where users would be accessing the resource. Permissions are assigned to global groups as needed.

Share Subdirectories SharesA share subdirectories share does exactly that: It shares subdirectories. It does so dynamically; new shares added to the root share are shared out after a short period. For example, consider the following directory structure:

Figure 7. Sample directory structure

The following figure illustrates a file share resource created for the Users directory. The Share subdirectories option is selected in the Advanced File Share Properties dialog box.

Figure 8. File share resource


The following shares will be created:

Users

Guy

John

Martin

Rick

Matt

Note that the Mystuff directory is not shared. The Share subdirectories option does not share more than one level deep.

If an administrator later adds a new user to the users directory, for instance, T:\Users\Shon, the Shon share will be added a short time later. If you examine Advanced File Share Properties closely, you will notice the Hide subdirectory shares check box. Selecting this check box has the net effect of appending a $ to each subdirectory name, hiding the share. With this option selected, the shares created would be:

Users

Guy$

John$

The users directory would not be hidden because the dollar sign is only appended to the subshares. To hide the users directory, simply append a $ to its share name in the resource’s parameters dialog box.

SecuritySecurity for this type of share is slightly restrictive. The subdirectories created by the resource inherit the share level permissions of the parent. Unless this is the desired behavior, the share level permissions must be left at default and NTFS level security used. Cluster service must have NTFS level read permissions to the subdirectories to create the share.

Server Consolidation—Scenario 2In this scenario, reskit.com's cluster is performing far ahead of expectations. It turns out that one of the servers can easily handle all three virtual servers. It is time for the server that handles user home directories to be decommissioned and replaced with a larger server, so reskit.com decides to migrate the user shares to the cluster as well. SEA-NA-FILE-04 handles all of the user shares for noam.reskit.com.

ImplementationSEA-NA-FILE-04 is migrated to the cluster as a virtual server. Drive T is chosen to host the user directory. All user home directories are copied to the users subfolder on drive T and a share subdirectories file share resource is created in the SEA-NA-FILE-04 group.


Procedural Overview1.Under the Users directory, user data is migrated to the storage class resource drive T.

2.The old server is renamed or removed from the network to prevent name conflicts.

3.A virtual server, SEA-NA-FILE-04, is created in the same resource group as drive T.

4.A file share resource is created for T:\Users with a share name of Users$. The Share subdirectories option is set in Advanced File Shares Properties. Since the data is located on a shared volume, dependencies are selected for the network name and disk resource.

5.Existing failback policies are left as is. No failback policy is configured for the SEA-NA-FILE-04 group.

Security ImplementationNTFS full control permissions are assigned to each of the users for their respective home directories. The Cluster service is assigned read permission to all folders so that it could create the share.

Dfs SharesSelecting the Dfs root option in Advanced File Share Properties creates clustered Dfs shares. There can be only one Dfs root per cluster. The Dfs root created by Cluster service is not an Active Directory Dfs root. The following table illustrates the differences between an Active Directory Dfs root and a clustered Dfs root.

Table 2. Dfs Shares

Attribute Active Directory Dfs Clustered Dfs

Availability For N domain controllers For N cluster nodes

Replication overhead Yes No

Data redundancy Yes No

Multiple levels of links Yes No

Site preference Yes No

Publishes information to Active Directory

Yes No

Can have root level targets Yes No

A domain-based Dfs root with replicas can be a better choice for providing high availability for read-mostly data. If the data set changes frequently, replication is usually undesirable and Cluster service Dfs is preferred.

The dependency tree in Figure 1 is required in a Dfs resource. This means that the data for a Dfs share resource must be located on clustered storage.

To administer the Dfs server, use the Dfs Administration snap-in to connect to the virtual server the share depends on. For more information on Dfs, refer to the Windows 2000 Help for Dfs.


SecurityDfs roots and Dfs links can be controlled by either NTFS security or share level security. Administering a Dfs tree can involve some overhead, so it is considered a best practice to administer NTFS permissions on the servers where the data is located and to leave share level permissions open.

Dfs links may point to data on FAT volumes, however, so it may be necessary to use share level permissions.

ScenarioReskit.com has multiple servers that host several shares that are not currently suitable for migration to the cluster. However, users would like to be able to access these shares via a single namespace.

ImplementationHosting the Dfs root on the cluster provides a higher level of availability than a single server; a single server hosted link is susceptible to failure, leaving users that are dependent on that namespace without any access to their data. A Dfs root is created under a virtual server, SEA-NA-FILE-05. Dfs links direct clients to the proper servers.

Procedural Overview1. The Cluster Application Wizard is run and the virtual server SEA-NA-FILE-05 is created.

2. A directory to host the Dfs share is created on the shared storage in the SEA-NA-FILE-05 group.

3. A file share resource is created with a dependency on the network name and storage class resource in the SEA-NA-FILE-05 group. The Dfs root option is set in Advanced File Shares Properties.

4. Using the Dfs Administration snap-in, a connection is made to the virtual server SEA-NA-FILE-05, and Dfs links are added.


Printer Shares

IntroductionCluster service makes it possible to host multiple spooler resources. This allows the service to provide high availability for printer shares, along with the ability to distribute load among the cluster nodes. The print spooler resource is limited to one spooler resource per group. It has required dependencies for a network name resource (for consistent access to the spooler) and a physical disk (to store spooler files).

Once a spooler resource is created, printers must be added to it. In Windows 2000, the job is greatly simplified because the spooler resource maintains information about clustered printer ports in the cluster configuration database. This eliminates the need to install the ports twice, once on each node. Drivers, however, must be installed on both nodes because printer drivers are copied to the PRINT$ share of the remote server.

Clustered print spoolers only support standard port monitors and Line Printer Remote (LPR) printers. LPR ports do not support bidirectional printing. Currently, no other ports are supported.

When a group containing a print spooler resource fails over to another node, the document that is currently being spooled to the printer is restarted from the other node after the failure. When you move a print spooler resource or take it offline, Cluster service waits until all documents are finished spooling or until the configured wait time has elapsed. Documents that are spooling from an application to a print spooler resource are discarded and must be re-spooled to the resource (or reprinted) if the group containing the resource fails over before the application has finished spooling.

Printers hosted by a cluster node are published into Active Directory by the spooler service.

Creating a Spooler ResourceThe print spooler resource has required dependencies on a network name and a storage class resource. Figure 9 shows the dependency tree for a spooler resource.

Figure 9. Dependency tree for a spooler resource


On the resource parameters page of the New Resource Wizard, the only parameters provided are the location of the spool folder and the job completion timeout. The wizard, based on dependencies, provides these parameters automatically, so there is usually no need to modify them.

Figure 10. Print spooler parameters

Adding PrintersCreating the virtual server and the spooler resource is only half of the job. The spooler resource is useless without printers. To add a printer, it is necessary to first note the owning node of the virtual servers. This is because the Add Printers Wizard copies the drivers to the owning node only. The driver must then be manually installed on the other node.

The Add Printers Wizard must be started from the virtual server—specifically, the network name on which the print spooler depends. Once the printer is successfully installed, the driver must be added to the other node. Cluster Administrator shows the owner for the SEA-NA-PRN-01 group. Although several different methods exist to add the drivers to the other node, the command line shown in Figure 11 below starts the Add Printers Wizard directly. It is useful to create a shortcut to this command line on a file and print cluster.


Figure 11. Add Printers Wizard command line

Adding Additional Drivers Adding additional drivers that are not Windows 2000 drivers is relatively uncomplicated. Once the initial drivers are installed, additional drivers may be installed through the printer user interface (UI). The procedure is as follows:

1. Connect to the virtual server.

2. Open the Printers folder.

3. Right-click the printer to add drivers to, and then click Properties.

4. Click the Sharing tab, and then click the Additional drivers option.

5. Once the driver has been added, return to the Printers folder.

6. Fail the group to the other node.

7. Repeat steps 3 through 6.

ScenarioReskit.com has multiple printer servers it would like to consolidate to one cluster, SEA-NA-CLUS-02. There are approximately 200 printers, and performance is of prime importance.

ImplementationTo achieve better performance, the printers are split roughly evenly between two virtual servers, SEA-NA-PRINT-01 and SEA-NA-PRINT-02. Each virtual server is configured in its own resource group with a print spooler resource. Half the printers are installed to one virtual server, with the remaining half allocated for the other virtual server. Preferred owners are configured for each group, and each is assigned to a particular group. Failback is configured to occur between 23 and 0 hours.

Procedural Overview1. Create virtual servers SEA-NA-PRINT-01 and SEA-NA-PRINT-02, adding a print spooler in each virtual

server.

2. Add printers to the first node.

3. Add printers to the second node.


4. Configure failback policy for each group SEA-NA-PRINT-01

a. Right-click the group, and then click Properties.

b. On the General tab, click Modify to add SEA-NA-CLN-01 as the preferred owners.

c. Move SEA-NA-CLN-01 to the right side.

d. Click the Failback tab, and then click Allow failback.

e. Click Failback between, and then enter 23 and 0 hours.

5. Repeat steps a through e for SEA-NA-PRINT-02 and SEA-NA-CLN-02, respectively.

6. Move groups to their preferred owners.


ConclusionBecause of the importance of file and print services to the end users on a computer network, Windows 2000 Advanced Server provides Cluster service, a powerful feature for improving the reliability and performance of file and print services. However, Cluster service must be deployed properly to provide these benefits to users.

Since clustering is new to Windows, it requires administrators to look at familiar tasks in new ways. For example, while clustered file shares behave exactly like normal file shares, creating and administering them is a bit different because they run on multiple machines.

Moreover, clustered file shares must be created using the Cluster Administrator in Administrative Tools, and they can involve more complicated administration of permissions. Similarly, the use of clustering for printer services requires that administrators apply dependencies for a network name resource and a physical disk.


For More InformationFor more information about Windows 2000 Cluster service, see the following resources:

Step-by-Step Guide to Installing Cluster Service

Server Cluster Glossary

Windows 2000 Advanced Server, Clustering Microsoft ITG Infrastructure Services

Cluster Management and Administration

Windows Clustering Technologies

Q259267 Microsoft Cluster Service Installation Resources

Q258750 Recommended Private "Heartbeat" Configuration on Cluster Server

Q174812 Effects of Using Autodetect Setting on Cluster NIC

Q197047 Failover/Failback Policies on Microsoft Cluster Server

Q171277 Microsoft Cluster Server Cluster Resource Failover Time

Q171791 Creating Dependencies in Microsoft Cluster Server

Q198893 Effects of Checking "Use Network Name for Computer Name" in MSCS

Q195462 WINS Registration and IP Address behavior for MSCS 1.0

Q278710 No Global Groups Are Available Creating File-Share Permissions

Q235529 MSCS Virtual Server Limitations in Windows 2000 Domain












http://www.microsoft.com/WINDOWS2000/library/technologies/cluster/default.asp

http://www.microsoft.com/WINDOWS2000/hpc/clusmgmt.asp

http://www.microsoft.com/BUSINESS/HowMicrosoftWorks/resources/win2cluster.asp

http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/mscs/cs_gloss_2gl5.htm

http://www.microsoft.com/windows2000/library/planning/server/clustersteps.asp

Appendix

Cluster Setup

Figure 12. Cluster Setup

Installation Notes The heartbeat cards were set to a speed and configured per the following articles in the Microsoft

Knowledge Base:Q258750 Recommended Private "Heartbeat" Configuration on Cluster ServerQ174812 Effects of Using Autodetect Setting on Cluster NIC

WARNING: At no time should both systems be booted with access to the shared resources, unless at least one of them has Cluster service. Install the first node with the second node down, then boot the second node and install Cluster service. FAILURE TO HEED THIS WARNING COULD RESULT IN FILE SYSTEM CORRUPTION THAT MAY BE UNDETECTABLE UNTIL A LATER DATE.

For additional cluster installation resources, consult:Q259267 Microsoft Cluster Service Installation Resourceshttp://www.microsoft.com/windows2000/library/planning/server/clustersteps.asp


http://www.microsoft.com/windows2000/library/planning/server/clustersteps.asp




Creating a Virtual Server

Cluster Application WizardTo start the Cluster Application Wizard, in Cluster Administrator, on the File menu, click Configure Application.

Figure 13. Cluster Administrator window

At the Welcome to the Cluster Application Wizard page, click Next.

Figure 14. Cluster Application Wizard


With Select or Create a Virtual Server, you can configure an application for an existing virtual server or create a virtual server. Since this section is about creating virtual servers, Create a new virtual server is selected.

Figure 15. Select Create a new virtual server

The next page is used to select a group for the virtual server or to create a new group. In general, you should use an existing cluster group, unless storage class resource is either not needed or will be created or moved to the new group. The storage class resource to be used by this virtual server is located in Disk Group 1.

Figure 16. Assign a resource group


Even though an existing group is selected, the group should be given a new name and description to reflect its current function. In this particular instance, the group is named after the virtual server, but this is not necessary and may not even be desired because a group can host more than one virtual server.

Figure 17. Name the resource group

Once the group name and description are configured, the IP address and network name for the virtual server are provided.

Figure 18. Provide a network name and IP address


After the virtual server properties are provided, the wizard presents an opportunity to edit detailed information regarding the group and resources. This is not necessary at this time, so it is skipped.

Figure 19. Set advanced properties

At this point, the virtual server is configured. The wizard will prompt for the creation of an application resource. Since, in this example, only the virtual server itself is of interest, No, I’ll create a cluster resource for my application later is selected.

Figure 20. The Create Application Cluster Resource screen


The wizard then provides a status page.

Figure 21. Cluster Application Wizard status page

Once the wizard is completed, the group is created, but in an offline state. To fully test the virtual server, right-click the group, and then click Bring Online.

Figure 22. To test the group, right click the group in the Cluster Administrator and click Bring Online


If all is well, the group should come completely online. To check the virtual server, ping from a client by IP address. To test name resolution, ping by name.

Resource by ResourceAlternatively, the virtual server can be created manually simply by adding an IP address and a network name to an existing group. To begin, right-click the group in which the virtual server will exist, and then click New then Resource. In this example, the Disk Group 2 was clicked. This starts the New Resource Wizard.

The first resource that must be created is an IP address resource. This example shows the creation of the SEA-NA-FILE-02 virtual server. The first step is to identify the resource type. The Name box is for a convenient label, and the Description box is a place for more detailed information.

Figure 23. Setting new resource parameters


The next page in the wizard allows specification of possible owners. By default, all nodes in the cluster are possible owners. If a node is removed from the possible owners list of a resource, the group in which the resource exists cannot fail over to that node. Since this group is intended for failover, the default is used.

Figure 24. Assigning resource owners

The next step in correctly adding the resource is to configure resource dependencies. IP addresses have no dependencies, so this page is left as is.

Figure 25. Configure resource dependencies

The final step is to configure resource-specific properties. An IP address has the following parameters:


Address—The IP address that will be registered on the adapter.

Subnet mask—The subnet mask that will be used for this IP address. This field is populated automatically.

Network—The network on which the IP address will be registered.

Enable NetBIOS for this address—Clear this check box if NetBIOS is not needed for this virtual server. NetBIOS is required for browsing to function properly. There is a limit of 64 NetBT devices in Windows. If this limit is exceeded, further IP address resources cannot use NetBIOS.

Figure 26. Enable NetBIOS check box

The IP address has been created.

Figure 27. Resource confirmation dialog box


Now a network name needs to be configured for the virtual server. The procedure is much the same, with the exception of selecting the type of resource dependencies and resource-specific parameters. The New Resource Wizard is started from Disk Group 2 by right-clicking the group and then clicking New then Resource. The resource type is, of course, a network name.

Figure 28. Configure a network name

Leave Possible owners at the default setting.

Figure 29. The Possible Owners screen


A dependency is configured for the previously created IP address. A dependency on an IP address is required for a network name.

Figure 30. Configure resource dependencies

The only resource-specific parameter for a network name is the name itself. This is the name of the virtual server on the network, and it must conform to standard computer naming rules.

Figure 31. Name the virtual server

Click Finish to create the network name.


At this point, the resource group may be brought online in the same manner that was used with the Cluster Application Wizard example. To give the group a more descriptive name, right-click the group, and then click Rename on the shortcut menu.

Figure 32. Rename the resource

Creating a File Share ResourceIn this example, the resource is started from the group that contains the virtual server SEA-NA-FILE-01.

Figure 33. The New Resource screen


Configure possible owners.

Figure 34. Configure possible owners

Add dependencies for the network name and storage resource.

Figure 35. Add dependencies


Next, configure the resource-specific parameters.

Figure 36. Configure file share parameters

A file share resource has the following parameters:

Share name—The name the folder will be shared on the network as.

Path—The path to the share.

Comment—A comment field for the share.

User Limit—A section to configure the user limit for the file share.

Permissions—Share level permissions are administered here.

Advanced—Select the type of file share here. The default is normal share.

Printers

Creating a Print Spooler Resource with the Cluster Application WizardIn this example, the Cluster Application Wizard is used to create the virtual server SEA-NA-PRINT-01 and configure the print spooler resource.


To start the Cluster Application Wizard, in Cluster Administrator, on the File menu, click Configure Application.

Figure 37. Cluster Application Wizard

Here, since the intent is to create a new virtual server and configure the application in one step, Create a new virtual server is selected.

Figure 38. Select Create a new virtual server


An existing resource group with a storage class resource is selected. The storage class resource to be used by this virtual server is located in Disk Group 3.

Figure 39. Select Use an existing resource group

The group name and description are provided.

Figure 40. Name the resource group


No additional configuration items are needed for the Advanced Properties page. Click Next to create the virtual server.

Figure 41. Click Next to create the virtual server

Yes, create a cluster resource for my application now is selected.

Figure 42. Accept the default selection


The resource type is Print Spooler.

Figure 43. Select Print Spooler as the resource type

The name and description for the resource are provided. To add dependencies, click Advanced Properties.

Figure 44. Click Advanced Properties


In the Advanced Resource Properties dialog box, click the Dependencies tab, and then click Modify.

Figure 45. The Resource dependencies screen

In the Modify Dependencies dialog box, the appropriate dependencies are moved to the right side.

Figure 46. Modify dependencies


Once dependencies are configured, click OK until Next becomes available. This will create the resource and prompt for resource-specific parameters. The wizard fills in the parameters based on dependencies. Usually, no additional modification is needed.

Figure 47. The provided print spooler parameters generally do not need to be modified

The virtual server and spooler resource are now configured. The group can now be brought online.

Adding a PrinterIn this example, the connection must be made to SEA-NA-PRINT-01. To start the connection, on the Start menu, click Run.

Figure 48. Connect to the virtual server


The Printers folder is selected.

Figure 49. Select the Printers folder


From the Printers folder, start the Add Printer Wizard. From a remote connection, the only option is to add a printer to the remote print server.

Figure 50. Only Remote print server can be selected

This is a new printer, so a new port must be created.

Figure 51. Select Create a new port


The Add Standard TCP/IP Printer Port Wizard is started.

Figure 52. The Add Standard TCP/IP Printer Port Wizard welcome screen

The port name field is populated as soon as the printer name or IP address is entered.

Figure 53. The Port Name field is populated


Once the port is configured, the Add Printer Wizard resumes, requesting a driver. In this example, a Lexmark Optra is selected.

Figure 54. Select the correct printer driver

You then name the printer.

Figure 55. Name the printer


The share name is automatically populated, but it can be changed.

Figure 56. Set printer sharing preferences

Information can be provided regarding the printer’s location and capabilities.

Figure 57. Adding printer location and comments


Printer installation is complete.

Figure 58. The Add Printer Wizard is now complete

Adding Drivers to the Other NodeTo start the connection, on the Start menu, click Run. This command starts the Add Printer Driver Wizard.

Figure 59. Start the Add Printer Driver Wizard


This allows the installation of the necessary print drivers to the other node.

Figure 60. Selecting the appropriate printer driver

This step is only necessary for the first Windows 2000 printer driver. Once this step is completed, additional drivers for other platforms can be installed through the printer user interface.

Figure 61. Complete the Add Printer Driver Wizard


Configuring FailbackThis section covers configuring a group for failback to a preferred owner. The example is drawn from the scenario for creating normal file shares and configuring failback.

To begin configuring failback, right-click the group and select properties.

Right-click the group and select Properties

Figure 62. Select the group


On the General tab in the group Properties dialog box, click Modify.

Click the Modify Button

Figure 63. Modify group properties

In the Modify Preferred Owners dialog box, add the desired preferred owner.

Figure 64. Nodes available for addition to the preferred owners


Since this example is drawn from the first scenario, SEA-NA-CLN-01 is added.

Figure 65. Add nodes to the preferred owners

On the Failback tab, the default option of Prevent failback is changed to Allow failback, with Failback between configured for 23 and 0 hours.

Figure 66. Configure failback settings

This completes the process for configuring a group for failback to a preferred owner.
