Microsoft Failover Clustering 2008

9/7/2015 MyCollection
My Collection
This document is provided "asis". Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product or product name. You may copy and use this document
for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2015 Microsoft. All rights reserved. Terms of Use
https://technet.microsoft.com/cc300389.aspx | Trademarks http://www.microsoft.com/library/toolbar/3.0/trademarks/enus.mspx
http://pabprod.blob.core.windows.net/books/573f89e519e54d8b9316f55be361978b.html 1/58
Table Of Contents
Chapter 1
Failover Clusters
Chapter 1
Failover Clusters
Applies To: Windows Server 2008 R2
Overview of Failover Clusters
Checklist: Create a Failover Cluster
Checklist: Create a Clustered File Server
Checklist: Create a Clustered Print Server
Checklist: Create a Clustered Virtual Machine
Installing the Failover Clustering Feature
Validating a Failover Cluster Configuration
Creating a Failover Cluster or Adding a Cluster Node
Configuring a Service or Application for High Availability
Migrating to a Failover Cluster Running Windows Server 2008 R2
Modifying Settings for a Failover Cluster
Managing a Failover Cluster
Resources for Failover Clusters
User Interface: The Failover Cluster Manager SnapIn
2015 Microsoft

A cluster is a set of independent computers that work together to increase the availability of services and applications. The clustered servers called nodes are
connected by physical cables and by software. If one of the nodes fails, another node begins to provide service through a process known as failover.
You can use the Microsoft Management Console MMC snapin, Failover Cluster Manager, to validate failover cluster configurations, create and manage failover
clusters, and migrate certain settings to a cluster running the WindowsServer2008R2 operating system. You can also configure and manage failover clusters by
using Windows PowerShell. These Help topics describe methods for using Failover Cluster Manager. For more information about using Windows PowerShell for failover
clusters, see http://go.microsoft.com/fwlink/?LinkId=135119 and http://go.microsoft.com/fwlink/?LinkId=135120.
In Windows Server2008 and Windows Server2008R2, the improvements to failover clusters formerly known as server clusters in Windows Server 2003 are aimed at
simplifying clusters, making them more secure, and enhancing cluster stability. Cluster setup and management are easier. Security and networking in clusters have been
improved, as has the way a failover cluster communicates with storage.
Note that the Failover Clustering feature is included in server products such as Windows Server2008R2 Enterprise and Windows Server2008R2 Datacenter. The
Failover Clustering feature is not included in Windows Server2008R2 Standard or Windows Web Server2008R2.
Additional references
For a list of links to a variety of topics about failover clusters, see http://go.microsoft.com/fwlink/?LinkId=68633.
For design and deployment information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137832.
For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137836.
For operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137835.
2015 Microsoft

If you want to provide high availability for users of one or more file shares, see a more complete checklist at Checklist: Create a Clustered File Server.
If you want to provide high availability for users of one or more print servers, see a more complete checklist at Checklist: Create a Clustered Print Server.
Step Reference
Review hardware and infrastructure requirements for a failover cluster. Understanding

Requirements for
Failover Clusters
Install the Failover Clustering feature on every server that will be in the cluster. Install the Failover
Clustering Feature
Connect the networks and storage that the cluster will use. Prepare Hardware
Before Validating a
Failover Cluster
Run the Validate a Configuration Wizard on all the servers that you want to cluster, to confirm that the hardware and hardware settings Validate a New or
of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and Existing Failover
rerun the wizard until all tests pass required for support. Cluster
Create the failover cluster. Create a New

Failover Cluster
After you have created a failover cluster, the next step is usually to configure the cluster to support a particular service or application. For more information, see
Configuring a Service or Application for High Availability.
2015 Microsoft

Step Reference
On every server that will be in the cluster, open Server Manager, click Add roles and then use the Add Roles Wizard to add the File Help in Server
Services role and any role services that are needed. Manager
Review hardware and infrastructure requirements for a failover cluster. Understanding

Requirements for
Failover Clusters
Install the Failover Clustering feature on every server that will be in the cluster. Install the Failover
Clustering Feature
Connect the networks and storage that the cluster will use. Prepare Hardware
Before Validating a
Failover Cluster
Run the Validate a Configuration Wizard on all the servers that you want to cluster, to confirm that the hardware and hardware settings Validate a New or
of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware or hardware settings and Existing Failover
rerun the wizard until all tests pass required for support. Cluster
Create the failover cluster. Create a New

Failover Cluster
If the clustered servers are connected to a network that is not to be used for network communication in the cluster for example, a Modify Network
network intended only for iSCSI or only for backup, then configure that network so that it does not allow cluster communication. Settings for a
Failover Cluster
Run the HighAvailability Wizard and specify the File Server role, a name for the clustered file server, and IP address information that is Configure a Service
not automatically supplied by your DHCP settings. Also specify the storage volume or volumes. or Application for
High Availability
Add shared folders to the clustered file server as needed. Create a Shared
Folder in a Clustered
File Server
Test the failover of the clustered file server. Test the Failover of a
Clustered Service or
Application
Modify the Failover Settings for a Clustered Service or Application
2015 Microsoft

Step Reference
On every server that will be in the cluster, open Server Manager, click Add roles and then use the Add Roles Wizard to Help in Server Manager
add the Print and Document Services role and any role services that are needed.
Review hardware and infrastructure requirements for a failover cluster. Understanding Requirements for
Failover Clusters
Install the Failover Clustering feature on every server that will be in the cluster. Install the Failover Clustering
Feature
Connect the networks and storage that the cluster will use. Prepare Hardware Before
Validating a Failover Cluster
Run the Validate a Configuration Wizard on all the servers that you want to cluster, to confirm that the hardware and Validate a New or Existing Failover
hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust Cluster
hardware or hardware settings and rerun the wizard until all tests pass required for support.
Create the failover cluster. Create a New Failover Cluster
If the clustered servers are connected to a network that is not to be used for network communication in the cluster for Modify Network Settings for a
example, a network intended only for iSCSI or only for backup, then configure that network so that it does not allow Failover Cluster
cluster communication.
Run the HighAvailability Wizard and specify the Print Server role, a name for the clustered print server, and IP address Configure a Service or Application
information that is not automatically supplied by your DHCP settings. for High Availability
Configure print settings such as the setting that specifies the printer. Configure the Print Settings for a
Clustered Print Server
Test the failover of the clustered print server. Test the Failover of a Clustered
Service or Application
From a client, print a test page on the clustered print server. Help for the operating system on
the client for specifying the path
to the clustered print server
Help from the application from

which you print the test page
2015 Microsoft

Step Reference
Review hardware and infrastructure requirements for a failover cluster. Understanding Requirements for
Failover Clusters
Review hardware requirements for HyperV. Hardware requirements for

HyperV
http://go.microsoft.com/fwlink/?
LinkId=137803
Review concepts related to HyperV and virtual machines in the context of a cluster. Understanding HyperV and
Virtual Machines in the Context
If you want to use Cluster Shared Volumes for your virtual machines, review concepts related to Cluster Shared Volumes. of a Cluster
Understanding Cluster Shared
Volumes in a Failover Cluster
Install HyperV role and Failover Clustering feature on every server that will be in the cluster. Install HyperV
LinkId=137804
Install the Failover Clustering

Feature
Connect the networks and storage that the cluster will use. In HyperV Manager, create virtual networks that will be Prepare Hardware Before
available for virtual machines to use. Validating a Failover Cluster
Managing virtual networks

LinkId=139566
Run the Validate a Configuration Wizard on all the servers that you want to cluster, to confirm that the hardware and Validate a New or Existing
hardware settings of the servers, network, and storage are compatible with failover clustering. If necessary, adjust hardware Failover Cluster
or hardware settings and rerun the wizard until all tests pass required for support.
Create the failover cluster. Create a New Failover Cluster
If the clustered servers are connected to a network that is not to be used for network communication in the cluster for Modify Network Settings for a
example, a network intended only for iSCSI or only for backup, then configure that network so that it does not allow Failover Cluster
cluster communication.
If you want to use Cluster Shared Volumes and you have not already enabled this feature, enable Cluster Shared Volumes. Enable Cluster Shared Volumes
in a Failover Cluster
Create a virtual machine and configure it for high availability, being sure to select Store the virtual machine in a different Configure a Virtual Machine for
location and specify appropriate clustered storage. If you have Cluster Shared Volumes, for the storage, specify a Cluster High Availability
Shared Volume a volume that appears to be on the system drive of the node, under the \ClusterStorage folder.
Otherwise, create the virtual machine on the node that currently owns the clustered storage for the virtual machine, and
specify the location of that storage.
None of the files used by a clustered virtual machine can be on a local disk. They must all be on clustered storage.
If you have not already installed the operating system for the virtual machine, install the operating system. If there are Install a guest operating system
HyperV integration services for that operating system, install them in the operating system that runs in the virtual http://go.microsoft.com/fwlink/?
machine. LinkId=137806
Reconfigure the automatic start action for the virtual machine so that it does nothing when the physical computer starts. Configure virtual machines
LinkId=137807
Test the failover of the clustered virtual machine. Test the Failover of a Clustered
Virtual Machine
Refresh the Configuration of a Virtual Machine
Configure a Virtual Machine for High Availability
2015 Microsoft

Before you can create a failover cluster, you must install the Failover Clustering feature on all servers that you want to include in the cluster. This section provides
instructions for installing this feature.
Note that the Failover Clustering feature is included in server products such as Windows Server2008R2 Enterprise and Windows Server2008R2 Datacenter. The
Failover Clustering feature is not included in Windows Server2008R2 Standard or Windows Web Server2008R2.
Install the Failover Clustering Feature
2015 Microsoft

You can install the Failover Clustering feature by using the Add Features command from Initial Configuration Tasks or from Server Manager.
Note
The Failover Clustering feature is included in server products such as Windows Server2008R2 Enterprise and Windows Server2008R2 Datacenter. The Failover
Clustering feature is not included in Windows Server2008R2 Standard or Windows Web Server2008R2.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate
accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To install the Failover Clustering feature
1. If you recently installed Windows Server2008R2 on the server and the Initial Configuration Tasks interface is displayed, under Customize This Server, click
Add features. Skip to Step 3.
2. If Initial Configuration Tasks is not displayed, add the feature through Server Manager:
If Server Manager is already running, click Features. Then under Features Summary, click Add Features.
If Server Manager is not running, click Start, click Administrative Tools, click Server Manager, and then, if prompted for permission to continue, click
Continue. Then, under Features Summary, click Add Features.
3. In the Add Features Wizard, click Failover Clustering and then click Install.
4. When the wizard finishes, close it.
5. Repeat the process for each server that you want to include in the cluster.
Understanding Requirements for Failover Clusters
2015 Microsoft

Before you create a failover cluster, we strongly recommend that you validate your configuration, that is, that you run all tests in the Validate a Configuration Wizard. By
running the tests, you can confirm that your hardware and settings are compatible with failover clustering.
You can run the tests on a set of servers and storage devices either before or after you have configured them as a failover cluster.
Important
Microsoft supports a failover cluster solution only if the complete configuration servers, network, and storage can pass all tests in the Validate a Configuration
Wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008 R2."
With the Validate a Configuration Wizard, you can run the complete set of configuration tests or a subset of the tests. The wizard provides a report that shows the result
of each test that was run.
Understanding Microsoft Support of Cluster Solutions
Understanding Cluster Validation Tests
Prepare Hardware Before Validating a Failover Cluster
Validate a New or Existing Failover Cluster
Use Validation Tests for Troubleshooting a Failover Cluster
2015 Microsoft

Updated: July 8, 2010
A failover cluster must meet certain requirements for hardware, software, and network infrastructure, and it requires the administrator to use an account with the
appropriate domain permissions. The following sections provide information about these requirements.
Hardware requirements for a failover cluster
Deploying storage area networks with failover clusters
Software requirements for a failover cluster
Network infrastructure and domain account requirements for a failover cluster
For additional information about hardware compatibility for Windows Server2008R2, see http://go.microsoft.com/fwlink/?LinkId=139145.
Hardware requirements for a failover cluster

You need the following hardware in a failover cluster:
Servers: We recommend that you use a set of matching computers that contain the same or similar components.
Important
Microsoft supports a failover cluster solution only if all the hardware components are marked as "Certified for Windows Server 2008 R2." In addition, the
complete configuration servers, network, and storage must pass all tests in the Validate a Configuration Wizard, which is included in the Failover Cluster
Manager snapin.
For information about hardware compatibility for Windows Server2008R2, see http://go.microsoft.com/fwlink/?LinkId=139145.
For information about the maximum number of servers that you can have in a failover cluster, see http://go.microsoft.com/fwlink/?LinkId=139146.
Network adapters and cable for network communication: The network hardware, like other components in the failover cluster solution, must be marked as
"Certified for Windows Server2008R2." If you use iSCSI, your network adapters should be dedicated to either network communication or iSCSI, not both.
In the network infrastructure that connects your cluster nodes, avoid having single points of failure. There are multiple ways of accomplishing this. You can
connect your cluster nodes by multiple, distinct networks. Alternatively, you can connect your cluster nodes with one network that is constructed with teamed
network adapters, redundant switches, redundant routers, or similar hardware that removes single points of failure.
Note
If you connect cluster nodes with a single network, the network will pass the redundancy requirement in the Validate a Configuration Wizard. However, the
report from the wizard will include a warning that the network should not have single points of failure.
For more details about the network configuration required for a failover cluster, see Network infrastructure and domain account requirements for a failover
cluster, later in this topic.
Device controllers or appropriate adapters for the storage:
For Serial Attached SCSI or Fibre Channel: If you are using Serial Attached SCSI or Fibre Channel, in all clustered servers, all components of the storage
stack should be identical. It is required that the multipath I/O MPIO software and Device Specific Module DSM software components be identical. It is
recommended that the massstorage device controllersthat is, the host bus adapter HBA, HBA drivers, and HBA firmwarethat are attached to cluster
storage be identical. If you use dissimilar HBAs, you should verify with the storage vendor that you are following their supported or recommended
configurations.
Note
With Windows Server2008R2, you cannot use parallel SCSI to connect the storage to the clustered servers. This was also true for Windows
Server2008.
For iSCSI: If you are using iSCSI, each clustered server should have one or more network adapters or host bus adapters that are dedicated to the cluster
storage. The network you use for iSCSI should not be used for network communication. In all clustered servers, the network adapters you use to connect
to the iSCSI storage target should be identical, and we recommend that you use Gigabit Ethernet or higher.
For iSCSI, you cannot use teamed network adapters, because they are not supported with iSCSI.
For more information about iSCSI, see the iSCSI FAQ on the Microsoft Web site http://go.microsoft.com/fwlink/?LinkId=61375.
Storage: You must use shared storage that is compatible with Windows Server2008R2.
In most cases, the storage should contain multiple, separate disks LUNs that are configured at the hardware level. For some clusters, one disk functions as the
disk witness described at the end of this subsection. Other disks contain the files required for the clustered services or applications. Storage requirements
include the following:
To use the native disk support included in failover clustering, use basic disks, not dynamic disks.
We recommend that you format the partitions with NTFS. If you have a disk witness or use Cluster Shared Volumes, the partition for each of those must
be NTFS.
For Cluster Shared Volumes, there are no special requirements other than the requirement for NTFS. For more information about Cluster Shared Volumes,
see Understanding Cluster Shared Volumes in a Failover Cluster.
For the partition style of the disk, you can use either master boot record MBR or GUID partition table GPT.
A disk witness is a disk in the cluster storage that is designated to hold a copy of the cluster configuration database. A failover cluster has a disk witness only if
this is specified as part of the quorum configuration. For more information, see Understanding Quorum Configurations in a Failover Cluster.
Deploying storage area networks with failover clusters

