For Windows Server 2019, additional safeguards have been added to help protect from misconfigurations. We have added logic to check to check if the share is going to DFS.
Microsoft does not support running the File Share Witness on a DFS share and did not support it in the past and we will not support it for the foreseeable future.
In a Windows 2016 4-node multi-site Cluster with two nodes at each site running SQL FCI, where each side utilizing a storage replication for the shared drives. This connection to the file share Witness, a part of the DFS share.
But in case there is a break in communication between t the two sites, will have the below result.
The loss of connectivity between the two sites will result for the Site A , which already has the file share witness, to place a lock on it. Because it is running SQL already, it stays status quo. On the Site B, is where the problem occurs. Since it cannot communicate to Site A, it has no idea what is going on. Site B nodes do what it is supposed to which is to arbitrate to get the Cluster Group and the witness resource. It goes to connect and DFS Referral sends it to one of the other machines and connects. Site B nodes see it has the witness, so it starts bringing everything online, which would include SQL and its databases. For those not so familiar with Failover Clustering and all its jargons, this is known as a split brain.
SO each side have quorum and SQL clients connecting and modifying the databases. Though when the connectivity will return a possible outcome is that one of the sides is going to lose what was changed.
As Microsoft doesn’t support running a FS Witness on a DFS share, extra steps were added in the Failover Cluster Manager t. In the quorum configuration wizard or powershell if you will try to use a DFS share , it will fail.