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.