An Exchange Server 2007 CCR cluster uses a cluster quorum configuration called Node and File Share Majority.
This means that the cluster has two servers that are the cluster nodes themselves, and a third server that is the File Share Witness server. The role of the File Share Witness server is to allow a majority of nodes to “vote” on which cluster node should be the active node.
The File Share Witness server is simply a server configured with a file share that the cluster service has access to. During failure scenarios each cluster node (that is still online) attempts to get an SMB lock on the file share to see if it can secure the majority of “votes” in the cluster.
The normal practice is to locate the File Share Witness for an Exchange Server 2007 CCR cluster on a Hub Transport server in the same site or data center as the cluster nodes, or the same data center of at least one of the nodes in a geo-cluster model. It is not mandatory to place it on a Hub Transport server though.
In some situations you may need to move this File Share Witness role to another server. This is a fairly simple process for Exchange Server 2007 CCR clusters running on Windows Server 2008.
In this demonstration I will move the File Share Witness from server HO-EX2007-HT1 to HO-EX2007-CA1 for the clustered mailbox server HO-EX2007-MB1.
Creating the File Share
The first step is to create the file share on the new File Share Witness server. Create a new folder named <clusteredmailboxserver>_FSW.
Open the Properties of the folder and navigate to the Sharing tab, then click Advanced Sharing.
Tick the box to share the folder, and then click Permissions.
Remove the default share permissions, and then add the computer account for the cluster with Full Control permissions.
Click OK, and OK to apply the share permissions, and then click on the Security tab of the folder properties.
Edit the permissions to grant the computer account for the cluster Full Control of the folder.
Click OK and apply all the changes you’ve just made.
Change the File Share Witness for the Failover Cluster
Log on to one of the cluster nodes and open Failover Cluster Management from the Administrative Tools. Right-click the cluster name and choose More Actions -> Configure Cluster Quorum Settings.
Click Next, then select Node and File Share Majority, and click Next to continue.
Enter the UNC path to the new file share that you created earlier, click Next, and then click Next again to configure the cluster with the new File Share Witness.
Click Finish when the operation has completed.
The File Share Witness role has now been moved to the new server.
Testing the New File Share Witness
There are a few ways you can test the new cluster configuration.
You can use the Manage Clustered Mailbox Server wizard to test the failover of the cluster between the two nodes.
You can also create unplanned failover scenarios, although if you do decide to do this I recommend making sure you do it outside of business hours, after a successful backup, and ensure the storage groups are in a healthy replication state with no copy or replay queues.
You can use Failover Cluster Management to stop the cluster service on the active node, which will cause a failover. Make sure you start it again when you’re done with the test.
Or you can simply pull out the network cable from the active node, which will have the same effect.
In these unplanned failover scenarios when one node is unavailable the File Share Witness is used to form a majority so that the other cluster node can bring the cluster resources online. You can verify that the FSW arbitration took place by generating the cluster log and opening it in Notepad.
C:\>cluster log /g Generating the cluster log(s) ... The cluster log has been successfully generated on node 'ho-ex2007-node2'... The cluster log has been successfully generated on node 'ho-ex2007-node1'...
Look at the cluster.log file in C:WindowsSystem32ClusterReports and you should see entries for the FSW arbitration.
File Share Witness : Beginning arbitration ... File Share Witness : Opening file \ho-ex2007-ca1ho-ex2007-mb1_fsw82c44535-d765-4fbe-8ad8-0de1c04a87a6Witness.log. File Share Witness : Locking file \ho-ex2007-ca1ho-ex2007-mb1_fsw82c44535-d765-4fbe-8ad8-0de1c04a87a6Witness.log.
After your testing is complete just be sure to reconnect any network cables, start cluster services if you stopped them, and move the cluster group back to the preferred active node.
This article is very good but not complete, we just tried it. It doesn’t remove existing FSW. we referred other articles and understood that first have to change the quorum setting to Nodeonly and then again set as Majoritynodeset
Refer the article below
Can we use the same process , if our current FSW got corrupted.
I wonder what will happen when you simulate a failover for the active node. I explain :
1. Simulate active node (EXCH1) fail
2. Passif node (EXCH2) begin active node automatically
3. EXCH1 come back alive -> what happen?
When a failed node comes back the storage groups/databases will try to resynchronise. If that fails manual attention by the administrator is required, possibly to reseed the copies.
The cluster doesn’t automatically fail back to the other node, if that is what you’re wondering.
Does it have to be in the cluster server or can it be on the stand alone HubTransport server which is not clustered ?
What about if the server who holds the FileShare Witness is rebooted ?
It must be a separate server, not one of the clustered Mailbox servers.
The cluster will survive a restart of the FSW because quorum is still maintained by the two mailbox servers.