When deploying a storage area network SAN with a failover cluster, follow these guidelines:
Confirm compatibility of the storage: Confirm with manufacturers and vendors that the storage, including drivers, firmware, and software used for the storage,
are compatible with failover clusters in Windows Server2008R2.
Important
Storage that was compatible with server clusters in Windows Server2003 might not be compatible with failover clusters in Windows Server2008R2. Contact
your vendor to ensure that your storage is compatible with failover clusters in Windows Server2008R2.
Failover clusters include the following new requirements for storage:
Improvements in failover clusters as compared to server clusters in Windows Server2003 require that the storage respond correctly to specific SCSI
commands. To confirm that your storage is compatible, run the Validate a Configuration Wizard. In addition, you can contact the storage vendor.
The miniport driver used for the storage must work with the Microsoft Storport storage driver.
Isolate storage devices, one cluster per device: Servers from different clusters must not be able to access the same storage devices. In most cases, a LUN used
for one set of cluster servers should be isolated from all other servers through LUN masking or zoning.
Consider using multipath I/O software: In a highly available storage fabric, you can deploy failover clusters with multiple host bus adapters by using multipath
I/O software. This provides the highest level of redundancy and availability. For Windows Server2008R2, your multipath solution must be based on Microsoft
Multipath I/O MPIO. Your hardware vendor will usually supply an MPIO devicespecific module DSM for your hardware, although Windows Server2008R2
includes one or more DSMs as part of the operating system.
Important
Host bus adapters and multipath I/O software can be very version sensitive. If you are implementing a multipath solution for your cluster, you should work
closely with your hardware vendor to choose the correct adapters, firmware, and software for Windows Server2008R2.
Software requirements for a failover cluster

All the servers in a failover cluster must either run the x64based version or the Itanium architecturebased version of Windows Server2008R2 nodes within a single
failover cluster cannot run different versions.
All the servers should have the same software updates patches and service packs.
The Failover Clustering feature is included in server products such as Windows Server2008R2 Enterprise and Windows Server2008R2 Datacenter. The Failover
Clustering feature is not included in Windows Server2008R2 Standard or Windows Web Server2008R2.
Network infrastructure and domain account requirements for a failover cluster

You will need the following network infrastructure for a failover cluster and an administrative account with the following domain permissions:
Network settings and IP addresses: When you use identical network adapters for a network, also use identical communication settings on those adapters for
example, Speed, Duplex Mode, Flow Control, and Media Type. Also, compare settings between the network adapter and the switch it connects to and make sure
that no settings are in conflict.
If you have private networks that are not routed to the rest of your network infrastructure, ensure that each of these private networks uses a unique subnet. This
is necessary even if you give each network adapter a unique IP address. For example, if you have two cluster nodes in a central office that uses one physical
network, and two more nodes in a branch office that uses a separate physical network, do not specify 10.0.0.0/24 for both networks, even if you give each
adapter a unique IP address.
For more information about the network adapters, see Hardware Requirements for a Failover Cluster, earlier in this topic.
DNS: The servers in the cluster must be using Domain Name System DNS for name resolution. The DNS dynamic update protocol can be used.
Domain role: All servers in the cluster must be in the same Active Directory domain. As a best practice, all clustered servers should have the same domain role
either member server or domain controller. The recommended role is member server.
Domain controllers: We recommend that your clustered servers be member servers. If they are, other servers will be the domain controllers in the domain that
contains your failover cluster.
Clients: There are no specific requirements for clients, other than the obvious requirements for connectivity and compatibility: the clients must be able to
connect to the clustered servers, and they must run software that is compatible with the services offered by the clustered servers.
Account for administering the cluster: When you first create a cluster or add servers to it, you must be logged on to the domain with an account that has
administrator rights and permissions on all servers in that cluster. The account does not need to be a Domain Admins accountit can be a Domain Users
account that is in the Administrators group on each clustered server. In addition, if the account is not a Domain Admins account, the account or the group
that the account is a member of must be delegated Create Computer Objects and Read All Properties permissions in the domain. For more information, see
Failover Cluster StepbyStep Guide: Configuring Accounts in Active Directory http://go.microsoft.com/fwlink/?LinkId=139147.
Note
There is a change in the way the Cluster service runs in Windows Server2008R2, as compared to Windows Server2003. In Windows Server2008R2, there is
no Cluster service account. Instead, the Cluster service automatically runs in a special context that provides the specific permissions and privileges necessary
for the service similar to the local system context, but with reduced privileges.
2015 Microsoft

Microsoft supports a failover cluster solution only if it meets the following requirements:
All hardware components in the failover cluster solution are marked as "Certified for Windows Server2008R2."
The complete cluster configuration servers, network, and storage can pass all tests in the Validate a Configuration Wizard.
The hardware manufacturers' recommendations for firmware updates and software updates patches have been followed. Usually, this means that the latest
firmware and software updates have been applied. Occasionally, a manufacturer might recommend specific updates other than the latest updates.
2015 Microsoft

With the Validate a Configuration Wizard, you can run tests to confirm that your hardware and hardware settings are compatible with failover clustering. You can run
the complete set of configuration tests or a subset of the tests.
We recommend that you run the tests on your set of servers and storage devices before you configure them as a failover cluster create a cluster from them. You can
also run the tests after you create a cluster.
Note that the Failover Clustering feature must be installed on all the servers that you want to include in the tests.
Important
The Validate a Configuration Wizard includes five types of tests:
Cluster Configuration tests. For an existing cluster, provide a simple way to review cluster settings and determine whether they are properly configured. These
tests run only on existing clusters. For more information, see Understanding Cluster Validation Tests: Cluster Configuration.
Inventory tests. Provide an inventory of the hardware, software, and settings such as network settings on the servers, and information about the storage. For
more information, see Understanding Cluster Validation Tests: Inventory.
Network tests. Validate that your networks are set up correctly for clustering. For more information, see Understanding Cluster Validation Tests: Network.
Storage tests. Validate that the storage on which the failover cluster depends is behaving correctly and supports the required functions of the cluster. For more
information, see Understanding Cluster Validation Tests: Storage.
System Configuration tests. Validate that system software and configuration settings are compatible across servers. For more information, see Understanding
Cluster Validation Tests: System Configuration.
The report from the Validate a Configuration Wizard includes messages such as the following about each test:
The tested item meets requirements for a failover cluster.
The tested item might meet the requirements, but there is a warning about something that you should check.
The test item does not meet requirements.
The test could not be run for example, if you are testing a single node by itself, certain tests do not run.
2015 Microsoft
Understanding Cluster Validation Tests: Cluster Configuration

Cluster configuration tests make it easier to review the cluster settings and determine whether they are properly configured. The cluster configuration tests run only on
existing clusters not servers for which a cluster is planned. The tests include the following:
List Cluster Core Groups: This test lists information about Available Storage and about the group of resources used by the cluster itself.
List Cluster Network Information: This test lists clusterspecific network settings that are stored in the cluster configuration. For example, it lists settings that
affect how often heartbeat signals are sent between servers on the same subnet, and how often they are sent between servers on different subnets.
List Cluster Resources: This test lists details for all the resources that are configured in the cluster.
List Cluster Volumes: This test lists information about volumes in the cluster storage.
List Clustered Services and Applications: This test lists the services and applications configured to run in the cluster.
Validate Quorum Configuration: This test validates that the quorum configuration is optimal for the cluster. For more information about quorum
configurations, see Understanding Quorum Configurations in a Failover Cluster.
Validate Resource Status: This test validates that cluster resources are online, and lists the cluster resources that are running in separate resource monitors. If a
resource is running in a separate resource monitor, it is usually because the resource failed and the Cluster service began running it in a separate resource
monitor to make it less likely to affect other resources if it fails again.
Validate Service Principal Name: This test validates that a Service Principal Name exists for all resources that have Kerberos enabled.
Validate Volume Consistency: This test checks for volumes that are flagged as inconsistent "dirty" and if any are found, provides a reminder that running
chkdsk is recommended.
2015 Microsoft
Understanding Cluster Validation Tests: Inventory

Inventory tests provide lists of information about the hardware, software, and settings on each of the servers you are testing. You can use inventory tests alone without
other tests in the Validate a Cluster Configuration Wizard to review or record the configuration of hardware for example, to review that the software updates on each
server are identical after you perform scheduled maintenance.
You can run the following inventory tests by using the Validate a Configuration Wizard:
List BIOS Information
List Environment Variables: Examples of environment variables are the number of processors, the operating system path, and the location of temporary folders.
List Fibre Channel Host Bus Adapters
List iSCSI Host Bus Adapters
List Memory Information
List Operating System Information
List Plug and Play Devices
List Running Processes
List SAS Host Bus Adapters: This test lists the host bus adapters for Serial Attached SCSI SAS.
List Services Information: As a general best practice for servers, especially cluster nodes, you should run only necessary services.
List Software Updates: You can use this test to help correct issues that are uncovered by one of the System Configuration tests, Validate Software Update
Levels. For more information, see Understanding Cluster Validation Tests: System Configuration.
List System Drivers
List System Information: The system information includes the following:
Computer name
Manufacturer, model, and type
Account name of the person who ran the validation tests
Domain that the computer is in
Time zone and daylight time setting determines whether the clock is adjusted for daylight time changes
Number of processors
List Unsigned Drivers: You can use this test to help correct issues that are uncovered by one of the System Configuration tests, Validate All Drivers Signed. For
more information, see Understanding Cluster Validation Tests: System Configuration.
2015 Microsoft
Understanding Cluster Validation Tests: Network

Network tests help you confirm that the correct network infrastructure is in place for a failover cluster.
Correcting issues uncovered by network tests

For information about how to correct the issues that are revealed by network tests, see:
Network tests in the Validate a Configuration Wizard

You can run the following network tests by using the Validate a Configuration Wizard:
List Network Binding Order: This test lists the order in which networks are bound to the adapters on each node.
Validate Cluster Network Configuration includes the following tasks:
Lists the cluster networks, that is, the network topology as seen from the perspective of the cluster.
Validates that, for a particular cluster network, all network adapters are provided with IP addresses in the same way that is, all use static IP addresses or all
use DHCP.
Validates that, for a particular cluster network, all network adapters use the same version of IP that is, all use IPv4, all use IPv6, or all use both IPv4 and
IPv6.
Validate IP Configuration includes the following tasks:
Lists the IP configuration details.
Validates that IP addresses are unique in the cluster no duplication.
Checks the number of network adapters on each tested server. If only one adapter is found, the report provides a warning about avoiding single points of
failure in the network infrastructure that connects clustered servers.
There are multiple ways of avoiding single points of failure. You can connect your cluster nodes by multiple, distinct networks. Alternatively, you can
connect your cluster nodes with one network that is constructed with teamed network adapters, redundant switches, redundant routers, or similar
hardware that removes single points of failure.
Validates that no tested servers have multiple adapters on the same IP subnet.
Validates that all tested servers use the same version of IP that is, all use IPv4, all use IPv6, or all use both IPv4 and IPv6.
Validate Multiple Subnet Properties: This test validates that settings related to DNS are configured appropriately for clusters using multiple subnets to span
multiple sites.
Validate Network Communication: This test validates that tested servers can communicate with acceptable latency on all networks. The test also checks to see
if there are redundant communication paths between all servers. Communication between the nodes of a cluster enables the cluster to detect node failures and
status changes and to manage the cluster as a single entity.
Validate Windows Firewall Configuration: This test validates that Windows Firewall is configured correctly for failover clustering on the tested servers.
2015 Microsoft
Understanding Cluster Validation Tests: Storage

Storage tests analyze the storage to determine whether it will work correctly for a failover cluster running Windows Server2008R2.
Correcting issues uncovered by storage tests

If a storage test indicates that your storage or your storage configuration will not support a failover cluster, review the following suggestions:
Contact your storage vendor and use the utilities provided with your cluster storage to gather information about the configuration. In unusual cases, your
storage vendor might indicate that your cluster solution is supported even though this is not reflected in the storage tests. For example, your cluster solution
might have been specifically designed to work without shared storage.
Review results from multiple tests in the Validate a Configuration Wizard, such as the List Host Bus Adapters test see the topic Understanding Cluster
Validation Tests: Inventory and two tests that are described in this topic, List All Disks and List Cluster Disks.
Look for a storage validation test that is related to the one that uncovered the issue. For example, if Validate Multiple Arbitration uncovered an issue, the
related test, Validate Disk Arbitration, might provide useful information.
Review the storage requirements in Understanding Requirements for Failover Clusters.
Review the documentation for your storage, or contact the manufacturer.
Storage tests in the Validate a Configuration Wizard

