The fallacy of the workstation File Share Witness

The hoary old theory that you can use a Windows 7/8/10 workstation to act as the witness server for an Exchange Database Availability Group (DAG) has been doing the rounds. Granted, it is a theory and no one that I know has yet succumbed to the desire to attempt to implement such a configuration. But as a public service, let me say for once and for all that the idea is unsupported, ill-advised, unpredictable, and just plain silly.

Workstations are not servers. Well, that’s not always the case as proven in 1996 when Mark Russinovich discovered that changing a few registry keys transformed a Windows NT workstation into a server. Of course, Mark is now a major-league player (the Azure CTO) at Microsoft where he spends his time worrying about Azure when not writing thrillers like “Rogue Code: A Jeff Aiken Novel” that feature a mixture of IT, hacking, and spying. If you’re looking for a good book and like a well-paced ramp with plenty of action, these are for you.

Things are a little different now and servers and workstations do differ. A lot is made about “One Windows” today and it’s true that the same kernel is used across the Windows family, but the fact remains that servers and workstations are designed to perform very different tasks. Even the smallest Windows 2012 server is designed to provide a more robust operating environment than a beefy Windows 8.1 Pro workstation. And let’s face it, if you are building a DAG that’s supposed to deliver high availability for critical mailboxes, why would you introduce a workstation into the scenario? It just doesn’t make sense.

In any case, the Exchange product group definitely wants you to use a real-life Windows server to host the file share witness (FSW) for a DAG. The witness server cannot be a member of the DAG that uses the FSW and a single server can act as the witness server for multiple DAGs, if that’s what you want to do. Another Exchange server that’s not part of the DAG or a print server are good options, but even a domain controller will do if you absolutely don’t have another server to hand.

The FSW is only used when the need arises to maintain quorum in the Windows Failover Cluster (for the DAG) that uses a node and file share majority scheme. Apart from this, the FSW doesn’t do very much at all. The FSW is managed by the cluster like any of the other resources on which the cluster depends.

If you look in the witness directory (configured as part of the DAG properties), you’ll find a couple of text files in the file share that gives the FSW its name. One of these (VerifyShareWriteAccess.log) is used by the Windows Failover Cluster as part of its periodic checks to validate that all is well with the witness resource. The second (Witness.log) is used by the cluster to lock the witness when the cluster is within one vote from using quorum. Windows uses a paxos algorithm to maintain consistency within clusters. A change in a cluster causes the paxos tags for the nodes to be recalculated. The witness.log file contains the updated paxos information for the cluster. If the file can be locked, the cluster knows that it can use the FSW vote to maintain quorum.

Although Microsoft is investigating new configurations for the FSW within a DAG, like the so-far unfulfilled effort to place the FSW on Azure, there’s no desire (and rightly so) to attempt to put the FSW on a workstation. Again, a DAG is a high-availability solution. Introducing a workstation into the mix seems like a pretty good way to create a low-availability scenario.

Follow Tony @12Knocksinna