Share via

Redundancy

  • Article

 

Applies to: Forefront Server Security Management Console

"Redundancy" provides the FSSMC server with fault tolerance. You can install one or more backup FSSMC servers that will automatically replicate data from the primary server and perform mission-critical activities, such as signature updating, if the primary server is not available. A backup server can perform the functionality of the primary server without excessive configuration.

For more information about how the console on a backup server differs from the console of a primary server, see Console Overview.

In order for the backup server to assume the responsibility of propagation and signature updates if the primary server fails, the following data need to be replicated from the primary server periodically:

  • Managed server list
  • Templates
  • Jobs

In anticipation of the primary server being offline at a critical time, you should set up template packages on the backup server to deploy special settings to be used in case of a virus or spam outbreak. Then, if the primary server is down during a virus or spam outbreak, log on to the backup server and run the job to deploy outbreak settings to all managed servers.

You should also consider changing the signature update frequency on the backup server to ensure that your scan engines are as up-to-date as possible.

Create and run a new remote log retrieval job at the end of the day to verify that incidents data can be retrieved and the outbreak settings are taking effect.

Note

The FSSMC redundancy feature is built on the SQL server replication feature. SQL server contains a publisher and a subscriber that map to the primary and backup servers, respectively. If a backup server is disconnected from the primary server for at least 30 days, the SQL subscription will expire. In that case, the replication mechanism will not work (that is, no further data will be transferred to the backup) and replication-related errors will appear in the backup server's notification log. To fix this problem, reinstall FSSMC on the backup server. It is not necessary to manually uninstall the old copy.

Replication Configuration

Once you have created packages and jobs on the primary server, log on to your backup server and configure it to replicate from the primary at a specific time each day.

The replication frequency setting can have important implications for overall FSSMC service performance. You must make a decision, based on the trade-offs in system performance. The shorter the replication frequency, the more assured you are that the data from the primary server is replicated to the backup server. However, the greater the replication frequency, the higher the load exerted on other aspects of the overall FSSMC system and the network environment. This process consumes system resources, and the more often the process is repeated, the greater the impact on the FSSMC server's performance. The network load/traffic will be much higher, because the data is being transferred more often. Also, the processing load on the synchronizing systems is increased as the process occurs more often.

To set up replication configuration

  1. Click Replication Configuration in the Administration section of the Backup server’s Navigation Area. The Replication Configuration work pane appears.

  2. Enter the Start Time for the replication job to begin. The default is 12:00 AM (midnight).

  3. Select the replication frequency. This is either a number of days or every 1, 2, 3, 4, 6, 8, or 12 hours within a single day. The default is one day.

Signature Update Redundancy

The most compelling reason to have a backup server is to ensure uninterrupted signature updates. The scheduled signature update jobs are replicated to the backup server and it will download the signature updates from the Internet at the scheduled time and try to redistribute them to all managed servers. The behavior of the backup server is exactly the same as that of the primary (that is, it will only download a signature update if it is more recent than the current version).

You should verify beforehand that signature updates will occur properly on the backup server.

To verify signature updates

  1. Make sure replication is properly configured.

  2. Take the primary server off the network.

  3. At the scheduled signature update time, check the managed Forefront servers to see whether their engine files are being updated.

What You Can and Cannot Do On the Backup Server

You can perform the following tasks on the backup server:

  • View servers and server groups.
  • View or copy template packages created on the primary server.
  • Add a template package. To differentiate a template package created on the backup server, an “*” is appended to its name.
  • Copy, rename, edit, or delete a template package created on the backup server.
  • View or copy a template deployment, signature redistribution, general options, or remote logs retrieval job created on the primary server.
  • Create new signature redistribution, template deployment, general options, or remote logs retrieval job. To differentiate a job created on the backup server, an “*” is appended to its name.
  • Edit, copy, or delete a signature redistribution, template deployment, general options, or remote logs retrieval job created on the backup server.
  • Run a signature redistribution, template deployment, general options or remote logs retrieval job. Because the backup server has the list of managed servers and the credentials to access them replicated from the primary server, it is able to run these jobs.
  • Check the status of a job.

You cannot perform the following tasks on the backup server:

  • Modify servers or server groups.
  • Modify template packages created on the primary server.
  • Modify jobs created on the primary server.

Notification Logs

The following notification logs are available on the backup server:

  • Deployment
  • General options
  • Log Retrieval
  • Redistribution
  • Replication

For more information about Notification Logs, see Event Logs.