You can run the following storage tests by using the Validate a Configuration Wizard:
List All Disks
List Potential Cluster Disks
Validate Disk Access Latency
Validate Disk Arbitration
Validate Disk Failover
Validate File System
Validate Microsoft MPIOBased Disks
Validate Multiple Arbitration
Validate SCSI Device Vital Product Data VPD
Validate SCSI3 Persistent Reservation
Validate Simultaneous Failover
List All Disks

This test lists all disks that are visible to one or more tested servers. The test lists:
Disks that can support clustering and can be accessed by all the servers.
Disks on an individual server.
The following information is listed for each disk:
Disk number
Unique identifier
Bus type
Stack type
Disk address where applicable, including the port, path, target identifier TID, and Logical Unit Number LUN
Adapter description
Disk characteristics such as the partition style and partition type
You can use this test to help diagnose issues uncovered by other storage tests described in this topic.
List Potential Cluster Disks

This test lists disks that can support clustering and are visible to all tested servers. To support clustering, the disk must be connected through Serial Attached SCSI SAS,
iSCSI, or Fibre Channel. In addition, the test validates that multipath I/O is working correctly, meaning that each of the disks is seen as one disk, not two.
Types of disks not listed by the test

This test lists only disks that can be used for clustering. The disks that it lists must:
Be connected through Serial Attached SCSI SAS, iSCSI, or Fibre Channel.
Be visible to all servers in the cluster.
Be accessed through a host bus adapter that supports clustering.
Not be a boot volume or system volume.
Not be used for paging files, hibernation, or dump files. Dump files record the contents of memory when the system stops unexpectedly.
Validate Disk Access Latency

This test validates that the latency for disk read and write operations is within an acceptable limit for a failover cluster. If disk read and write operations take too long,
one possible result is that cluster timeouts might be triggered. Another possible result is that the application attempting to access the disk might appear to have failed,
and the cluster might initiate a needless failover.

This test validates that:
Each of the clustered servers can use the arbitration process to become the owner of each of the cluster disks.
When a particular server owns a disk, if one or more other servers arbitrate for that disk, the original owner retains ownership.
If a clustered server cannot become the owner of a disk, or it cannot retain ownership when other clustered servers arbitrate for the disk, various issues might result:
The disk could have no owner and therefore be unavailable.
Two owners could write to the disk in an uncoordinated way, causing the disk to become corrupted.
Failover cluster servers are designed to coordinate all write operations in a way that avoids disk corruption.
The disk could change owners every time arbitration occurs, which would interfere with disk availability.

This test validates that disk failover works correctly in the cluster. Specifically, the test validates that when a disk owned by one clustered server is failed over, the server
that takes ownership of the disk can read it. The test also validates that information written to the disk before the failover is still the same after the failover.
If disk failover occurs but the server that takes ownership of a disk cannot read it, the cluster cannot maintain availability of the disk. If information written to the disk is
changed during the process of failover, it could cause issues for users or software that require this information. In either case, if the affected disk is a disk witness a disk
that stores cluster configuration data and participates in quorum, such issues could cause the cluster to lose quorum and shut down.
If this test reveals that disk failover does not work correctly, the results of the following tests might help you identify the cause of the issue:
Validate File System

This test validates that the file system on disks in shared storage is supported by failover clusters.
Validate Microsoft MPIOBased Disks

This test validates that multipath disks Microsoft MPIObased disks have been configured correctly for failover cluster.

This test validates that when multiple clustered servers arbitrate for a cluster disk, only one server obtains ownership. The process of disk arbitration helps ensure that
clustered servers perform all write operations in a coordinated way, avoiding disk corruption.
If this test reveals that multiple clustered servers can obtain ownership of a cluster disk through disk arbitration, the results of the following test might help you identify
the cause of the issue:
Validate SCSI Device Vital Product Data VPD

This test validates that the storage supports necessary SCSI inquiry data VPD descriptors and that they are unique.

This test validates that the cluster storage uses the more recent SCSI3 standard Persistent Reserve commands which are different from the older SCSI2 standard
reserve/release commands. The Persistent Reserve commands avoid SCSI bus resets, which means they are much less disruptive than the older reserve/release
commands. Therefore, a failover cluster can be more responsive in a variety of situations, as compared to a cluster running an earlier version of the operating system. In
addition, disks are never left in an unprotected state, which lowers the risk of volume corruption.
Validate Simultaneous Failover

This test validates that simultaneous disk failovers work correctly in the cluster. Specifically, the test validates that even when multiple disk failovers occur at the same
time, any clustered server that takes ownership of a disk can read it. The test also validates that information written to each disk before a failover is still the same after
the failover.
If disk failover occurs but the server that takes ownership of a disk cannot read it, the cluster cannot maintain availability of the disk. If information written to the disk is
changed during the process of failover, it could cause issues for users or software that require this information. In either case, if the affected disk is a disk witness a disk
that stores cluster configuration data and participates in quorum, such issues could cause the cluster to lose quorum and shut down.
If this test reveals that disk failover does not work correctly, the results of the following tests might help you identify the cause of the issue:
2015 Microsoft
Understanding Cluster Validation Tests: System Configuration

System configuration tests analyze the selected servers to determine whether they are properly configured for working together in a failover cluster. The system
configuration tests include the following:
Validate Active Directory Configuration: This test validates that each tested server is in the same domain and organizational unit. It also validates that all
tested servers are domain controllers or that all are member servers. To change the domain role of a server, use the Active Directory Domain Services
Installation Wizard.
Validate All Drivers Signed: This test validates that all tested servers contain only signed drivers. If an unsigned driver is detected, the test is not considered a
failure, but a warning is issued.
The purpose of signing drivers is to tell you whether the drivers on your system are original, unaltered files that either came with the operating system or were
supplied by a vendor.
You can get a list of system drivers and a list of unsigned drivers by running the corresponding inventory tasks. For more information, see Understanding Cluster
Validation Tests: Inventory.
Validate Cluster Service and Driver Settings: This test validates the startup settings used by services and drivers, such as the Cluster service, NetFT.sys, and
Clusdisk.sys.
Validate Memory Dump Settings: This test validates that none of the nodes currently requires a reboot as part of a software update and that each node is
configured to capture a memory dump if it stops running.
Validate Operating System Installation Option: This test validates that the operating systems on the servers use the same installation option full installation
or Server Core installation.
Validate Required Services: This test validates that the services that are required for failover clustering are running on each tested server and are configured to
start automatically whenever the server is restarted.
Validate Same Processor Architecture: This test validates that all tested servers have the same architecture. A failover cluster is supported only if the systems in
it are all x64based or all Itanium architecturebased.
Validate Service Pack Levels: This test validates that all tested servers have the same service packs. A failover cluster can run even if some servers have different
service packs than others. However, servers with different service packs might behave differently from each other, with unexpected results. We recommend that
all servers in the failover cluster have the same service packs.
Validate Software Update Levels: This test validates that all tested servers have the same software updates. A failover cluster can run even if some servers have
different updates than others. However, servers with different software updates might behave differently from each other, with unexpected results. We
recommend that all servers in the failover cluster have the same software update levels.
Validate System Drive Variable: This test validates that all nodes use the same letter for the system drive environment variable.
2015 Microsoft

Before running the Validate a Configuration Wizard for a failover cluster, you should make preparations such as connecting the networks and storage needed by the
cluster. This topic briefly describes these preparations. For a full list of the requirements for a failover cluster, see Understanding Requirements for Failover Clusters.
In most cases, membership in the local Administrators group on each server, or equivalent, is the minimum required to complete this procedure. This is because the
procedure includes steps for configuring networks and storage. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
To prepare hardware before validating a failover cluster
1. Confirm that your entire cluster solution, including drivers, is compatible with Windows Server2008R2 by checking the hardware compatibility information on
the Microsoft Web site http://go.microsoft.com/fwlink/?LinkId=139145.
Important
Microsoft supports a failover cluster solution only if all the hardware components are marked as "Certified for Windows Server 2008 R2." In addition, the
complete configuration servers, network, and storage must pass all tests in the Validate a Configuration Wizard, which is included in the Failover Cluster
Manager snapin.
We recommend that you use a set of matching computers that contain the same or similar components.
2. For the cluster networks:
a. Review the details about networks in Understanding Requirements for Failover Clusters.
b. Connect and configure the networks that the servers in the cluster will use.
Note
One option for configuring cluster networks is to create a preliminary network configuration, then run the Validate a Configuration Wizard with only
the Network tests selected avoid selecting Storage tests. When only the Network tests are run, the process does not take a long time. Using the
validation report, you can make any corrections still needed in the network configuration. Later, after the storage is configured, you should run the
wizard with all tests.
3. For the storage:
a. Review the details about storage in Understanding Requirements for Failover Clusters.
b. Follow the manufacturer's instructions for physically connecting the servers to the storage.
4. Ensure that the disks LUNs that you want to use in the cluster are exposed to the servers you will cluster and only those servers. You can use any of the
following interfaces to expose disks or LUNs:
Microsoft Storage Manager for SANs part of the operating system in Windows Server2008R2. To use this interface, you need to contact the
manufacturer of your storage for a Virtual Disk Service VDS provider package that is designed for your storage.
If you are using iSCSI, an appropriate iSCSI interface.
The interface provided by the manufacturer of the storage.
5. If you have purchased software that controls the format or function of the disk, obtain instructions from the vendor about how to use that software with
Windows Server2008R2.
6. On one of the servers that you want to cluster, click Start, click Administrative Tools, click Computer Management, and then click Disk Management. If the
User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes. In Disk Management, confirm that the cluster
disks are visible.
7. If you want to have a storage volume larger than 2 terabytes, and you are using the Windows interface to control the format of the disk, convert that disk now to
the partition style called GUID partition table GPT. To do this, back up any data on the disk, delete all volumes on the disk and then, in Disk Management, right
click the disk not a partition and click Convert to GPT Disk.
For volumes smaller than 2 terabytes, instead of using GPT, you can use the partition style called master boot record MBR.
Important
You can use either MBR or GPT for a disk used by a failover cluster, but you cannot use a disk that you converted to dynamic by using Disk Management.
8. Check the format of any exposed volume or LUN. We recommend NTFS for the format for the disk witness or for Cluster Shared Volumes, you must use NTFS.
9. As appropriate, make sure that there is connectivity from the servers to be clustered to any nonclustered domain controllers. Connectivity to clients is not
necessary for validation, and it can be established later.
2015 Microsoft
Validate a New or Existing Failover Cluster

Before creating a failover cluster, we recommend that you validate your hardware servers, networks, and storage by running the Validate a Configuration Wizard. You
can validate either an existing cluster or one or more servers that are not yet clustered.
Important
Note
If you want to run tests on a cluster with Cluster Shared Volumes that are currently online, use the instructions in Use Validation Tests for Troubleshooting a Failover
Cluster.
To validate a new or existing failover cluster
1. Identify the server or servers that you want to test and confirm that the Failover Clustering feature is installed:
If the cluster does not yet exist, choose the servers that you want to include in the cluster, and make sure you have installed the Failover Clustering feature
on those servers. For more information, see Install the Failover Clustering Feature.
Note that when you run the Validate a Configuration Wizard on unclustered servers, you must enter the names of all the servers you want to test, not just
one.
If the cluster already exists, make sure you know the name of the cluster or a node in the cluster.
2. Review network or storage hardware that you want to validate, to confirm that it is connected to the servers. For details, see Prepare Hardware Before Validating
a Failover Cluster and Understanding Requirements for Failover Clusters.
3. Decide whether you want to run all or only some of the available validation tests. For detailed information about the tests, see the topics listed in Understanding
Cluster Validation Tests.
The following guidelines can help you decide whether to run all tests:
For a planned cluster with all hardware connected: Run all tests.
For a planned cluster with parts of the hardware connected: Run System Configuration tests, Inventory tests, and tests that apply to the hardware that
is connected that is, Network tests if the network is connected or Storage tests if the storage is connected.
For a cluster to which you plan to add a server: Run all tests. When you run them, be sure to include all servers that you plan to have in the cluster.
For troubleshooting an existing cluster: If you are troubleshooting an existing cluster, you might run all tests, although you could run only the tests that
relate to the apparent issue.
Note
If you are troubleshooting an existing cluster that uses Cluster Shared Volumes, see Use Validation Tests for Troubleshooting a Failover Cluster.
4. In the Failover Cluster Manager snapin, in the console tree, make sure Failover Cluster Manager is selected and then, under Management, click Validate a
Configuration.
5. Follow the instructions in the wizard to specify the servers and the tests, run the tests, and view the results.
Note that when you run the Validate a Configuration Wizard on unclustered servers, you must enter the names of all the servers you want to test, not just one.
Additional considerations
To open the failover cluster snapin, click Start, click Administrative Tools, and then click Failover Cluster Manager. If the User Account Control dialog box
appears, confirm that the action it displays is what you want, and then click Yes.
To view the results of the tests after you close the wizard, choose one of the following:
Open the folder systemroot\Cluster\Reports on a clustered server.
If the tested servers are now a cluster, in the console tree, rightclick the cluster, and then click View Validation Report. This displays the most recent
validation report for that cluster.
Understanding the Process of Migrating to a Cluster Running Windows Server 2008 R2
2015 Microsoft

Before you can configure the cluster for the first time or add a server node to an existing failover cluster, you need to take the following preparatory steps:
Install the Failover Clustering feature: You must install the Failover Clustering feature on any server that will become a server node in the cluster. For more
information, see Install the Failover Clustering Feature.
Connect networks and storage: You must connect the networks and storage that the nodes will use. For details, see:
Understanding Requirements for Failover Clusters.
Validate the hardware configuration: We strongly recommend that you validate your hardware configuration servers, network, and storage before creating a
cluster or adding a node to a cluster. To validate, you run a wizard. For more information, see Validate a New or Existing Failover Cluster.
Important
Microsoft supports a failover cluster solution only if the complete configuration servers, network, and storage can pass all tests in the Validate a
Configuration Wizard. In addition, all hardware components in the solution must be marked as "Certified for Windows Server 2008 R2."
To see the preceding steps in the context of a checklist, see Checklist: Create a Failover Cluster.
The following topics describe how to create a failover cluster or add a server node to a failover cluster:
Understanding Access Points Names and IP Addresses in a Failover Cluster
Create a New Failover Cluster
Add a Server to a Failover Cluster
2015 Microsoft
Understanding Access Points (Names and IP Addresses) in a

