A. Consider the file share witness’s role. The file share witness becomes a crucial “vote” in the event the cluster becomes split. The file share witness’s vote is secured by writing information to the file share and locking the witness.log file. This lock means that only one part of the cluster can claim the file share witness for its quorum.
DFS abstracts the physical layout of file shares and instead creates a logical namespace that redirects a user to an actual file share (i.e., a target) based on the location within the DFS namespace. You can define multiple targets for a single DFS link, so that users can be redirected to a copy of the data closest to them. Through DFS Replication (DFSR), the content of the multiple targets is kept synchronized.
Let’s say the file share witness is a share within the DFS namespace that has multiple targets, and two locations lose communication with one node in each location. Both nodes would access the file share witness via DFS and be directed to the target closest to their location. The nodes would actually be viewing a separate physical share that isn’t replicating in absolute real time. In this way, both nodes can update the file share, both nodes lock the witness.log file, and both nodes think they’ve locked the file share and thus make quorum, as the following diagram shows.
That is, both halves of the cluster offer services because both sides made quorum, which will lead to problems and possible corruption. Thus, you shouldn’t host the file share witness on a DFS hosted share.
