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.

Moving SSL Certs from IIS to Apache

These instructions will help you convert SSL certificates generated for IIS to private key, and cert files you can use on unix, or Apache for windows.

First Export your IIS certificate into a pfx file (this is something you should do anyways for backup)

• Run mmc.exe
  
• Click the 'Console' menu and then click 'Add/Remove Snap-in'.
  
• Click the 'Add' button and then choose the 'certificates' snap-in and click on 'Add'.
  
• Select 'Computer Account' then click 'Next'.
  
• Select 'Local Computer' and then click 'OK'.
  
• Click 'Close' and then click 'OK'.
  
• Expand the menu for 'Certificates' and click on the 'Personal' folder.
  
• Right click on the certificate that you want to export and select 'All tasks' -> 'Export'.
  
• A wizard will appear. Make sure you check the box to include the private key and continue through with this wizard until you have a .PFX file.

Next run openssl to extract the private key, and the cert file.

Export the private key file from the pfx file

openssl pkcs12 -in filename.pfx -nocerts -out key.pem

Export the certificate file from the pfx file

openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem

This removes the passphrase from the private key so Apache won't prompt you for your passphase when it starts.

openssl rsa -in key.pem -out server.key

There are times when a customer has a large amount of AD users and requests a list of users who belong to a certain AD group. If you ever want to export a list of users from AD who belong to a specific AD group you can use dsquery to do so.

Example:

Customer: XYZ
AD group: XYZ_ReportCorp

dsquery group -name XYZ_ReportCorp|dsget group -members|dsget user -samid -fn -ln > c:\XYZ_List.txt