Failover Cluster
An access point is a name and associated IP address information. You use an access point to administer a failover cluster or to communicate with a service or
application in the cluster. One access point can include one or more IP addresses, which can be IPv6 addresses, IPv4 addresses supplied through DHCP, or static IPv4
addresses.
When selecting a network to be used for an access point, avoid any network that is used for iSCSI. Configure networks used for iSCSI so that they are not used for
network communication in the cluster.
Understanding Cluster Validation Tests: Network
Modify Network Settings for a Failover Cluster
2015 Microsoft
Create a New Failover Cluster

Updated: July 15, 2010
Before you create a cluster, you must carry out tasks such as connecting the hardware and validating the hardware configuration. For a list of these tasks, see Checklist:
Create a Failover Cluster.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, if your account is not a Domain
Admins account, either the account or the group that the account is a member of must be delegated the Create Computer Objects and Read All Properties
permissions in the domain. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To create a new failover cluster

1. Confirm that you have connected the hardware and validated the hardware configuration, as described in the following topics:
Validate a New or Existing Failover Cluster.
Important
2. In the Failover Cluster Manager snapin, confirm that Failover Cluster Manager is selected and then, under Management, click Create a Cluster.
3. Follow the instructions in the wizard to specify:
The servers to include in the cluster.
The name of the cluster.
Any IP address information that is not automatically supplied by your DHCP settings.
4. After the wizard runs and the Summary page appears, if you want to view a report of the tasks that the wizard performed, click View Report.
To view the report after you close the wizard, see the following folder, where SystemRoot is the location of the operating system for example, C:\Windows:
SystemRoot\Cluster\Reports\
You can also perform the task described in this procedure by using Windows PowerShell. For more information about using Windows PowerShell for failover
2015 Microsoft
Add a Server to a Failover Cluster

Before you add a server node to a failover cluster, we strongly recommend that you run the Validate a Configuration Wizard for the existing cluster nodes and the new
node or nodes. The Validate a Configuration Wizard helps you confirm the configuration in a variety of important ways. For example, it validates that the server to be
added is connected correctly to the networks and storage and that it contains the same software updates.
Important
For more information about validation, see Validate a New or Existing Failover Cluster.
To add a server to a failover cluster
1. Confirm that you have connected the networks and storage to the server you want to add. For details about the requirements for networking and storage, see
Prepare Hardware Before Validating a Failover Cluster.
2. Validate the hardware configuration, including both the existing cluster nodes and the proposed new node. For information about validation, see Validate a New
or Existing Failover Cluster.
Important
3. In the Failover Cluster Manager snapin, if the cluster that you want to configure is not displayed, in the console tree, rightclick Failover Cluster Manager, click
Manage a Cluster, and then select or specify the cluster that you want.
4. Select the cluster, and then in the Actions pane, click Add Node.
5. Follow the instructions in the wizard to specify the server to add to the cluster.
6. After the wizard runs and the Summary page appears, if you want to view a report of the tasks the wizard performed, click View Report.
To view the report after you close the wizard, see the following folder, where SystemRoot is the location of the operating system for example, C:\Windows:
SystemRoot \Cluster\Reports\
2015 Microsoft

This topic provides an overview of the task of configuring specific services or applications for failover clustering by using the High Availability Wizard. Instructions for
running the wizard are provided in Configure a Service or Application for High Availability.
Important
If you want to cluster a mail server or database server application, see the application's documentation for information about the correct way to install it in a cluster
environment. Mail server and database server applications are complex, and they might require configuration steps that fall outside the scope of this failover
clustering Help.
This topic contains the following sections:
Applications and services listed in the High Availability Wizard
List of topics about configuring a service or application for high availability
Applications and services listed in the High Availability Wizard

A variety of services and applications can work as "clusteraware" applications, functioning in a coordinated way with cluster components.
Note
When configuring a service or application that is not clusteraware, you can use generic options in the High Availability Wizard: Generic Service, Generic Application,
or Generic Script. For information about using these options, see Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster.
In the High Availability Wizard, you can choose from the generic options described in the previous note, or you can choose from the following services and applications:
DFS Namespace Server: Provides a virtual view of shared folders in an organization. When a user views the namespace, the folders appear to reside on a single
hard disk. Users can navigate the namespace without needing to know the server names or shared folders that are hosting the data.
DHCP Server: Automatically provides client computers and other TCP/IPbased network devices with valid IP addresses.
Distributed Transaction Coordinator DTC: Supports distributed applications that perform transactions. A transaction is a set of related tasks, such as updates
to databases, that either succeed or fail as a unit.
File Server: Provides a central location on your network where you can store and share files with users.
Internet Storage Name Service iSNS Server: Provides a directory of iSCSI targets.
Message Queuing: Enables distributed applications that are running at different times to communicate across heterogeneous networks and with computers that
may be offline.
Other Server: Provides a client access point and storage only. Add an application after completing the wizard.
Print Server: Manages a queue of print jobs for a shared printer.
Remote Desktop Connection Broker formerly TS Session Broker: Supports session load balancing and session reconnection in a loadbalanced remote
desktop server farm. RD Connection Broker is also used to provide users access to RemoteApp programs and virtual desktops through RemoteApp and Desktop
Connection.
Virtual Machine: Runs on a physical computer as a virtualized computer system. Multiple virtual machines can run on one computer.
WINS Server: Enables users to access resources by a NetBIOS name instead of requiring them to use IP addresses that are difficult to recognize and remember.
List of topics about configuring a service or application for high availability

The following topics describe the process of configuring a service or application for high availability in a failover cluster:
Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster
Understanding HyperV and Virtual Machines in the Context of a Cluster
Configure a Service or Application for High Availability
Test the Failover of a Clustered Service or Application
Test the Failover of a Clustered Virtual Machine
Modifying the Settings for a Clustered Service or Application
2015 Microsoft
Understanding Generic Services and Applications that Can Be

Configured in a Failover Cluster
You can configure a variety of different services or applications for high availability in a failover cluster. For a list of the services or applications most commonly
configured for high availability, see Configuring a Service or Application for High Availability.
Services or applications that can be run as a Generic Application, Generic Script, or Generic Service
Basic requirements for a service or application in a failover cluster environment
Services or applications that can be run as a Generic Application, Generic Script, or Generic Service
In failover clusters, you can use the Generic Application, Generic Script, and Generic Service options to configure high availability for some services and applications that
are not "clusteraware" not originally designed to run in a cluster.
Generic Application
If you run an application as a Generic Application, the cluster software will start the application, then periodically query the operating system to see whether the
application appears to be running. If so, it is presumed to be online, and will not be restarted or failed over.
Note that in comparison with a clusteraware application, a Generic Application has fewer ways of communicating its precise state to the cluster software. If a Generic
Application enters a problematic state but nonetheless appears to be running, the cluster software does not have a way of discovering this and taking an action such as
restarting the application or failing it over.
Before running the High Availability Wizard to configure high availability for a Generic Application, make sure that you know the path of the application and the names
of any registry keys under HKEY_LOCAL _MACHINE that are required by the application.
Generic Script
You can create a script that runs in Windows Script Host and that monitors and controls your application. Then you can configure the script as a Generic Script in the
cluster. The script provides the cluster software with information about the current state of the application. As needed, the cluster software will restart or fail over the
script and through it, the application will be restarted or failed over.
When you configure a Generic Script in a failover cluster, the ability of the cluster software to respond with precision to the state of the application is determined by the
script. The more precise the script is in providing information about the state of the application, the more precise the cluster software can be in responding to that
information.
Before running the High Availability Wizard to configure high availability for a Generic Script, make sure that you know the path of the script.
Generic Service
The cluster software will start the service, then periodically query the Service Controller a feature of the operating system to determine whether the service appears to
be running. If so, it is presumed to be online, and will not be restarted or failed over.
Note that in comparison with a clusteraware service, a Generic Service has fewer ways of communicating its precise state to the cluster software. If a Generic Service
enters a problematic state but nonetheless appears to be running, the cluster software does not have a way of discovering this and taking an action such as restarting
the service or failing it over.
Before running the High Availability Wizard to configure high availability for a Generic Service, make sure that you know the name of the service as it appears in the
registry under HKEY_LOCAL _MACHINE\System\CurrentControlSet\Services.
Basic requirements for a service or application in a failover cluster environment

To be appropriate for a failover cluster, a service or application must have certain characteristics. The most important characteristics include:
The service or application should be stateful. In other words, the service or application should have longrunning inmemory state or large, frequently
updated data states. One example is a database application. For a stateless application such as a Web server front end, Network Load Balancing will probably
be more appropriate than failover clustering.
The service or application should use a client component that automatically retries after temporary network interruptions. Otherwise, if the server
component of the application fails over from one clustered server to another, the unavoidable but brief interruption will cause the clients to stop, rather than
simply retrying and reconnecting.
The service or application should be able to identify the disk or disks it uses. This makes it possible for the service or application to communicate with disks
in the cluster storage, and to reliably find the correct disk even after a failover.
The service or application should use IPbased protocols. Examples include TCP, UDP, DCOM, named pipes, and RPC over TCP/IP.
2015 Microsoft
Understanding Hyper-V and Virtual Machines in the Context of

a Cluster
Updated: February 11, 2010
This topic provides information about the following:
Overview of HyperV in the context of a failover cluster
Using Cluster Shared Volumes with HyperV
Live migration, quick migration, and moving of virtual machines
Coordinating the use of HyperV Manager with the use of Failover Cluster Manager
Overview of HyperV in the context of a failover cluster

The HyperV role in Server Manager enables you to create a virtualized server computing environment in which you can create and manage virtual machines that run
operating systems, applications, and services. Failover clusters are used to increase the availability of such applications and services. HyperV and failover clustering can
be used together to make a virtual machine that is highly available, thereby minimizing disruptions and interruptions to clients.
You can cluster a virtual machine and you can cluster a service or application that happens to be running in a virtual machine. If you cluster a virtual machine, the cluster
monitors the health of the virtual machine itself and will respond to failures by restarting the virtual machine or failing it over. If you cluster a service or application
that happens to be running in a virtual machine, the cluster monitors the health of the service or application and will respond to failures by restarting the application or
failing it over.
A feature of failover clusters called Cluster Shared Volumes is specifically designed to enhance the availability and manageability of virtual machines.
Using Cluster Shared Volumes with HyperV

Cluster Shared Volumes are volumes in a failover cluster that multiple nodes can read from and write to at the same time. The Cluster Shared Volumes feature is only
supported for use with HyperV a server role in Windows Server2008R2 and other technologies specified by Microsoft. For more information about Cluster Shared
Volumes, see the following topics:
Using Cluster Shared Volumes in a Failover Cluster in Windows Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=182152
Cluster Shared Volumes Support for HyperV http://go.microsoft.com/fwlink/?LinkId=137158
Live migration, quick migration, and moving of virtual machines

With failover clusters, a virtual machine can be moved from one cluster node to another in several different ways: live migration, quick migration, and moving. This
section describes these actions. For information about how to perform the actions, see Live Migrate, Quick Migrate, or Move a Virtual Machine from Node to Node.
Note
If you want to cluster virtual machines and use live migration or quick migration, we recommend making the hardware and system settings on the nodes as similar
as possible to minimize potential problems.
The following list describes the choices:
Live migration: When you initiate live migration, the cluster copies the memory being used by the virtual machine from the current node to another node, so that
when the transition to the other node actually takes place, the memory and state information is already in place for the virtual machine. The transition is usually fast
enough that a client using the virtual machine does not lose the network connection. If you are using Cluster Shared Volumes, live migration is almost instantaneous,
because no transfer of disk ownership is needed. A live migration can be used for planned maintenance but not for an unplanned failover.
Note
You cannot use live migration to move multiple virtual machines simultaneously. On a given server running HyperV, only one live migration to or from the server
can be in progress at a given time.
Quick migration: When you initiate quick migration, the cluster copies the memory being used by the virtual machine to a disk in storage, so that when the transition
to another node actually takes place, the memory and state information needed by the virtual machine can quickly be read from the disk by the node that is taking over
ownership. A quick migration can be used for planned maintenance but not for an unplanned failover.
You can use quick migration to move multiple virtual machines simultaneously.
Moving: When you initiate a move, the cluster prepares to take the virtual machine offline by performing an action that you have specified in the cluster configuration
for the virtual machine resource: Save, Shut down, Shut down forced, or Turn off. Save the default saves the state of the virtual machine, so that the state can be
restored when bringing the virtual machine back online. Shut down performs an orderly shutdown of the operating system waiting for all processes to close on the
virtual machine before taking the virtual machine offline. Shut down forced shuts down the operating system on the virtual machine without waiting for slower
processes to finish, and then takes the virtual machine offline. Turn off is like turning off the power to the virtual machine, which means that data loss may occur.
The setting you specify for the offline action does not affect live migration, quick migration, or unplanned failover. It affects only moving or taking the resource offline
through the action of Windows PowerShell or an application. To specify this setting, see the "Additional considerations" section in Live Migrate, Quick Migrate, or Move
a Virtual Machine from Node to Node.
Coordinating the use of HyperV Manager with the use of Failover Cluster Manager
After you configure clustered virtual machines, you can modify most settings of those clustered virtual machines using either HyperV Manager or Failover Cluster
Manager. We recommend that you use Failover Cluster Manager for modifying those settings, as described in Modify the Virtual Machine Settings for a Clustered
Virtual Machine. If you decide to use HyperV Manager to modify virtual machine settings, be sure to open Failover Cluster Manager and refresh the virtual machine
configuration, as described in Refresh the Configuration of a Virtual Machine.
Cluster Shared Volumes Support for HyperV http://go.microsoft.com/fwlink/?LinkId=137158
Live Migrate, Quick Migrate, or Move a Virtual Machine from Node to Node
2015 Microsoft

