These are the various types of clusters and cluster-like configurations on which FPE can be installed:

• Cluster Continuous Replication (CCR)—This type of clustered mailbox server combines the replication and replay features in Exchange 2007 with failover features in Microsoft Cluster services. Failover is the process by which a server in the cluster takes over the functions of another server in the cluster, in the case of a failure of the first device. The term can also be used for a deliberate transfer of services to another server in the cluster. CCR is a solution that can be deployed with no single point-of-failure in a single data center or between two data centers. A node that is currently running a Clustered Mailbox Server (formerly called an Exchange Virtual Server) is an active node; a node in the cluster that is not currently running a Clustered Mailbox Server is a passive node.
  
  CCR uses the database failure recovery functionality in Exchange 2007 in order to enable the continuous and asynchronous updating of a second copy of a database with the changes that have been made to the active copy of the database. Logs are not copied until they are closed and no longer in use by the Mailbox server. During installation of the passive node in a CCR environment, each storage group and its database is copied from the active node to the passive node. This operation is called seeding, and it provides a baseline for replication of the database. After the initial seeding is performed, log copying and replay are performed continuously. CCR uses the passive node to copy and replay the logs. Logs are accessed by the passive node via a secured file share.
  
  In a CCR environment, replication capabilities are integrated with the Cluster service to deliver a high availability solution. In addition to providing data and service availability, CCR also provides for scheduled outages. When updates need to be installed or when maintenance needs to be performed, you can move a Clustered Mailbox Server manually to a passive node. After the move operation is complete, you can perform the needed maintenance.
  
  
• Database Availability Groups (DAG)—In other types of clusters, when there is a failure, physical servers fail over. Failover is the process by which a server in the cluster takes over the functions of another server in the cluster, in the case of a failure of the first device. The term can also be used for a deliberate transfer of services to another server in the cluster. In DAG, instead of servers failing over, individual databases fail over. Each server in a DAG can have multiple mailbox databases (MDBs), and the servers monitor each other to detect when a peer has failed. If a failure occurs, automatic recovery causes the failed database on the active server to be dismounted and the duplicate copy on the passive server to be mounted. All clients now query information on the active (duplicate) copy of the database.
  
  
• Local Continuous Replication (LCR)—LCR allows for data replication to an alternate drive attached to the same system. This is not a cluster configuration because it does not provide true high availability in the event of system failure. It is intended to provide protection against local storage failures, but it does not protect against the failure of the server itself. LCR is a single-server solution that uses built-in asynchronous log shipping and log replay technology in order to create and maintain a copy of a storage group on a second set of discs that are connected to the same server as the production storage group. LCR provides a quick manual switch to a secondary copy of your data. The procedure for installing FPE on an LCR system is the same as that for a normal stand-alone installation.
  
  
• Single Copy Cluster (SCC)—This type of clustered mailbox server uses shared storage in a failover cluster configuration to permit multiple servers to manage a single copy of the storage groups. Failover is the process by which a server in the cluster takes over the functions of another server in the cluster, in the case of a failure of the first device. The term can also be used for a deliberate transfer of services to another server in the cluster. In this architecture, although all nodes in the cluster can access shared data, they cannot access it at the same time.
  
  In a Single Copy Cluster, an Exchange 2007 mailbox server uses its own network identity, not the identity of any node in the cluster. This network identity is referred to as a Clustered Mailbox Server. If the node running a Clustered Mailbox Server experiences problems, the Clustered Mailbox Server goes offline for a brief period until another node takes control of it and brings it online (failover). The shared storage is available to each possible host node of the Clustered Mailbox Server. As the failover happens, the storage associated with the clustered mailbox is logically detected from the failed node and placed under the control of the new host node.
  
  In addition to providing data and service availability, SCC also provides for scheduled outages. When you need to install updates or perform maintenance, you can move a Clustered Mailbox Server manually to a passive node. After the move operation is complete, you can perform the needed maintenance or install the updates.
  
  
• Standby Continuous Replication (SCR)—This is a replication technology, not a cluster configuration. Unlike CCR, which requires that both servers belong to a Windows cluster (typically residing in the same data center), SCR can replicate data to a non-clustered server located in a different data center. This configuration creates redundancy for data center storage by permitting an additional copy of the data to exist inside or outside the data center. SCR uses the continuous replication technology to move data from one mailbox server to another. SCR enables a mailbox server to be a continuous replication target for a stand-alone mailbox server that does not have LCR enabled. A mailbox server can also be a passive node in a failover cluster where the mailbox role is installed but no clustered mailbox server has been installed in the cluster. Failover is the process by which a server in the cluster takes over the functions of another server in the cluster, in the case of a failure of the first device. The term can also be used for a deliberate transfer of services to another server in the cluster.
  
  

FPE supports local installations in all types of Exchange Server 2007 clusters and cluster-like configurations. FPE is supported on active/passive configurations, but not active/active configurations.

Note:
If your system is configured to run a Network Load Balancer (NLB), there are no special installation procedures for FPE. Follow the instructions for a non-clustered installation (see Installing the product).

Note:
Each node of the cluster is a mailbox-only server (in DAG systems, each node can be a mailbox-only or a bridgehead/mailbox). FPE should also be installed on your Edge and Hub servers for more reliable protection and performance.

FPE recognizes Windows Server 2003 and Windows Server 2008 active and passive clusters. To install FPE in a cluster environment, you must log on to the local computer as a domain user with an account that has local administrator rights. FPE must be installed on each node. All program files must be installed to a local drive.

Features of the installation include the following:

• Configuration data (such as ScanJobs.fdb and Notifications.fdb in Microsoft Forefront Security for Exchange Server Version 10, and Configuration.xml in FPE Version 11) is associated with a Clustered Mailbox Server (CMS), not the physical nodes. Because of this, the data needs to be configured only for each CMS, regardless of how many nodes you have.
  
  
• Similarly, engine definition files are associated with a CMS, so that both active and passive nodes are current.
  
  
• Configuration data kept in the registry is replicated on a CMS basis when the CMS moves from one computer to another during a failover event.
  
  

In Microsoft Forefront Security for Exchange Server Version 10, the Forefront Server Security Administrator should be connected to the CMS. In FPE Version 11, the Forefront Protection 2010 for Exchange Server Administrator Console (FPE Administrator Console) is automatically connected to the CMS.

Each node of a cluster is managed separately through its FPE Administrator Console.

Microsoft Customer Support Services (CSS) supports FPE clustering based on the failover clustering features of the Microsoft Cluster Service (MSCS). Several third-party vendors offer clustering services and solutions that do not rely on MSCS for applicable versions of Microsoft Windows operating system software. Microsoft cannot provide information about the actual performance or interaction of third-party clustering services and solutions that are running Exchange.

CSS will attempt to help you troubleshoot Exchange-related issues when Exchange is installed on a third-party clustering solution. CSS will help until it is reasonably believed that the cause of the issue is an incompatibility between the third-party clustering solution and Exchange. CSS may suggest removing the third-party solution to help resolve the issue, although this is not a precondition to receiving CSS support services. CSS may also refer you to the vendor of the third-party clustering solution for additional troubleshooting support. It is your responsibility to engage the third-party vendor's support organization. CSS will try to provide reasonable assistance in working with a third-party vendor's support organization, however CSS cannot be considered the primary liaison between you and the third-party vendor. It is strongly recommended that you develop support relationships with each vendor whose hardware or software is part of your Exchange solution.

The minimum server requirements for FPE can be found at Verifying system requirements.

Concepts