I get asked this question all the time. People are concerned about losing their file share witness, so like many of their other shares, they want to leverage DFS for some additional availability. This is a very bad idea and is not supported.
Microsoft recently publish a great blog article that describes exactly why this is not supported.
https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/
Much of this article would also apply to people who ask if they can use a DataKeeper replicated volume resource as a Disk Share. It makes sense, you can use a DataKeeper volume resource in place of a Physical Disk resource for any other workload, so why not a Disk Witness?
This issue is the same as the DFS issue, in the event of a loss of communication between the two servers there is nothing to guarantee that the volume wouldn’t come online on both servers, causing a potential split-brain condition. The Physical Disk resource overcomes this issue by using SCSI reservations, ensuring the disk is only accessible by one cluster node at a time.
The good news is that Microsoft already blocks you from trying to us a replicated DataKeeper Volume resource and coming in Windows Server 2019 it looks like they will also block you from using a DFS share as a File Share Witness.
Clustering For Mere Mortals 
Hi Dave,
The article says “Microsoft does not support running a File Share Witness on certain DFS shares”, and “As long as there is only one link on the DFS share (meaning DFS-N only used as a namespace), you should be good.”
I take it from that, that if a normal single link share and no replication IS supported. What’s your take on that?
Seems the Win 2019 logic just checks to see if the DFS share has multiple links. If so it will fail. Otherwise it will pass?
Steve
Good question. Based upon what you quoted from the article I would agree with your assumption. I’m not sure of the behavior of 2019, I would have to explore that a bit. Are you telling me that it checks whether or not a share is part of DFS-N during the creation of the FSW and will fail if it has multiple links, but pass if only a single link? Again, great question, I’d have to do a little research, but do let us know what you experience. Next time I talk to someone on the cluster team at Microsoft I’ll see if I can get some clarification.
I have a question about use of a replicated NAS share for FSW. I understand the risks outlined in the MS article about avoiding replicated shares, but my challenge is slightly different. I “inherited” a design for a major customer, which is far from ideal, and I have to do what I can to improve matters. Here’s the scenario: 2 datacentres, primary and “standby”. Two nodes of a 4 node Windows Cluster in each running Server 2016. Apart from this cluster, much of the infrastructure is based on old school Active/Standby approach. There is a NAS system in the primary DC, which is replicated to the second DC. The NAS system in DC2 is isolated from the servers. In a DR situation where DC1 is lost, only then is the NAS in DC2 connected to the servers, by moving the subnet to the second DC (this is a manual intervention). So, when a share is “lost” in DC1 when that DC goes offline, then the copy appears online in DC2 with the same network path.
So, my question is, would it be viable to have FSW on a NAS share in this scenario. There’s no risk of a problematic split brain scenario. Even if the nodes in DC2 shut down due to loss of quorum immediately after the disaster, they can then come online as a functioning cluster once the FSW share in DC2 is online.
Any thoughts?
Well, if it is working and you have no issue with it then I suppose it is a workable solution, although supported by Microsoft is questionable. With a replicated file share witness you could run into times when the time stamp on the file share is older than the cluster database, which may cause a partition-in-time. Usually that happens when the cluster database is older than the file share witness, so I’m not 100% sure what would happen if the cluster database is newer than the file share witness timestamp. If that happens you might have to force the quorum online.
Thanks for the quick reply. It’s not a solution that’s implemented yet, and sadly I don’t have the options to run comprehensive testing to characterise how it would behave. Your comment on the timestamp aspects is certainly useful to know though. Thanks again.
Another, possible better option, is simply to use a Cloud Witness. It cost practically nothing and solves this problem. If you have any issues getting your storage to cooperate in this multi-site cluster drop me a line and I’ll introduce you to DataKeeper.