If you go through the GUI and are unable to uninstall a windows cluster chances are you have components that have not cleared themselves correctly from the registry. In order to get the target server(s) back to a pre-clustered configuration, you can use the instructions in the following link:

http://support.microsoft.com/kb/282227

Do note that this will forcefully delete all configuration in the registry redering any and all software that was associated with the cluster unusable.  At that point you ahve to manually clean up those entries as well.  So, use this process with caution.

Ever need to create a more detailed log for Windows 2008 failover clustering? Well, it became much easier for you. Just run the following command and then go into the directory C:\Windows\Cluster\Reports to get the cluster.log file:

cluster log /g /level:5

For more information, please read the link below:
http://blogs.msdn.com/b/clustering/archive/2008/09/24/8962934.aspx

The short answer is "yes" however its not recommended nor supported. If you choose to perform this option, you have to go in and just like any standalone Windows box first unjoin it and then rejoin the cluster nodes to the Active Directory domain you are looking for.

The following settings can be used for a general cluster configuration. Do note that you want to be EXTREMELY careful in setting high values here so as to not cause a non-detection event where the cluster does not failover as expected: Likewise, turning up the sensitivity may cause false failover events to happen when not needed:

1. If any nodes are currently paused, unpause them all using the failover cluster MMC
   
2. Set the following cluster properties on the passive node(s) from the command line:
   

   cluster /prop SameSubnetDelay=1000
   cluster /prop SameSubnetThreshold=10
   cluster res ClusterName /priv HostRecordTTL=300
   cluster res AnyOtherClusterName /priv HostRecordTTL=300

3. Also set the following cluster properties for the individual node via the command line:
   

   cluster /priv HeartBeatLostInterfaceTicks=10:DWORD
   cluster /priv HeartBeatLostNodeTicks=10:DWORD

4. Stop and start the cluster service on each node to confirm the settings have taken effect

Do note that the general settings and how to set these are found at the following link below:
What has changed for Windows 2008 and the heartbeat network?

Speacial Note: Dynamic DNS and Windows 2008 Failover Clusters

If you are seeing random issues here where DDNS is failing even after the changes are made above you can try going the alternate route and performing the following changes:

• Change the cluster DNS registration TTL's to to reflect a (1) day expiration:

  cluster res ClusterName /priv HostRecordTTL=86400
  cluster res AnyOtherClusterName /priv HostRecordTTL=86400

• Uncheck the "Register this connection's addresses in DNS" in the advanced DNS properties tab on all NIC's for all nodes of a cluster
  
• Choose the "Disable NetBIOS over TCP/IP" option in the advanced WINS properties tab on all NIC's for all nodes of a cluster

NOTE - This change is basically making the DNS registration of the cluster's network name valid for the prescribed time frame. If the IP Address is changed manually on purpose, you may need to restart the cluster and/or clear out the DNS cache to ensure this gets updated to the latest IP Address. Also, proper testing should be performed to ensure this option is valid in any particular customer's environment.

RHEL5 rhcs cluster nodes will try to fence each other if they lose multicast cluster communications between nodes.

In these types of problems the culprit is almost always a failure or configuration issue with multicast at the network switch.
Environment
Red Hat Cluster Suite
Diagnosing the problem
1. On all cluster nodes enable recognition of icmp broadcasts:
echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

2. On all cluster nodes run "cman_tool status" and note:

A. Number of cluster nodes.
B. The cluster multicast address:

[root@node5 ~]# cman_tool status
Version: 6.1.0
Config Version: 8
Cluster Name: rhel_cluster
Cluster Id: 31412
Cluster Member: Yes
Cluster Generation: 180
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 9
Flags: 2node Dirty
Ports Bound: 0 11 177
Node name: node5
Node ID: 5
Multicast addresses: 239.192.122.47
Node addresses: 9.47.65.165

3. Do a 2-count multicast ping:

ping -c 2 -I bond0 -b -L 239.192.122.47

4. If there are no problems then you should see multicast responses from all other cluster nodes:

PING 239.192.122.47 (239.192.122.47) from 9.47.65.165 bond0: 56(84) bytes of data.
64 bytes from 9.47.65.166: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from 9.47.65.166: icmp_seq=2 ttl=64 time=2.28 ms

-- 239.192.122.47 ping statistics --
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.230/1.755/2.281/0.527 ms

5. If you don't get the proper responses, then:

A. Make sure that you previously ran the following on ALL the cluster nodes:

echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

B. If you confirmed that Step 5A was done, then the either a node or network
switch is misconfigured or there are hardware problems such as bad
network cables.

6. On all cluster nodes disable recognition of icmp broadcasts:

echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Alternative Method

'omping' can be started on both nodes, taking the the ip of the remote node and the own ip as parameters.

Reference : How do I test multicast?

