Let's take a look at the four ways of determining quorum in Windows Server 2008:

Node Majority-- With the Node Majority model, each of the nodes that make up the server cluster gets a vote that counts toward quorum. The quorum disk itself does not have a vote. The cluster will function when more than half of the nodes in the cluster are operational, which means this model is used only when there are an odd number of nodes in the cluster. Remember that although the Node Majority model doesn't give its disk a vote, that disk is still a requirement for cluster operations.

Node and Disk Majority -- The vast majority of Windows clusters are two-node clusters. This has traditionally been the case because of the complexities of creating multi-node clusters as well as their cost. Two-node clusters cannot be created using the Node Majority mode -- as they have an even node count -- so in this alternate architecture, the disk resource itself also gets a vote. Used for server clusters that have an even number of nodes, the Node and Disk Majority requires more than half of the nodes plus the quorum drive itself to be operational for quorum to be achieved.

Node and File Share Majority -- Windows Server 2008 now includes support for geographically distributed clusters, those that are not bound by the length of the physical cables separating the nodes. Among other things, this support comes about with the conversion of cluster heartbeat communications from broadcast traffic to TCP-based traffic, which allows that portion of cluster communication to span subnets.

However, to create such a geo-cluster, both nodes can no longer functionally share the same storage. Thus, a special type of quorum drive was created that resides on a file share that is accessible by both nodes. This special cluster type also works for workloads that do not require shared storage, such as Exchange CCR clusters and some limited Hyper-V clustering arrangements.

No Majority: Disk Only -- This last quorum model relies only on the availability of the shared disk itself for determining quorum. It is effectively the same as what's used in older versions of Windows clustering. Because of its single point of failure reliance on the disk's presence, this model is rarely recommended for use in production environments.

Microsoft Exchange Transport Dumpster

The Exchange Transport Dumpster is a feature that exists in Exchange 2007 andExchange 2010 to prevent data loss. The transport dumpster has been revamped in Exchange 2013 and is now known as the Safety Net.

First introduced in Exchange 2007, the transport dumpster exists on the hub transport server and is only enabled for continuous cluster replication (CCR) and

local continuous replication (LCR). Administrators can configure either so that after a clustered mailbox server goes down, it comes back online with limited data loss because messages stored in the dumpster are still sent to users.

Similarly, in Exchange 2010 the transport dumpster still exists on the hub transport server, but because CCR and LCR were replaced by database availability groups(DAGs), it now works with them. When a message is sent from the hub transport server to a DAG, the message is stored in the transport dumpster so in case of failure, messages can still be sent to users.