You can configure a service or application for high availability by running a wizard that creates the appropriate settings in a failover cluster. For information about the
services and applications that you can configure in a failover cluster, see:
Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster.
If you are configuring a clustered file server or a clustered print server, review one of the following:
Checklist: Create a Clustered Print Server.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, if your account is not a Domain
Admins account, either the account or the group that the account is a member of must be delegated the Create Computer Objects permission in the domain. Review
details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To configure a service or application for high availability
2. If the console tree is collapsed, expand the tree under the cluster that you want to configure.
3. Click Services and Applications and then, under Actions on the right, click Configure a Service or Application.
4. Follow the instructions in the wizard to specify the service or application that you want to configure for high availability, along with the following details:
A name for the clustered service or application. This name will be registered in DNS and associated with the IP address for this clustered service or
application.
Any IP address information that is not automatically supplied by your DHCP settingsfor example, a static IPv4 address for this clustered service or
application.
The storage volume or volumes that the clustered service or application should use.
Specific information for the service or application that you are configuring. For example, for a Generic Application, you must specify the path for the
application and any registry keys that the application requires so that the registry keys can be replicated to all nodes in the cluster.
If you are configuring a clustered file server or a clustered print server, see the following "Additional considerations" section.
If this is the first service or application that you are configuring for high availability, it might be appropriate to review your cluster network settings now. If the
clustered servers are connected to a network that is not to be used for network communication in the cluster for example, a network that is intended only for
iSCSI or only for backup, then under Networks, rightclick that network, click Properties, and then select Do not allow the cluster to use this network.
If you are configuring a clustered file server, review Checklist: Create a Clustered File Server.
If you are configuring a clustered print server, review Checklist: Create a Clustered Print Server.
For information about modifying the settings for this service or application after the wizard finishes running, see Modifying the Settings for a Clustered Service or
Application.
Understanding Generic Services and Applications that Can Be Configured in a Failover Cluster
2015 Microsoft

In a failover cluster, you can create configure a virtual machine for high availability by running a wizard that creates the appropriate settings.
To work with virtual machines, you might want to view Help content for the HyperV Manager snapin. To view this content, install the HyperV role through Server
Manager and the Add Roles Wizard, open HyperV Manager through Server Manager or in a separate snapin console, and press F1. You can also view information
about HyperV on the Web, for example, information about creating a virtual machine http://go.microsoft.com/fwlink/?LinkId=137805.
Membership in the local Administrators group on each clustered server, or equivalent, is the minimum required to complete this procedure. Also, the account you use
must be a domain account. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To configure a virtual machine for high availability
1. Be sure that you have installed the HyperV role and have reviewed the steps in Checklist: Create a Clustered Virtual Machine. This procedure is a step in that
checklist.
4. Click Services and Applications.
5. If you have already created the virtual machine, skip to step 6. Otherwise, use the New Virtual Machine Wizard to create a virtual machine and configure it for
high availability:
a. In the Action pane, click Virtual machines, point to Virtual machine, and then click a node.
The virtual machine will initially be created on that node, and then be clustered so that it can move to another node or nodes as needed.
b. If the Before You Begin page of the New Virtual Machine Wizard appears, click Next.
c. Specify a name for the virtual machine, and then select Store the virtual machine in a different location and specify a disk in shared storage or, if
Cluster Shared Volumes is enabled, a Cluster Shared Volume a volume that appears to be on the system drive of the node, under the \ClusterStorage
folder.
d. Follow the instructions in the wizard. You can specify details such as the amount of memory, the network, and the virtual hard disk file now, and you can
also add or change configuration details later.
e. When you click Finish, the wizard creates the virtual machine and also configures it for high availability. Skip the remaining step in this procedure.
6. If you have already created the virtual machine and only want to configure it for high availability, first make sure that the virtual machine is not running. Then,
use the High Availability Wizard to configure the virtual machine for high availability:
a. In the Action pane, click Configure a Service or Application.
b. If the Before You Begin page of the High Availability Wizard appears, click Next.
c. On the Select Service or Application page, click Virtual Machine and then click Next.
d. Select the virtual machine that you want to configure for high availability, and complete the wizard.
e. After the High Availability wizard runs and the Summary page appears, if you want to view a report of the tasks that the wizard performed, click View
Report.
If you decide to change the settings of a clustered virtual machine, be sure to see Modify the Virtual Machine Settings for a Clustered Virtual Machine.
For each clustered virtual machine, you can also specify the action that the cluster performs before taking the virtual machine offline. Taking the virtual machine
offline is necessary when moving the virtual machine but not necessary for live migration or quick migration. To specify the setting, make sure that after
selecting the clustered virtual machine in the console tree on the left, you rightclick the virtual machine resource displayed in the center pane not on the left,
and then click Properties. Click the Settings tab and select an option. The actions are described in Understanding HyperV and Virtual Machines in the Context
of a Cluster in the section called "Live migration, quick migration, and moving of virtual machines," in the description about the moving of virtual machines.
If this is the first virtual machine that you are configuring for high availability, it might be appropriate to review your cluster network settings now. If the clustered
servers are connected to a network that is not to be used for network communication in the cluster for example, a network that is intended only for iSCSI or only
for backup, then under Networks, rightclick that network, click Properties, and then select Do not allow the cluster to use this network.
Modify the Virtual Machine Settings for a Clustered Virtual Machine
2015 Microsoft
Test the Failover of a Clustered Service or Application

You can perform a basic test to confirm that a clustered service or application can fail over successfully to another node. For information about performing a similar test
for a clustered virtual machine, see Test the Failover of a Clustered Virtual Machine.
This procedure is one of the steps in the following checklists:
To test the failover of a clustered service or application
3. Expand Services and Applications, and then click the service or application for which you want to test failover.
4. Under Actions on the right, click Move this service or application to another node.
As the service or application moves, the status is displayed in the results pane center pane.
5. Optionally, repeat step 4 to move the service or application to an additional node or back to the original node.
2015 Microsoft
Test the Failover of a Clustered Virtual Machine

You can perform a basic test to confirm that a clustered virtual machine can fail over successfully to another node. For information about performing a similar test for a
clustered service or application, see Test the Failover of a Clustered Service or Application.
This procedure is one of the steps in the following checklist:
To test the failover of a clustered virtual machine
3. Expand Virtual Machine, and then click the virtual machine for which you want to test failover.
4. Under Actions on the right, click Move virtual machines to another node.
As the virtual machine moves, the status is displayed in the results pane center pane.
5. Optionally, repeat step 4 to move the virtual machine to an additional node or back to the original node.
2015 Microsoft

This topic describes failover and failback settings for a clustered service or application. It also provides links to information about other settings that you can modify for
a clustered service or application.
Modifying failover and failback settings, including preferred owners
List of topics about modifying settings
Modifying failover and failback settings, including preferred owners

You can adjust the failover settings, including preferred owners and failback settings, to control how the cluster responds when the application or service fails. You can
configure these settings on the property sheet for the clustered service or application on the General tab or the Failover tab. The following table provides examples
that illustrate how these settings work.
Settings Effect
Example 1: If the service or application fails over from Node1 to Node2, when Node1 is again available, the service or application will fail back to
Node1.
General tab, Preferred
owner: Node1
Failover tab,Failback
setting: Allow failback
Immediately
Example 2: In a sixhour period, if the application or service fails no more than twice, it will be restarted or failed over each time. If the application
or service fails a third time in the sixhour period, it will be left in the failed state.
Failover tab, Maximum
failures in the specified The default value for the maximum number of failures is n1, where n is the number of nodes. You can change the value, but we
period: 2 recommend a relatively low value, so that if multiple node failures occur, the application or service will not be moved between nodes
indefinitely.
Failover tab, Period
hours: 6
List of topics about modifying settings

The following topics provide details about settings that you can modify for a clustered service or application:
Add Storage for a Clustered Service or Application For information about adding a disk to the cluster itself, so that the disk is available for adding to a clustered
service or application, see Add Storage to a Failover Cluster.
Add a Resource to a Clustered Service or Application
Create a Shared Folder in a Clustered File Server
Configure the Print Settings for a Clustered Print Server
2015 Microsoft
Add Storage for a Clustered Service or Application

You can add storage to an existing clustered service or application. However, if the storage has not already been added to the failover cluster itself, you must first add
the storage to the cluster before you can add the storage to a clustered service or application within the cluster. For information about adding storage to a cluster, see
Add Storage to a Failover Cluster.
To add storage for a clustered service or application
3. Expand Services and Applications, and then click the service or application that you want to add storage to.
4. Under Actions on the right, click Add storage.
5. Select the disk or disks that you want to add.

If a disk does not appear in the list, it might not have been added to the cluster yet. For more information, see Add Storage to a Failover Cluster.
Add Storage to a Failover Cluster
Understanding Cluster Validation Tests: Storage
2015 Microsoft
Add a Resource to a Clustered Service or Application

To customize the way your clustered service or application works, you can add a resource.
Important
This procedure is designed for use by administrators who are familiar with the way clustered resources and resource groups are configured in Windows Server2003.
Unless you have this familiarity, do not use this procedure, but instead follow the steps in Configure a Service or Application for High Availability, which tells how to
run the High Availability Wizard. When you run the wizard and choose a role or service such as File Server or Print Server, the wizard creates the appropriate
resources for a clustered instance of that role or service.
If you want to cluster a mail server or database server application, see the application's documentation for information about the correct way to install and configure
it in a cluster environment. Mail server and database server applications are complex, and therefore might require configuration steps that fall outside the scope of
this failover clustering Help.
To add a resource to a clustered service or application
1. Ensure that the software or feature that is needed for the resource is installed on all nodes in the cluster.
4. Expand Services and Applications, and then click the service or application that you want to add a resource to.
5. Under Actions on the right, click Add a resource.
6. Click the resource that you want to add, or click More resources and then click the resource that you want to add. If a wizard appears for the resource you
chose, provide the information requested by the wizard.
7. In the center pane, rightclick the resource that you added and click Properties.
8. If the property sheet includes a Parameters tab, click the tab and then configure the parameters that are needed by the resource.
9. Click the Dependencies tab, and then configure the dependencies for the resource. Click OK.
10. In the console tree, select the service or application not the individual resource, and then under Actions on the right, click Show Dependency Report.
11. Review the dependencies between the resources. For many resources, you must configure the correct dependencies before the resource can be brought online.
If you need to change the dependencies, close the dependency report and then repeat step 9.
12. Rightclick the resource that you just added, and then click Bring this resource online.
2015 Microsoft
Modify the Failover Settings for a Clustered Service or

Application
You can adjust the failover, failback, or preferred owner settings to control the way the cluster responds when a particular application or service fails. For examples that
illustrate the way the settings work, see Modifying the Settings for a Clustered Service or Application.
To modify the failover settings for a clustered service or application
3. Expand Services and Applications.
4. Rightclick the service or application that you want to modify the failover settings for, and then click Properties.
5. To configure failback, on the General tab, change settings for preferred owners, then click the Failover tab and choose options under Failback.
You must configure a preferred owner if you want failback to occur that is, if you want a particular service or application to fail back to a particular node when
possible.
6. To configure the number of times that the cluster service should attempt to restart or fail over a service or application in a given time period, click the Failover
tab and specify values under Failover.
For more information about failover settings for a clustered service or application, see Modifying the Settings for a Clustered Service or Application.
2015 Microsoft
Modify the Virtual Machine Settings for a Clustered Virtual

Machine
When you change the settings of a clustered virtual machine, we recommend that you use Failover Cluster Manager instead of HyperV Manager, as described in this
procedure.
To modify the virtual machine settings for a clustered virtual machine
4. In the console tree, click the virtual machine that you want to modify the settings for.
5. In the center pane, rightclick the virtual machine resource and then click Settings. If you do not see Settings in the menu, collapse the virtual machine resource
and then rightclick it.
The Settings interface appears. This is the same interface that you see in HyperV Manager.
6. Configure the settings for the virtual machine.
If you use HyperV Manager instead of Failover Cluster Manager to configure settings for a virtual machine, be sure to follow the steps in Refresh the
Configuration of a Virtual Machine.
2015 Microsoft
Create a Shared Folder in a Clustered File Server

Before you perform this procedure, review the steps in Checklist: Create a Clustered File Server. This procedure describes a step in that checklist.
To create a shared folder in a clustered file server
1. In Control Panel, open Windows Firewall, click Allow a program or feature through Windows Firewall, click Change settings, select an exception for Remote
Volume Management, and then click OK.
4. Expand Services and Applications, and then select the clustered file server.
5. Under Actions, click Add a shared folder.
The Create a Shared Folder Wizard appears. This is the same wizard that you would use to share a folder on a nonclustered server.
6. Follow the instructions in the wizard to specify the settings for the shared folder, including path, name, offline settings, and permissions.
In a clustered file server, when you bring the associated File Server resource online or take it offline, all shared folders in that resource go offline or online at the
same time. You cannot change the online or offline status of one of the shared folders without affecting all of the shared folders.
2015 Microsoft
Configure the Print Settings for a Clustered Print Server

Before you perform this procedure, review the steps in Checklist: Create a Clustered Print Server. This procedure describes the last step in that checklist.
To configure the print settings for a clustered print server
4. Rightclick the clustered print server that you want to configure the print settings for, and then click Manage Printers.
An instance of the Failover Cluster Manager interface appears with Print Management in the console tree.
5. Under Print Management, click Print Servers and locate the clustered print server you want to configure.
Always perform management tasks on the clustered print server. Do not manage the individual cluster nodes as print servers.
6. Rightclick the clustered print server, and then click Add Printer. Follow the instructions in the wizard to add a printer.
This is the same wizard you would use to add a printer on a nonclustered server.
7. When you have finished configuring settings for the clustered print server, to close the instance of the Failover Cluster Manager interface with Print
Management in the console tree, click File and then click Exit.
The failover cluster software automatically replicates important files such as print drivers to each of the nodes in the cluster. It supports this replication process
by using a disk resource in the cluster storage as a place to store these files. This disk resource is configured automatically by the High Availability Wizard as
part of a new clustered print server. Do not delete the disk resource that is part of the clustered print server.
2015 Microsoft
Migrating to a Failover Cluster Running Windows Server 2008

R2
For information about migrating to a failover cluster running Windows Server2008R2, see Migrating Clustered Services and Applications to Windows Server 2008 R2
StepbyStep Guide http://go.microsoft.com/fwlink/?LinkId=182155.
2015 Microsoft
Understanding the Process of Migrating to a Cluster Running

