Cluster Management Considerations

Applies to: Forefront Server Security Management Console

Microsoft Forefront Server Security Management Console supports Exchange 2003 clusters and Cluster Continuous Replication (CCR) and Single Copy Clusters (SCC) clusters in Exchange 2007. FSSMC manages Microsoft Forefront Security for Exchange Server (FSE) or Antigen for Exchange 9.1 on the cluster (not the cluster itself). These are some important points to consider.

Points to Consider

These are some important points to consider.

• You can deploy FSE to active and passive SCC or CCR clusters in any order. All nodes that are intended to be failover candidates must be running and be part of the cluster group at the time FSE is deployed.
• To install FSE to an SCC cluster or Antigen to an Exchange 2003 cluster, you must enter the shared drive when creating the deployment package. You do this in the Configure Installation Package pane, in the Cluster Match Shared Drive section, by selecting the Cluster Server check box and entering the drive letter, followed by a colon (:). For more information, see "Deployment Jobs" in Manage Jobs.
• Agents are installed on all nodes of the CCR cluster. That is, the cluster is managed as two separate nodes, not as a single virtual server.
• If a standalone server is converted to a CCR node, the agent must be redeployed. If a CCR node is converted to a standalone server, nothing has to be done.
• In Active Mode (that is, when monitoring an active node), the agent behaves normally. You can perform any task that can be performed on a standalone server.
• If the servers switch roles, the agent automatically detects it and switches to the proper mode.
• The status of the CCR nodes is updated every time Statistics Polling is run (every 240 minutes by default, but you can change it under “Global Configuration”). However, status information could be inaccurate if Statistics Polling has not yet run after a failover or handover occurred. Therefore, you should either reduce the polling interval to a smaller value or manually poll before obtaining status information from a CCR cluster.
• Alerts are only triggered when a server is in Active Mode (that is, the server is the active node). The alert returns the physical name of the server, not the virtual name of the cluster.
• If a cluster fails over, outbreak alert data is not carried over between servers. That is, if you had requested that an alert notification be sent when virus detection exceeds 30 messages per hour and a failover occurs after 29 detections, no notification will be sent if only 2 more detections occur on the second server.
• You should schedule jobs on both nodes to be confident that they will run on the one that is active. Since there is no way of knowing which node will be active when a job runs, you are always permitted to schedule a job on the passive node, even if it will not run.
• The Engine Versions report will show data for all active and passive nodes. You should expect the version on a passive node to be the same as, or one version behind, the version on the active node.
• Detection Reports should be generated for both nodes, because the statistical data on one node is not replicated on the other.
• The Retrieving Quarantined Data job should be run on both nodes, because the data on one node is not in sync with the data on the other.
• The Retrieving Remote Log Files Job should be run on both nodes to get the complete log files for the cluster.
• In Passive Mode you can run a scheduled report job.
• In Passive Mode (that is, when monitoring a passive node), some functions can be performed and some can’t be. The following tables indicate which are the permitted functions and which are not.