Ok, here we go with part 3 in my series about how to install Exchange 2007 CCR Clustering within a VMWARE environment – in part 1 I discussed how you can configure a virtual environment to support Virtual Clustering and went through how I created a pair of nodes – then in part 2 I discussed what a Majority Node Set cluster is and how one can created with the nodes from part 1.

In part 3 of this series I would like to discuss how to configure “File Share Witness” within the cluster.

At this stage if you have not read parts 1 and 2 I would suggest that you have a look at them as they will bring you up to date with some of the finer technical details that may prove useful if you wish to try this yourself.

Ok lets begin…

What is File Share Witness (FSW)?

The File Share Witness is a separately downloaded feature to Windows 2003 Enterprise Edition SP1 and Windows 2003 EE R2 SP1 Majority Node Set based clusters, which allows for you to configure a share which is separate to your cluster nodes (on another machine in your enterprise) which contains data about the status of a two-node MNS cluster. You should note that the FSW update is included as part of Windows 2003 SP2.

As mentioned in part 1 of this series a MNS cluster can only function if the majority of the nodes are up and running, however in a two node MNS based cluster if one node fails the cluster will be unable to sustain the loss, and therefore all cluster resources will fail (50% is not a majority – the majority of a two node cluster is, erm, two). In order to be able to loose a single node in a two node MNS cluster you need three nodes that can be considered as “available”.

File Share Witness allows you to configure a share on another server independent of your cluster which acts as the third node in a two node MNS cluster and will allow for the remaining “official” node to continue operation (clever isn’t it?).

There are some other features to the FSW that are pertinent to these articles;

• The FSW aids in avoiding “split brain” scenarios, these arise if two nodes in a MNS cluster cannot communicate with each other, a Split Brain situation normally results in both nodes not knowing where the communication loss occurred (as the other node cannot be contacted) – this typically results in the cluster service terminating on both nodes and the cluster being rendered inoperative, however the FSW can choose a remaining node and tag it as a survivor the node can then work out if it is to continue running.
• The FSW aids in avoiding “Partition in time” the can occur when one node is running, but the other is not – then the running node stops working then the second node is brought back online and tries to assume control of the cluster – however this is dangerous as the second node may not have the most up to date version of the cluster configuration (from the first node). The FSW will stop a node that does not have the most current version of the cluster configuration from running.

There is an excellent article on the FSW here from the Microsoft Knowledge base which explains the above in much more detail.

Ok, How do we configure this beasty?

Firstly lets understand where the FSW ** SHOULD ** be placed;

The guys over at EHLO suggest that in production the FSW share should be placed on the Hub Transport server in the same data center (remember nodes do not have to be in the same physical location as each other when using the MNS, just the same subnet) as the preferred node of the MNS (this is typically the first node that you have setup) – this supposition is based upon a statistical study that was done which determined that the most common form of networking failure is WAN rather than LAN (think about it how many WAN links do you lose in a year compared to your local network) – this means that your failure point will be between nodes, and as mentioned above in a two node MNS cluster the FSW decides which node is to carry on – if the FSW is in the same Data Center as the preferred owning node then the primary node will maintain service.

There is a brilliant (and better) explanation of the above here.

Now, as I am working within a VM environment although my nodes are in the same place, I do not at this stage have a “Hub Transport” server – so, I have decided to create the FSW on the domain controller (remember I am only doing this as part of the lab – in production I would follow the MS recommendation, and I also intend to move the FSW share when I build a HT role server for the Lab).

• Requirements for the FSW Share

The FSW is a normal Windows share, however there are some specific permissions that need to be considered:

When you have created the folder to be shared you must ensure that the account that the Cluster Service  runs under as well as the Domain Admins group has both full control on the share permissions AND on the NTFS permissions – you can accomplish this by either adding the cluster account into the local administrators group on the Hub Transport server (in production) and then assigning the local administrators full permissions to the folder – or – in my case (as I am using the DC which does not have a local administrators group) add the Cluster domain account directly onto the permissions of the folder.

To create the share I logged onto my domain controller, and created a folder called FSW on one of the partitions – like the example below:

I then right clicked on the folder and from the pop up menu that appeared I selected “Properties” – which opened up the following dialog box:

From here I clicked on the “Sharing Tab” and then selected the “Share this folder” option, then provided a name for the share – I then clicked on the permissions button which opened up the following dialog:

I clicked on the “Add” button and from the directory search box typed in the name of my Cluster Services domain account (if you haven’t seen the last article is #EXCLUSTER”) and then clicked on the OK button, I then selected the #EXCLUSTER account from the list and gave it full control on the share – like so:

I then added in the “Domain Admin” group and gave it “Full Control” and removed the “Everyone” group from the share permissions and clicked on the OK button, which returned my back to the FSW “Properties” dialog box – I then clicked on the “Security” Tab which changed the dialog to look like the following:

Here I clicked on the “Advanced” button which opened up the following dialog box:

Here I un-ticked the “Allow inheritable permissions from the parent to propagate to this object and all child objects, include these with entries explicitly defined here” option – which displayed the following dialog box:

Here I clicked on the “Copy” option and then when I returned to the previous dialog I clicked “Ok” which returned me to the security “Properties” where I configured the following:

I added in the Cluster services account and the Domain Admins account and gave them full control over the share, and then removed all of the other account entries.

At this stage the share is now ready to be configured for FSW via the primary node.

Here I logged onto the primary node of my MNS cluster – I opened up a command prompt and typed in the following command:

cluster.exe res “Majority Node Set” /priv MNSFileShare=\\VS-EXDC-CLUS\FSW

I know that I was successful as I received the following message:

System warning 5024 (0×00013a0).

The properties were stored but not all changes will take effect until the next time the resource is brought online.

Here I enabled the changes by typing in the following command:

Cluster group “cluster group” /move

This moved the cluster resource to the second node (which will enable the settings as the resources are taken offline and brought online again during a cluster move operation).

I then ran the same command again to move the resources back to the primary node.

Next Article;

Installing Exchange 2007