The solution uses external storage, while third-party solutions don't use external storage. They're using a mirror to create a partition on each server and synchronize the data in the background. It's not easy to set up or monitor its status.
The product should be less dependent on network configuration. Our technicians usually require other tools along with Failover Clustering. It makes our network implementation more expensive.
The solution has some downsides related to the election mechanism, meaning that if the servers or the cluster services or cluster server elect one server, they will attribute to that server an object that is called a quorum. This quorum does the server or the service that has that quorum, it is taken as the master. So when you have, for example, something happens in your data centers like a power outage or an unexpected shutdown, and you can't start the master server what sometimes will happen, is since the shutdown was unexpected, the cluster didn't have time to do some post configurations before the extension of the shutdown of the servers, sometimes that quorum can't be removed from the crashed master and the cluster wants stuff. This is part of the architecture of this service, the Failover service. So sometimes we face this type of problem. In the past, we had a lot of power outages and when we started after, our server, we faced this problem. Meaning that the cluster won't stop because one of the servers, the master crashed, and they didn't want to start. So we need to access and do some line configurations so that we will force the cluster to elect a new master and ignore the crashed one.
There are times when we do the system security updates and have to restart the server which is difficult because we need to wait until the end of the day or when working hours are finished. There are service updates that have a requirement to restart the system and it is not convenient. In a feature release, there should be a feature to allow applications to be developed on the web portal and better databases that we can run.
The solution has failed me maybe twice since I've had it over the course of ten years. The failure was a long time ago, however, and it happened on a different version. RIght now, the current version seems to work properly. I'd like to see the reliability continue to improve. I don't ever want the solution to go down on me. It's too important. They could drop the price or improve the cost of the hyper-converged component of it all. Right now, licensing is expensive and complex.
Learn what your peers think about Windows Server Failover Clustering. Get advice and tips from experienced pros sharing their opinions. Updated: January 2026.
Windows Server Failover Clustering provides infrastructure features that support the high-availability and disaster recovery scenarios of hosted server applications such as Microsoft SQL Server and Microsoft Exchange. If a cluster node or service fails, the services that were hosted on that node can be automatically or manually transferred to another available node in a process known as failover.
The solution uses external storage, while third-party solutions don't use external storage. They're using a mirror to create a partition on each server and synchronize the data in the background. It's not easy to set up or monitor its status.
The product should be less dependent on network configuration. Our technicians usually require other tools along with Failover Clustering. It makes our network implementation more expensive.
The tool's pricing is high.
The solution has some downsides related to the election mechanism, meaning that if the servers or the cluster services or cluster server elect one server, they will attribute to that server an object that is called a quorum. This quorum does the server or the service that has that quorum, it is taken as the master. So when you have, for example, something happens in your data centers like a power outage or an unexpected shutdown, and you can't start the master server what sometimes will happen, is since the shutdown was unexpected, the cluster didn't have time to do some post configurations before the extension of the shutdown of the servers, sometimes that quorum can't be removed from the crashed master and the cluster wants stuff. This is part of the architecture of this service, the Failover service. So sometimes we face this type of problem. In the past, we had a lot of power outages and when we started after, our server, we faced this problem. Meaning that the cluster won't stop because one of the servers, the master crashed, and they didn't want to start. So we need to access and do some line configurations so that we will force the cluster to elect a new master and ignore the crashed one.
There are times when we do the system security updates and have to restart the server which is difficult because we need to wait until the end of the day or when working hours are finished. There are service updates that have a requirement to restart the system and it is not convenient. In a feature release, there should be a feature to allow applications to be developed on the web portal and better databases that we can run.
The solution has failed me maybe twice since I've had it over the course of ten years. The failure was a long time ago, however, and it happened on a different version. RIght now, the current version seems to work properly. I'd like to see the reliability continue to improve. I don't ever want the solution to go down on me. It's too important. They could drop the price or improve the cost of the hyper-converged component of it all. Right now, licensing is expensive and complex.
The standard, non-enterprise technical support could be improved.