Ensure you run the same command on both nodes at the same time as mentioned in the above reference URL to properly check multicasting between the nodes.

With the introduction of Windows 2008, several improvements were introduced to improve upon Microsoft's cluster technology. In order to support a multisite cluster configuration, changes in how a cluster performs its inter cluster communication or health-checks was updated. Configuring these settings is done from the command line and is detailed below:

The following links below detail this process in more detail for your consumption.

To configure heartbeat and DNS settings in a multi-site failover cluster

1. On a node in the cluster, open a Command Prompt window.
   
2. Determine whether to change the heartbeat settings, for nodes on a common subnet, nodes communicating across subnets, or both. For background information about heartbeat settings, see Requirements and Recommendations for a Multi-Site Failover Cluster (http://go.microsoft.com/fwlink/?LinkId=129109).
   By default, regardless of subnet configuration, heartbeat frequency (also known as subnet delay) is once every second (1000 milliseconds). The range for heartbeat frequency is once every 250-2000 milliseconds on a common subnet, and 250-4000 milliseconds across subnets. By default, when a node misses a series of 5 heartbeats, another node will initiate failover, and the range for this value (also known as subnet threshold) is from 3 through 10.
   
3. If in step 2 you decided to change the heartbeat settings, run one or more of the following commands. Note that the first two commands affect nodes on a common subnet and the second two commands affect communication across subnets:

   cluster /cluster:<ClusterName> /prop SameSubnetDelay=<value>

   cluster /cluster:<ClusterName> /prop SameSubnetThreshold=<value>

   cluster /cluster:<ClusterName> /prop CrossSubnetDelay=<value>

   cluster /cluster:<ClusterName> /prop CrossSubnetThreshold=<value>

4. To confirm that the heartbeat settings are set as intended, run the following command:

   cluster /cluster:<ClusterName> /prop

5. View the network names of resources that are currently configured on the cluster by running the following command:

   cluster /cluster:<ClusterName> res

6. Determine which IP addresses should be registered in DNS for your cluster: either all IP addresses on which a network name resource depends, or only the IP address that successfully comes online (that is, the IP address on the subnet of the node that currently owns that network name resource). For background information about this setting, see Requirements and Recommendations for a Multi-Site Failover Cluster http://go.microsoft.com/fwlink/?LinkId=129109.
   The default is to register only the IP address that successfully comes online.
   
7. Choose and run only one of the following commands, substituting the name of the resource for <NetworkNameResource>:
   
   • To cause all IP addresses on which a network name resource depends to be registered, run the following command:

     cluster /cluster:<ClusterName> res <NetworkNameResource> /priv RegisterAllProvidersIP=1

   • To cause only the IP address that successfully comes online to be registered, run the following command:

     cluster /cluster:<ClusterName> res <NetworkNameResource> /priv RegisterAllProvidersIP=0

8. Determine the value to use for the DNS setting called Time to Live (TTL). As an example, the value recommended for Office Exchange Server 2007 is five minutes, which equals 300 seconds. If you do not adjust the TTL value, it defaults to 20 minutes (1200 seconds). For background information about TTL, see Requirements and Recommendations for a Multi-Site Failover Cluster http://go.microsoft.com/fwlink/?LinkId=129109.
   
9. To change the TTL setting, run the following command:

   cluster /cluster:<ClusterName> res <NetworkNameResource> /priv HostRecordTTL=<TimeInSeconds>

where <NetworkNameResource> is the name of the clustered resource that you want to set the TTL value for, and <TimeInSeconds> is the value you want to set for TTL.

1. To confirm that all the DNS settings are set as intended for a given network name resource, run the following command:

cluster /cluster:<ClusterName> res <NetworkNameResource> /priv

1. Take the clustered service or application offline and bring it back online, using the method that you are most familiar with. For example, to use the Failover Cluster Management snap-in, under Services and Applications, right-click the service or application and click Take this service or application offline, then right-click again and click Bring this service or application online.

The full article as well as additional resources are listed below for your reference:

Configuring thresholds for Heartbeat Network:

• http://technet.microsoft.com/en-us/library/dd197562%28WS.10%29.aspx

Information on Windows 2008 and changes to the heartbeat algorithm:

• http://blogs.technet.com/b/askcore/archive/2010/02/12/windows-server-2008-failover-clusters-networking-part-1.aspx
• http://blogs.technet.com/b/askcore/archive/2010/02/22/windows-server-2008-failover-clusters-networking-part-2.aspx
• http://blogs.technet.com/b/askcore/archive/2010/02/25/windows-server-2008-failover-clusters-networking-part-3.aspx

1. Carve the new LUNs on the new array (Storage)
2. If possible, add the new array and its LUNs to the same switch as the existing array (Storage).
3. Configure the switch to expose the new LUNs to NodeA and NodeB (Storage)
4. Install Powerpath/Multipath and then use disk management to rescan the drives
5. Use the active node to partition and format the disks
6. Use Cluster Admin to create the new physical disk resources and put them into their proper cluster groups
7. Move the Quorum using a temp location
   1. In Cluster Administrator, right click the cluster name
   2. Select Properties
   3. Select the Quorum tab
   4. Use the drop down box to select a temp location for the quorum
8. Delete the existing MSDTC folder
   1. Stop the MSDTC resource
   2. Copy the MSDTC folder from Q: to the final qurom disk target location
   3. Stop the Q: resource
   4. Delete the MSDTC resource
9. Move the quorum to its final location
   1. Go into disk management and change the Q: name to another letter
   2. Use disk management and name the final quorum drive to Q:
   3. Repeat steps 7.1-7.4 to move the quorum to its final destination
10. Recreate the MSDTC resource
    1. Create a new MSDTC resource with the cluster name network name resource and the new Q: as dependencies
    2. Bring the MSDTC resource online
11. Stop the cluster service and the application cluster groups (you can just stop the application resources if you want to move app data one at a time)
12. Move the data from the old disks to the new ones
13. Re-letter the old disks to something outside the current range, but do not remove them yet - you might need to use them in your back out plan
14. Re-letter the new disks to the same drive letter as the old ones (no, you do not have to worry about disk signatures as applications don't understand disk signatures and don't care about anything other than drive letters)
15. Verify that all dependent resources are pointing to the proper physical disk resource.
16. Restart the cluster service
17. Make sure the new drive letters and disk resources are showing up properly in cluster administrator
18. Bring everything back online

To enable a bigger cluster log file you can refer to the following document online at: http://support.microsoft.com/kb/168801

Do note that to fully enable this you have to also reboot the cluster service on ALL nodes for this to work.

The following is a checklist for common items that should be implemented or considered when you need to install a Windows based cluster for a customer:

1. Number of Cluster Nodes - typically this is (2) nodes but can go up to (4) node configurations within OpSource.
   
2. Number of NIC's - Network interfaces are often bonded together for fault tolerance.  But, for a cluster, we usually require additional dedicated interfaces for cluster traffic.  As a result, the recommendation is usually (2) NIC's one for internal cluster traffic and the other NIC for external application traffic.
   
3. Windows OS Type - When installing a cluster, you are REQUIRED to install Windows 2003 Enterrpise 32-bit or 64-bit
   
4. Shared Disk Partition(s) - A part of clustering involves usually a shared volume that is used to "float" amongst the nodes in a given cluster.  Disks that are to be used for clustering then are required to be seen and owned by all nodes participating in the cluster.  So, we typically use hte following mediums to achieve this:
   
   1. DAS Storage via SCSI or SAS cable
      
   2. SAN Storage via Fiber
5. SAN Storage Configuration - SAN storage LUN's should be created as distinctly separate LUN's so the proper redundancy can be achieved when a disk fails.  This will prevent all partitions created for a cluster to be on the SAME LUN and thereby causing a bigger outage event of one of the disks were in a failed state for whatever reason.
   
6. DNS Naming - All names used by the cluster MUST be in DNS as both A and PTR records.  This also includes any virtual or cluster management names setup for use by the cluster.  If these names are not present, naming issues usually result and cause weird connection errors within the cluster.
   
7. Networking Configuration - By nature of the cluster, a minimum of (2) networks should be defined for a proper cluster configuration. One of these networks can be the TRUST VLAN setup by default.  The other usually is a private non-routed network used solely for cluster communication.  If there are (2) nodes in a cluster, you may opt for a cross over cable to achieve this.  Otherwise, configuring a flat VLAN with no routing will suffice. 
8. Uninstalling Internet Explorer Security Component - These add-on components usually cause major issues when installing the application portion of software specifially when an application tries to connect via CIFS or UNC to the remote server to run the installer.  Uninstalling this component takes these sorts of issues out of the picture.
   
9. Security Patches - All cluster nodes should be at the same patch revision to ensure the same operating environment is maintained when failing over from one node to another.
   
10. Creation of AD SSO Objects - For any cluster setup, at a bare minimum, (1) service account is REQUIRED to act as a dedicated account that is not a named user so that the cluster can function across all nodes with the appropriate rights.  Additional accounts are typically added as it applies to the application needs.  For example, MSSQL usually requires 2-3 accounts for various services it maintains.
    
11. Assignment of Admin Rights to AD SSO Objects - Assigning administrative control or the like to the service accounts used for cluster operations is imperative to a properly configured setup.  Avoid adding individual accounts on a per server basis but rather assigning them to AD Security Groups and then assigning those groups access to what is needed on the target cluster nodes.

The following link details how to move a Cluster Quorum group in Windows 2008:

http://blogs.msdn.com/b/joesack/archive/2009/01/08/windows-server-2008-how-to-move-the-quorum-disk-group.aspx