Windows Server 2008 R2
You can use a wizard to migrate the settings of many types of resources to a cluster running Windows Server2008R2. The wizard supports migration to a cluster
running Windows Server2008R2 from a cluster running any of the following operating systems:
Windows Server2003
Windows Server2008
Windows Server2008R2
For information about which resource groups can be migrated by using the wizard and how to perform migrations not supported by the wizard, see Migration Paths for
Migrating to a Failover Cluster Running Windows Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=182156.
For a complete description of the steps for performing a migration, see topics in Migrating Clustered Services and Applications to Windows Server 2008 R2 Step
byStep Guide http://go.microsoft.com/fwlink/?LinkId=182155.
For a brief description of the Migrate a Cluster Wizard, see Migrate Resource Groups to a Failover Cluster Running Windows Server 2008 R2.
For design and deployment information including migration information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137832.
2015 Microsoft
Migrate Resource Groups to a Failover Cluster Running

Windows Server 2008 R2
You can use a wizard to migrate the settings of many types of resource groups clustered services and applications to a cluster running Windows Server2008R2. The
wizard supports migrations from clusters running Windows Server2003, Windows Server2008, or Windows Server2008R2.
Important
For information about which resource groups can be migrated by using the wizard and how to perform migrations not supported by the wizard, see Migration Paths
for Migrating to a Failover Cluster Running Windows Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=182156.
Before you start the wizard, be sure that you know the name or IP Address of the cluster or cluster node from which you want to migrate resource groups.
Caution
If new storage is used, you must handle all copying or moving of data or folders on your shared volumes during a migration. The wizard for migrating clustered
resource groups does not copy data from one location to another.
To migrate resource groups to a failover cluster running Windows Server 2008 R2
1. On the cluster running Windows Server2008R2, open the failover cluster snapin.
2. If the cluster to which you want to migrate is not displayed, in the console tree, rightclick Failover Cluster Manager, click Manage a Cluster, and then select or
specify the cluster that you want.
3. Under Configure, click Migrate Services and Applications.
4. Read the first page of the Migrate a Cluster Wizard, and then click Next.
5. Specify the name or IP Address of the cluster or cluster node from which you want to migrate resource groups, and then click Next.
6. Click View Report. Read the report, which explains whether each resource is eligible for migration.
The wizard also provides a report after it finishes, describing any additional steps that might be needed before you bring the migrated resource groups online.
7. Follow the instructions in the wizard to complete the following:
Choose the resource group or groups whose settings you want to migrate.
Some types of resource groups are eligible for migration and some are not. For more information, see Migration Paths for Migrating to a Failover Cluster
Running Windows Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=182156.
Specify whether the resource groups to be migrated will use new storage, or the same storage used in the old cluster. If the resource groups will use new
storage, you can specify the disk that each resource group should use after migration. Note that if new storage is used, you must handle all copying or
moving of data or foldersthe wizard does not copy data from one location to another.
8. After the wizard runs and the Summary page appears, click View Report. This report contains important information about any additional steps that might be
needed before you bring the migrated resource groups online.
For information about modifying the settings of a service or application after migration, see Modifying the Settings for a Clustered Service or Application.
Migrating Clustered Services and Applications to Windows Server 2008 R2 StepbyStep Guide http://go.microsoft.com/fwlink/?LinkId=182155
2015 Microsoft

The default settings that are created by wizards for failover clustering work well for many clusters. However, you can change a cluster's settingsfor example, add
storage, modify network settings, or enable Cluster Shared Volumes. The following topics provide information about changing the overall settings for your cluster:
Understanding Cluster Shared Volumes in a Failover Cluster
Understanding Quorum Configurations in a Failover Cluster
Enable Cluster Shared Volumes in a Failover Cluster
Select Quorum Options for a Failover Cluster
2015 Microsoft

To understand how Cluster Shared Volumes CSV works in a failover cluster, it is helpful to review how a cluster works without CSV. Without CSV, a failover cluster
allows a given disk LUN to be accessed by only one node at a time. Given this constraint, each HyperV virtual machine in the failover cluster requires its own set of
LUNs in order to be migrated or fail over independently of other virtual machines. In this type of deployment, the number of LUNs must increase with the addition of
each virtual machine, which makes management of LUNs and clustered virtual machines more complex.
In contrast, on a failover cluster that uses CSV, multiple virtual machines that are distributed across multiple cluster nodes can all access their Virtual Hard Disk VHD
files at the same time, even if the VHD files are on a single disk LUN in the storage. The clustered virtual machines can all fail over independently of one another.
This topic provides a basic description of Cluster Shared Volumes. For more detailed information, see Using Cluster Shared Volumes in a Failover Cluster in Windows
Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=182152.
Benefits of using Cluster Shared Volumes in a failover cluster

Cluster Shared Volumes provides the following benefits in a failover cluster:
The configuration of clustered virtual machines is much simpler than before.
You can reduce the number of LUNs disks required for your virtual machines, instead of having to manage one LUN per virtual machine, which was previously
the recommended configuration because the LUN was the unit of failover. Many virtual machines can use a single LUN and can fail over without causing the
other virtual machines on the same LUN to also fail over.
You can make better use of disk space, because you do not need to place each Virtual Hard Disk VHD file on a separate disk with extra free space set aside just
for that VHD file. Instead, the free space on a Cluster Shared Volume can be used by any VHD file on that volume.
You can more easily track the paths to VHD files and other files used by virtual machines. You can specify the path names, instead of identifying disks by drive
letters limited to the number of letters in the alphabet or identifiers called GUIDs which are hard to use and remember. With Cluster Shared Volumes, the path
appears to be on the system drive of the node, under the \ClusterStorage folder. However, this path is the same when viewed from any node in the cluster.
If you use a few Cluster Shared Volumes to create a configuration that supports many clustered virtual machines, you can perform validation more quickly than
you could with a configuration that uses many LUNs to support many clustered virtual machines. With fewer LUNs, validation runs more quickly. You perform
validation by running the Validate a Configuration Wizard in the snapin for failover clusters.
There are no special hardware requirements beyond what is already required for storage in a failover cluster although Cluster Shared Volumes require NTFS.
Resiliency is increased, because the cluster can respond correctly even if connectivity between one node and the SAN is interrupted, or part of a network is down.
The cluster will reroute the Cluster Shared Volumes communication through an intact part of the SAN or network.
Important
For detailed information about requirements and recommendations for using Cluster Shared Volumes, see Using Cluster Shared Volumes in a Failover Cluster
in Windows Server 2008 R2 http://go.microsoft.com/fwlink/?LinkId=182152.
Cluster Shared Volumes Support for HyperVCluster Shared Volumes Support for HyperV http://go.microsoft.com/fwlink/?LinkId=137158
2015 Microsoft

How the quorum configuration affects the cluster
Quorum configuration choices
Illustrations of quorum configurations
Why quorum is necessary
For information about how to configure quorum options, see Select Quorum Options for a Failover Cluster.
How the quorum configuration affects the cluster

The quorum configuration in a failover cluster determines the number of failures that the cluster can sustain. If an additional failure occurs, the cluster must stop
running. The relevant failures in this context are failures of nodes or, in some cases, of a disk witness which contains a copy of the cluster configuration or file share
witness. It is essential that the cluster stop running if too many failures occur or if there is a problem with communication between the cluster nodes. For a more
detailed explanation, see Why quorum is necessary later in this topic.
Important
In most situations, use the quorum configuration that the cluster software identifies as appropriate for your cluster. Change the quorum configuration only if you
have determined that the change is appropriate for your cluster.
Note that full function of a cluster depends not just on quorum, but on the capacity of each node to support the services and applications that fail over to that node.
For example, a cluster that has five nodes could still have quorum after two nodes fail, but the level of service provided by each remaining cluster node would depend
on the capacity of that node to support the services and applications that failed over to it.
Quorum configuration choices

You can choose from among four possible quorum configurations:
Node Majority recommended for clusters with an odd number of nodes
Can sustain failures of half the nodes rounding up minus one. For example, a seven node cluster can sustain three node failures.
Node and Disk Majority recommended for clusters with an even number of nodes
Can sustain failures of half the nodes rounding up if the disk witness remains online. For example, a six node cluster in which the disk witness is online could
sustain three node failures.
Can sustain failures of half the nodes rounding up minus one if the disk witness goes offline or fails. For example, a six node cluster with a failed disk witness
could sustain two 31=2 node failures.
Node and File Share Majority for clusters with special configurations
Works in a similar way to Node and Disk Majority, but instead of a disk witness, this cluster uses a file share witness.
Note that if you use Node and File Share Majority, at least one of the available cluster nodes must contain a current copy of the cluster configuration before you
can start the cluster. Otherwise, you must force the starting of the cluster through a particular node. For more information, see "Additional considerations" in
Start or Stop the Cluster Service on a Cluster Node.
No Majority: Disk Only not recommended
Can sustain failures of all nodes except one if the disk is online. However, this configuration is not recommended because the disk might be a single point of
failure.
Illustrations of quorum configurations

The following illustrations show how three of the quorum configurations work. A fourth configuration is described in words, because it is similar to the Node and Disk
Majority configuration illustration.
Note
In the illustrations, for all configurations other than Disk Only, notice whether a majority of the relevant elements are in communication regardless of the number of
elements. When they are, the cluster continues to function. When they are not, the cluster stops functioning.
As shown in the preceding illustration, in a cluster with the Node Majority configuration, only nodes are counted when calculating a majority.
As shown in the preceding illustration, in a cluster with the Node and Disk Majority configuration, the nodes and the disk witness are counted when calculating a
majority.
Node and File Share Majority Quorum Configuration
In a cluster with the Node and File Share Majority configuration, the nodes and the file share witness are counted when calculating a majority. This is similar to the Node
and Disk Majority quorum configuration shown in the previous illustration, except that the witness is a file share that all nodes in the cluster can access instead of a disk
in cluster storage.
In a cluster with the Disk Only configuration, the number of nodes does not affect how quorum is achieved. The disk is the quorum. However, if communication with the
disk is lost, the cluster becomes unavailable.
Why quorum is necessary

When network problems occur, they can interfere with communication between cluster nodes. A small set of nodes might be able to communicate together across a
functioning part of a network but not be able to communicate with a different set of nodes in another part of the network. This can cause serious issues. In this "split"
situation, at least one of the sets of nodes must stop running as a cluster.
To prevent the issues that are caused by a split in the cluster, the cluster software requires that any set of nodes running as a cluster must use a voting algorithm to
determine whether, at a given time, that set has quorum. Because a given cluster has a specific set of nodes and a specific quorum configuration, the cluster will know
how many "votes" constitutes a majority that is, a quorum. If the number drops below the majority, the cluster stops running. Nodes will still listen for the presence of
other nodes, in case another node appears again on the network, but the nodes will not begin to function as a cluster until the quorum exists again.
For example, in a five node cluster that is using a node majority, consider what happens if nodes 1, 2, and 3 can communicate with each other but not with nodes 4 and
5. Nodes 1, 2, and 3 constitute a majority, and they continue running as a cluster. Nodes 4 and 5, being a minority, stop running as a cluster. If node 3 loses
communication with other nodes, all nodes stop running as a cluster. However, all functioning nodes will continue to listen for communication, so that when the
network begins working again, the cluster can form and begin to run.
2015 Microsoft

You can add storage to a failover cluster after exposing that storage to all cluster nodes by changing LUN masking or zoning. You do not need to add the storage to
the cluster if the storage is already listed for that cluster under Storage in the Failover Cluster Manager snapin.
If you are only adding storage to a particular clustered service or application not adding entirely new storage to the failover cluster as a whole, see Add Storage for a
Clustered Service or Application.
To add storage to a failover cluster
3. Rightclick Storage, and then click Add a disk.
4. Select the disk or disks you want to add.
After you click Add a disk, if you do not see a disk that you expect to see, review the following:
The list of disks that are shown when you click Storage in the Failover Cluster Manager snapin. If the disk is already in that list, you do not need to add it
to the cluster.
The configuration of the storage interfaces, including the storage interfaces that run on the cluster nodes. The disk must be available to all nodes in the
cluster before you can add it to the set of storage for the cluster.
The disks shown in Disk Management check each node in the cluster.
If the disk that you want to add does not appear at all in Disk Management on any node, there might be an issue with the storage configuration that is
preventing the operating system from recognizing or mounting the disk. Note that disks currently in use by the cluster will appear in Disk Management
on one node only the node that is the current owner of that disk.
If the disk that you want to add appears in Disk Management but does not appear after you click Add a disk, confirm that the disk is configured as a
basic disk, not a dynamic disk. Only basic disks can be used in a failover cluster.
To open Disk Management, click Start, click Administrative Tools, click Computer Management, and then click Disk Management. If the User
Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
Add Storage for a Clustered Service or Application
2015 Microsoft

For each of the networks physically connected to the servers nodes in a failover cluster, you can specify whether the network is used by the cluster, and if so, whether
the network is used by the nodes only or also by clients. Note that in this context, the term "clients" includes not only client computers accessing clustered services and
applications, but remote computers that you use to administer the cluster.
If you use a network for iSCSI storage, do not use it for network communication in the cluster.
For background information about network requirements for a failover cluster, see Understanding Requirements for Failover Clusters.
To modify network settings for a failover cluster
3. Expand Networks.
4. Rightclick the network that you want to modify settings for, and then click Properties.
5. If needed, change the name of the network.
6. Select one of the following options:
Allow cluster network communication on this network
If you select this option and you want the network to be used by the nodes only not clients, clear Allow clients to connect through this network.
Otherwise, make sure it is selected.
Do not allow cluster network communication on this network
Select this option if you are using a network only for iSCSI communication with storage or only for backup. These are among the most common reasons
for selecting this option.
IP addresses and the associated network names used for the cluster itself or for clustered services or applications are called access points. For a brief description
of access points, see Understanding Access Points Names and IP Addresses in a Failover Cluster.
2015 Microsoft
Enable Cluster Shared Volumes in a Failover Cluster

You can enable Cluster Shared Volumes for a failover cluster using the Failover Cluster Manager snapin. By enabling Cluster Shared Volumes for a failover cluster, all
nodes in the cluster will be enabled to use shared volumes.
Important
The Cluster Shared Volumes feature has specific restrictions that must be followed. For a list of both the benefits and the restrictions, see Understanding Cluster
Shared Volumes in a Failover Cluster.
To enable Cluster Shared Volumes in a failover cluster
2. Under Configure center pane, click Enable Cluster Shared Volumes.
3. In the dialog box, select the checkbox.
Cluster Shared Volumes can only be enabled once per cluster.
2015 Microsoft

If you have special requirements or make changes to your cluster, you might want to change the quorum options for your cluster.
Important
In most situations, use the quorum configuration that the cluster software identifies as appropriate for your cluster. Change the quorum configuration only if you
have determined that the change is appropriate for your cluster.
For important conceptual information about quorum configuration options, see Understanding Quorum Configurations in a Failover Cluster.
To select quorum options for a cluster
2. With the cluster selected, in the Actions pane, click More Actions, and then click Configure Cluster Quorum Settings.
3. Follow the instructions in the wizard to select the quorum configuration for your cluster. If you choose a configuration that includes a disk witness or file share
witness, follow the instructions for specifying the witness.
2015 Microsoft

The following topics contain information about managing and troubleshooting a failover cluster:
Understanding Backup and Recovery Basics for a Failover Cluster
Bring a Clustered Service or Application Online or Take It Offline
Live Migrate, Quick Migrate, or Move a Virtual Machine from Node to Node
Pause or Resume a Node in a Failover Cluster
Run a Disk Maintenance Tool Such as Chkdsk on a Clustered Disk
Start or Stop the Cluster Service on a Cluster Node
View Events and Logs for a Failover Cluster
View Reports of the Actions of Failover Cluster Wizards
2015 Microsoft
Understanding Backup and Recovery Basics for a Failover

Cluster
This topic outlines some basic guidelines for backing up and restoring a failover cluster. For more information about backing up and restoring a failover cluster, see
http://go.microsoft.com/fwlink/?LinkId=92360.
Backing up a failover cluster

When you back up a failover cluster, you can back up the cluster configuration, the data on clustered disks, or both.
Backing up the cluster configuration

When you back up the cluster configuration, take note of the following:
For a backup to succeed in a failover cluster, the cluster must be running and must have quorum. In other words, enough nodes must be running and
communicating perhaps with a disk witness or file share witness, depending on the quorum configuration that the cluster has achieved quorum.
For more information about quorum in a failover cluster, see Understanding Quorum Configurations in a Failover Cluster.
Before putting a cluster into production, test your backup and recovery process.
If you choose to use Windows Server Backup the backup feature included in Windows Server2008R2, you must first add the feature. You can do this in Initial
Configuration Tasks or in Server Manager by using the Add Features Wizard.
When you perform a backup using Windows Server Backup or other backup software, choose options that will allow you to perform a system recovery from
your backup. For more information, see the Help or other documentation for your backup software.
Backing up data on clustered disks

When you back up data through a cluster node, notice which disks are Online on that node at that time. Only disks that are Online and owned by that cluster node at
the time of the backup are backed up.
Restoring to a failover cluster from backup

When you restore to a failover cluster from backup, you can restore the cluster configuration, the data on clustered disks, or both.
Restoring the cluster configuration from backup

The Cluster service keeps track of which cluster configuration is the most recent, and it replicates that configuration to all cluster nodes. If the cluster has a disk witness,
the Cluster service also replicates the configuration to the disk witness. Therefore, when you restore a single cluster node from backup, there are two possibilities:
Restoring the node to normal function, but not rolling back the cluster configuration: This is called a "nonauthoritative restore." In this scenario, the
reason you use the backup is only to restore a damaged node to normal function. When the restored node begins functioning and joins the cluster, the latest
cluster configuration automatically replicates to that node.
Rolling back the cluster configuration to the configuration stored in the backup: This is called an "authoritative restore." In this scenario, you have
determined that you want to use the cluster configuration that is stored in the backup, not the configuration currently on the cluster nodes. By specifying
appropriate options when you restore the backup, you can cause the cluster to treat the restored configuration as the "most recent." In this case, the Cluster
service will not overwrite the restored configuration, but instead will replicate it across all nodes. For details about how to perform an authoritative restore, see
the Help or other documentation for your backup software.
Restoring data to clustered disks from backup

When you restore backedup data through a failover cluster node, notice which disks are Online on that node at that time. Data can be written only to disks that are
Online and owned by that cluster node when the backup is being restored.
For additional information about backing up and restoring failover clusters, see http://go.microsoft.com/fwlink/?LinkId=92360.
For additional operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137835.
2015 Microsoft
Bring a Clustered Service or Application Online or Take It Offline

Sometimes during maintenance or diagnosis that involves a service or application in a failover cluster, you might need to bring that service or application online or take
it offline. Bringing an application online or taking it offline does not trigger failover, although the Cluster service handles the process in an orderly fashion. For example,
if a particular disk is required by a particular clustered application, the Cluster service ensures that the disk is available before the application starts.
For information about related actions, such as pausing a cluster node, see Managing a Failover Cluster.

To bring a clustered service or application online or take it offline
1. In the Failover Cluster Manager snapin, if the cluster you want to manage is not displayed, in the console tree, rightclick Failover Cluster Manager, click
Manage a Cluster, and then select or specify the cluster you want.
2. If the console tree is collapsed, expand the tree under the cluster that you want to manage.
3. Under Services and Applications, expand the console tree.
4. Check the status of the service or application that you want to bring online or take offline by clicking the service or application and viewing the Status column in
the center pane.
5. Rightclick the service or application that you want to bring online or take offline.
6. Click the appropriate command: Bring this service or application online or Take this service or application offline.
Note that in a clustered file server, shared folders are associated with a File Server resource. When you bring that resource online or take it offline, all shared
folders in the resource go offline or online at the same time. You cannot change the online or offline status of one of the shared folders without affecting all of
the shared folders in the File Server resource.
2015 Microsoft
Live Migrate, Quick Migrate, or Move a Virtual Machine from

Node to Node
Failover clusters in Windows Server2008R2 provide several ways to move virtual machines from one cluster node to another. You can live migrate, quick migrate, or
move a virtual machine to another node.
To live migrate, quick migrate, or move a virtual machine to another node
3. Expand Services and Applications, and then click the clustered instance containing the virtual machine you want to migrate or move.
4. Under Actions on the right, click one of the following:
Live migrate virtual machine to another node
Quick migrate virtual machines to another node
Move virtual machines to another node
For more information about these choices, see Understanding HyperV and Virtual Machines in the Context of a Cluster.
You cannot use live migration to move multiple virtual machines simultaneously. On a given server running HyperV, only one live migration to or from the
server can be in progress at a given time.
For live migration and quick migration, we recommend that you make the hardware and system settings of the nodes as similar as possible to minimize potential
problems.
For each clustered virtual machine, you can also specify the action that the cluster performs before taking the virtual machine offline. This setting does not affect
live migration, quick migration, or unplanned failover. It affects only moving or taking the resource offline through the action of Windows PowerShell or an
application. To specify the setting, make sure that after selecting the clustered virtual machine in the console tree on the left, you rightclick the virtual machine
resource displayed in the center pane not on the left, and then click Properties. Click the Settings tab and select an option. The actions are described in
Understanding HyperV and Virtual Machines in the Context of a Cluster in the section called "Live migration, quick migration, and moving of virtual machines,"
in the description for moving of virtual machines.
2015 Microsoft

Important
If you cluster your virtual machines and then use HyperV Manager to change the configuration of one of those virtual machines, be sure to follow the procedure
described in this topic. Otherwise, the settings of the virtual machine might not be uptodate in the failover cluster, which could cause problems during the next
move, migration, or failover of that clustered virtual machine.
We recommend that you use Failover Cluster Manager instead of HyperV Manager when you change the settings of a clustered virtual machine. For more
information, see Modify the Virtual Machine Settings for a Clustered Virtual Machine.
To refresh the configuration of a virtual machine
3. Expand Services and Applications, and then click the virtual machine for which you want to refresh the configuration.
4. In the Actions pane, scroll down, click More Actions, and then click Refresh virtual machine configuration.
5. Click Yes to view the details of this action.
2015 Microsoft
Pause or Resume a Node in a Failover Cluster

When you pause a node, existing groups and resources stay online, but additional groups and resources cannot be brought online on the node. Pausing a node is
usually done when applying software updates to the node, where the recommended sequence is to move all services and applications off of the node, pause the node,
then apply software updates to the node.
If you need to perform extensive diagnosis or maintenance on a cluster node, it might not be workable to simply pause the node. In that case, you can stop the Cluster
service on that node. For more information, see Start or Stop the Cluster Service on a Cluster Node.
To pause or resume a node in a failover cluster by using the Windows interface
Manage a Cluster, and select or specify the cluster you want.
2. If the console tree is collapsed, expand the tree under the cluster you want to manage.
3. Expand the console tree under Nodes.
4. Rightclick the node you want to pause or resume, and then either click Pause or Resume.
2015 Microsoft
Run a Disk Maintenance Tool Such as Chkdsk on a Clustered

Disk
To run a disk maintenance tool such as Chkdsk on a disk or volume that is configured as part of a clustered service, application, or virtual machine, you must use
maintenance mode. When maintenance mode is on, the disk maintenance tool can finish running without triggering a failover. If you have a disk witness, you cannot
use maintenance mode for that disk.
Maintenance mode works somewhat differently on a volume in Cluster Shared Volumes than it does on other disks in cluster storage, as described in Additional
considerations, later in this topic.
To run a disk maintenance tool such as Chkdsk on a clustered disk
1. In the Failover Cluster Manager snapin, if the cluster is not displayed, in the console tree, rightclick Failover Cluster Manager, click Manage a Cluster, and
select or specify the cluster you want.
2. If the console tree is collapsed, expand the tree under the cluster that uses the disk on which you want run a disk maintenance tool.
3. In the console tree, click Storage.
4. In the center pane, click the disk on which you want to run the disk maintenance tool.
5. Under Actions, click More Actions, and then click the appropriate command:
If the disk you clicked is under Cluster Shared Volumes and contains multiple volumes, click Maintenance, and then click the command for the
appropriate volume. If prompted, confirm your action.
If the disk you clicked is under Cluster Shared Volumes and contains one volume, click Maintenance, and then click Turn on maintenance mode for
this volume. If prompted, confirm your action.
If the disk you clicked is not under Cluster Shared Volumes, click Turn on maintenance mode for this disk.
6. Run the disk maintenance tool on the disk or volume.
When maintenance mode is on, the disk maintenance tool can finish running without triggering a failover.
7. When the disk maintenance tool finishes running, with the disk still selected, under Actions, click More Actions, and then click the appropriate command:
If the disk you clicked is under Cluster Shared Volumes and contains multiple volumes, click Maintenance, and then click the command for the
appropriate volume.
If the disk you clicked is under Cluster Shared Volumes and contains one volume, click Maintenance, and then click Turn off maintenance mode for
this volume.
If the disk you clicked is not under Cluster Shared Volumes, click Turn off maintenance mode for this disk.
Maintenance mode works somewhat differently on a volume in Cluster Shared Volumes than it does on other disks in cluster storage:
For Cluster Shared Volumes For disks not in Cluster Shared

Volumes
Changes the state of a volume. Changes the state of a disk LUN.
Takes dependent resources offline which interrupts client access. Leavesdependentresourcesonline.
Removes access through the \ClusterStorage\volume path, still allowing the owner node to access the volume Leaves access to the disk
through its identifier GUID. Also, suspends direct access from other nodes, allowing access only through the owner unchanged.
node.
Maintenance mode will remain on until one of the following occurs:
You turn it off.
The node on which the resource is running restarts or loses communication with other nodes which causes failover of all resources on that node.
For a disk that is not in Cluster Shared Volumes, the disk resource goes offline or fails.
You can see whether a disk is in maintenance mode by looking at the status in the center pane when Storage is selected in the console tree.
2015 Microsoft
Start or Stop the Cluster Service on a Cluster Node

You might need to stop and restart the Cluster service on a cluster node during some troubleshooting or maintenance operations. When you stop the Cluster service on
a node, services or applications on that node will fail over, and the node will stop functioning in the cluster until the Cluster service is restarted.
If you want to leave a particular node functioning so that it supports the services or applications it currently owns, and at the same time prevent additional services and
applications from failing over to that node, pause the node do not stop the Cluster service. For more information, see Pause or Resume a Node in a Failover Cluster.
To start or stop the Cluster service on a cluster node by using the Windows interface
2. If the console tree is collapsed, expand the tree under the cluster you want to manage.
3. To minimize disruption to clients, before stopping the Cluster service on a node, move the applications that are currently owned by that node to another node.
To do this, expand the console tree under the cluster that you want to manage, and then expand Services and Applications. Click each service or application
and in the center pane view the Current Owner. If the owner is the node on which you want to stop the Cluster service, rightclick the service or application,
click Move this service or application to another node, and then choose the node. For an explanation of the Best possible command option, see "Additional
considerations" in this topic.
4. Expand the console tree under Nodes.
5. Rightclick the node that you want to start or stop, and then click More Actions.
6. Click the appropriate command:
To start the service, click Start Cluster Service.
To stop the service, click Stop Cluster Service.
On a cluster with more than two nodes, from the options next to Move this service or application to another node, you can choose Best possible. This option
has no effect if you have not configured a Preferred owners list for the service or application you are moving in this case, the node will be chosen randomly. If
you have configured a Preferred owners list, Best possible will move the service or application to the first available node on the list.
In the center pane of the Failover Cluster Manager snapin, you can view information about the state of a node. To specifically check whether the Cluster service
is running on a node, rightclick the node and click More Actions. On a node that is started, Start Cluster Service is dimmed, and on a node that is stopped,
Stop Cluster Service is dimmed.
If you are using the Node and File Share Majority quorum option, at least one of the available cluster nodes must contain a current copy of the cluster
configuration before you can start the cluster. Otherwise, you must force the starting of the cluster through a particular node. The cluster will then use the copy
of the cluster configuration that is on that node and replicate it to all other nodes. To force the cluster to start, on a node that contains a copy of the cluster
configuration that you want to use, open the Failover Cluster Manager snapin, click the cluster, and then under Actions on the right, click Force Cluster Start.
Under most circumstances, this command is not available in the Windows interface.
Note
When you use this command on a given node, the copy of the cluster configuration that is on that node will be treated as the authoritative copy of the
configuration and will be replicated to all other nodes.
The Cluster service performs essential functions on each cluster node, including managing the cluster configuration, coordinating with the instances of the
Cluster service running on other nodes, and performing failover operations.
2015 Microsoft

The Validate a Configuration Wizard can be useful when troubleshooting a failover cluster. By running tests related to the symptoms you see, you can learn more about
what to do to correct the issue.
Important
If a clustered service or application is using a disk when you start the wizard, the wizard will prompt you about whether to take that clustered service or application
offline for the purposes of testing. If you choose to take a clustered service or application offline, it will remain offline until the tests finish.
Also, if you want to test disks that you have configured as Cluster Shared Volumes, you must explicitly take those disks offline, as described in the following
procedure.
To use validation tests for troubleshooting a failover cluster
1. Decide whether you want to run all or only some of the available validation tests. You can select or clear the following tests individually or by category:
Cluster Configuration tests: Validate important cluster configuration settings. For more information, see Understanding Cluster Validation Tests: Cluster
Configuration.
Inventory tests: Provide an inventory of the hardware, software, and settings such as network settings on the servers, and information about the
storage. For more information, see Understanding Cluster Validation Tests: Inventory.
Network tests: Validate that networks are set up correctly for clustering. For more information, see Understanding Cluster Validation Tests: Network.
Storage tests: Validate that the storage on which the failover cluster depends is behaving correctly and supports the required functions of the cluster. For
more information, see Understanding Cluster Validation Tests: Storage.
System Configuration tests: Validate that the system software and configuration settings are compatible across servers. For more information, see
Understanding Cluster Validation Tests: System Configuration.
2. In the Failover Cluster Manager snapin, if the cluster that you want to troubleshoot is not displayed, in the console tree, rightclick Failover Cluster Manager,
click Manage a Cluster, and then select or specify the cluster that you want.
3. If you want to test disks that you have configured as Cluster Shared Volumes, perform the following steps:
a. Expand the console tree and click Cluster Shared Volumes.
b. In the center pane, rightclick a disk that you want to test and then click Take this resource offline.
c. Repeat the previous step for any other disks that you want to test.
4. Rightclick the cluster that you want to troubleshoot, and then click Validate This Cluster.
5. Follow the instructions in the wizard to specify the tests, run the tests, and view the results.
6. If you took Cluster Shared Volumes offline in a previous step, perform the following steps:
a. Click Cluster Shared Volumes.
b. In the center pane, rightclick a disk that is offline and then click Bring this resource online.
c. Repeat the previous step for any other disks that you previously took offline.
To view the results of the tests after you close the wizard, choose one of the following:
Open the folder systemroot\Cluster\Reports on a clustered server.
In the console tree, rightclick the cluster, and then click View Validation Report. This displays the most recent validation report for that cluster.
2015 Microsoft

When you view events through the Failover Cluster Manager snapin, you can see events for all nodes in the cluster instead of seeing events for only one node at a
time.
For information about viewing the reports from the failover cluster wizards, see View Reports of the Actions of Failover Cluster Wizards.
To view events and logs for a failover cluster by using the Windows interface
1. In the Failover Cluster Manager snapin, if the cluster is not displayed, in the console tree, rightclick Failover Cluster Manager, click Manage a Cluster, and
then select or specify the cluster that you want.
2. If the console tree is collapsed, expand the tree under the cluster for which you want to view events.
3. In the console tree, rightclick Cluster Events and then click Query.
4. In the Cluster Events Filter dialog box, select the criteria for the events that you want to display.
To return to the default criteria, click the Reset button.
5. Click OK.
6. To sort the events, click a heading, for example, Level or Date and Time.
7. To view a specific event, click the event and view the details in the Event Details pane.
You can also use Event Viewer to open a log related to failover clustering. To locate the log, in Event Viewer, expand Applications and Services Logs, expand
Microsoft, expand Windows, and then expand FailoverClustering. The log file is stored in systemroot\system32\winevt\Logs.
2015 Microsoft

Each of the failover cluster wizards in Windows Server2008R2 produces a report of its actions. This topic describes how to view the report of a particular wizard by
clicking a button on the last page of that wizard or by opening a report from a specific folder in Windows Server2008R2.
To view a report of the actions of a failover cluster wizard
Choose one of the following options:
If the wizard for which you want to view a report is displayed, proceed through the wizard until you are on the Summary page, and then click View
Report.
If you ran the wizard but it is not displayed now, use Windows Explorer or another method to navigate to the following location and open the report you
want:
systemroot\Cluster\Reports
2015 Microsoft

For more information about failover clusters, see the following resources on the Microsoft Web site:
For a list of links to a variety of topics about failover clusters, see http://go.microsoft.com/fwlink/?LinkId=68633.
2015 Microsoft
User Interface: The Failover Cluster Manager Snap-In

This section contains descriptions of the following elements of the Failover Cluster Manager snapin for Windows Server2008R2:
Add Resource Type Dialog Box
<ClusteredInstance> Properties: General Tab
<Resource> Properties: Advanced Policies tab
<Resource> Properties: Dependencies Tab
<Resource> Properties: General Tab
<Resource> Properties: Policies Tab
Virtual Machine <Resource Name> Properties: Settings Tab
2015 Microsoft
Add Resource Type Dialog Box

Item Details
Resource Specify the path and file name of the resource DLL that the Cluster service should use when it communicates with your service or application. A resource
DLL path DLL monitors and controls the associated service or application in response to commands and requests from the Cluster service and associated software
and file components. For example, the resource DLL saves and retrieves service or application properties in the cluster database, brings the resource online and
name takes it offline, and checks the health of the resource.
Resource Specify the name that the Cluster service uses for the resource type. This name stays the same regardless of the regional and language options that are
type currently selected.
name
Resource Specify the name that is displayed for the resource type. This name might vary when you make changes to regional and language options.
type
display
name
2015 Microsoft
<ClusteredInstance> Properties: General Tab

Item Details
Preferred Select nodes from the list, and then use the buttons to list them in order.
owners
If you want this service or application to be moved to a particular node whenever that node is available:
Select the check box for a node and use the buttons to place it at the top of the list.
On the Failover tab, ensure that failback is allowed for this service or application.
Note that in the Preferred owners list, even if you clear the check box for a node, the service or application could fail over to that node for either
of two reasons:
You have not specified any preferred owners.
No node that is a preferred owner is currently online.
To ensure that a clustered service or application never fails over to a particular node:
1. Select an individual resource in the service or application.
2. Open the Properties sheet for that resource.
3. Select the Advanced Policies tab.
4. Configure Possible owners.
2015 Microsoft
<Resource> Properties: Advanced Policies tab

Item Details
Possible owners Clear the check box for a node only if you want to prevent this resource and the clustered service or application that contains this resource
from failing over to that node. Otherwise, leave the boxes checked for all nodes.
Note that if you leave the box for only one node checked, this resource and the clustered service or application that contains this resource
cannot fail over.
Basic resource Specify how often you want the cluster to perform a basic check to see whether the resource appears to be online. We recommend that you
health check use the standard time period for the resource type unless you have a reason to change it.
interval
This health check is also known as the Looks Alive poll.
Thorough resource Specify how often you want the cluster to perform a more thorough check, looking for indications that the resource is online and
health check functioning properly. We recommend that you use the standard time period for the resource type unless you have a reason to change it.
interval
This health check is also known as the Is Alive poll.
2015 Microsoft
<Resource> Properties: Dependencies Tab

When you specify resource dependencies, you control the order in which the Cluster service brings resources online and takes them offline. A dependent resource is:
Brought online after the resource or resources it depends on.
Taken offline before the resource or resources it depends on.
Note
After specifying dependencies, to see a report, rightclick the clustered service or application not the resource, and then click Show Dependency Report.
This tab contains the following controls:
Item Details
Resource Click the box, and then select a resource from the list. The list contains the other resources in this clustered service or application that have not already
been selected.
AND/OR For the second or later lines:
Specify AND if both the resource in that line and one or more previously listed resources must be online before the dependent resource is
brought online.
Specify OR if either the resource in that line or another previously listed resource must be online before the dependent resource is brought
online. The dependent resource can also be brought online if both are online.
Notice that gray brackets appear to show how the listings are grouped, based on the AND/OR settings.
Insert When you select a line in the list and click Insert, a line is added to the list before the selected line.
Delete When you select a line in the list and click Delete, the line is deleted.
2015 Microsoft
<Resource> Properties: General Tab

If a disk that you are using in a failover cluster has failed, you can use Repair on the General tab of the Properties sheet to assign a different disk.
Item Details
Repair button When you click this button, you can stop using a failed disk and assign a different disk to this service or application. The disk that you assign
for a disk must be one that can be used for clustering but is not yet clustered.
For more information about disks that can be used for clustering, see "List Potential Cluster Disks" in Understanding Cluster Validation Tests:
Storage.
Caution
The Repair button does not recover data.
Before using the Repair button, expose a LUN to each node of the cluster, but do not add that LUN to the cluster through the Failover Cluster
Manager snapin.
You can restore the data to the disk before or after using the Repair button.
2015 Microsoft
<Resource> Properties: Policies Tab

Item Details
Maximum restarts in the Specify the number of times that you want the Cluster service to try to restart the resource during the period you specify. If the
specified period resource cannot be started after this number of attempts in the specified period, the Cluster service will take actions as specified by
other fields of this tab.
For example, if you specify 3 for Maximum restarts in the specified period and 15:00 for the period, the Cluster service attempts
to restart the resource three times in a given 15 minute period. If the resource still does not run, instead of trying to restart it a
fourth time, the Cluster service will take the actions that you specified in the other fields of this tab.
Period mm:ss Specify the length of the period minutes and seconds during which the Cluster service counts the number of times that a resource
has been restarted. For an example of how the period works with the maximum number of restarts, see the previous cell in this
table.
If restart is unsuccessful, Use this box to control the way the Cluster service responds if the maximum restarts fail:
fail over all resources in
this service or application
Select this box if you want the Cluster service to respond by failing the clustered service or application over to another node.
Clear this box if you want the Cluster service to respond by leaving this clustered service or application running on this node
even if this resource is in a failed state.
If all the restart attempts Select this box if you want the Cluster service to go into an extended waiting period after attempting the maximum number of
fail, begin restarting again restarts on the resource. Note that this extended waiting period is measured in hours and minutes. After the waiting period, the
after the specified period Cluster service will begin another series of restarts. This is true regardless of which node owns the clustered service or application at
hh:mm that time.
2015 Microsoft
Virtual Machine <Resource Name> Properties: Settings Tab

On this tab, one of the settings you can specify is the action that the cluster will perform when taking the virtual machine offline. This setting does not affect live
migration, quick migration, or unplanned failover. It affects only moving or taking the resource offline through the action of Windows PowerShell or an application.
Option Details
Save The cluster saves the state of the virtual machine before taking the virtual machine offline, so that the state can be restored when bringing the
virtual machine back online. This is the default.
Shut down The cluster performs an orderly shutdown of the operating system waiting for all processes to close on the virtual machine before taking the
virtual machine offline.
Shut down The cluster shuts down the operating system on the virtual machine without waiting for slower processes to finish, and then takes the virtual
forced machine offline.
Turn off The cluster turns off the virtual machine without shutting down the operating system first when taking the virtual machine offline. This is the same
as turning off the power, which means that data loss may occur.
Option Details
Enable heartbeat When this option is selected, heartbeats are sent from the operating system running in the virtual machine to the operating system running
monitoring for the the HyperV role. If the heartbeats stop, indicating that virtual machine has become unresponsive, the cluster is notified, and can attempt to
virtual machine restart the clustered virtual machine or fail it over.
2015 Microsoft

Microsoft Failover Clustering 2008

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Microsoft Failover Clustering 2008

Hochgeladen von

Copyright:

Verfügbare Formate

9/7/2015 MyCollection

Overview of Failover Clusters

Checklist: Create a Failover Cluster

Checklist: Create a Clustered File Server

Checklist: Create a Clustered Print Server

Checklist: Create a Clustered Virtual Machine

Installing the Failover Clustering Feature

Validating a Failover Cluster Configuration

Creating a Failover Cluster or Adding a Cluster Node

Configuring a Service or Application for High Availability

Migrating to a Failover Cluster Running Windows Server 2008 R2

Modifying Settings for a Failover Cluster

Managing a Failover Cluster

Resources for Failover Clusters

User Interface: The Failover Cluster Manager SnapIn

Overview of Failover Clusters

Checklist: Create a Failover Cluster

Checklist: Create a Clustered File Server

Checklist: Create a Clustered Print Server

Checklist: Create a Clustered Virtual Machine

Installing the Failover Clustering Feature

Validating a Failover Cluster Configuration

Creating a Failover Cluster or Adding a Cluster Node

Configuring a Service or Application for High Availability

Migrating to a Failover Cluster Running Windows Server 2008 R2

Modifying Settings for a Failover Cluster

Managing a Failover Cluster

Resources for Failover Clusters

User Interface: The Failover Cluster Manager SnapIn

For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137836.

For operations information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137835.

Checklist: Create a Failover Cluster

Review hardware and infrastructure requirements for a failover cluster. Understanding

Create the failover cluster. Create a New

Checklist: Create a Clustered File Server

Review hardware and infrastructure requirements for a failover cluster. Understanding

Create the failover cluster. Create a New

Modify the Failover Settings for a Clustered Service or Application

Checklist: Create a Clustered Print Server

Create the failover cluster. Create a New Failover Cluster

Help from the application from

Modify the Failover Settings for a Clustered Service or Application

Checklist: Create a Clustered Virtual Machine

Review hardware requirements for HyperV. Hardware requirements for

Understanding Cluster Shared

Install the Failover Clustering

Managing virtual networks

Create the failover cluster. Create a New Failover Cluster

Overview of Failover Clusters

Modify the Failover Settings for a Clustered Service or Application

Configure a Virtual Machine for High Availability

Installing the Failover Clustering Feature

Install the Failover Clustering Feature

Install the Failover Clustering Feature

To install the Failover Clustering feature

4. When the wizard finishes, close it.

Understanding Requirements for Failover Clusters

Validating a Failover Cluster Configuration

Understanding Microsoft Support of Cluster Solutions

Understanding Cluster Validation Tests

Prepare Hardware Before Validating a Failover Cluster

Validate a New or Existing Failover Cluster

For troubleshooting information for failover clusters, see http://go.microsoft.com/fwlink/?LinkId=137836.

Understanding Requirements for Failover Clusters