Share via

Best practices for configuring Forefront Protection 2010 for Exchange

  • Article

 

The following are best practice recommendations for configuring and operating Forefront Protection 2010 for Exchange Server (FPE). As a general rule, the default configuration settings are the recommended settings.

General configuration:

  • A recommended option for managing FPE on multiple Exchange servers, such as in an enterprise, is to use the Microsoft Forefront Protection Server Management Console (FPSMC). It is built to manage multiple instances of FPE. You can download FPSMC from the Microsoft Download Center at the following location: Microsoft Forefront Protection Server Management Console (FPSMC) 2010. Documentation for FPSMC can be found in the TechNet library at Forefront Protection Server Management Console.

    The Microsoft Forefront Protection Server Script Kit also provides multi-server management capability for FPE.

    If you aren’t using a tool or other means to manage multiple servers, you can install and configure FPE on a single Exchange server, and then export and import these configuration settings to additional Exchange servers (keeping in mind that each FPE installation must be performed individually on that server first). For more information, see Exporting and importing configuration settings.

  • If you have not already done so, configure the addresses that FPE considers to be internal and external. For more information, see Identifying external and internal addresses.

  • There are a number of settings and situations that require you to restart services. In the event that FPE does not recognize the current settings, stop and then restart the relevant Microsoft Exchange and Microsoft Forefront Server Protection services. For more information, see Restarting services.

Antimalware scanning:

  • Run a full scheduled scan after installing FPE for the first time. For more information, see Configuring the scheduled scan.

  • Scans targeting large mailbox stores may run for a long time. Running such scans using the on-demand scan is not recommended. Use the scheduled scan instead; for more information, see Scheduling malware scanning of mailboxes and public folders. When using the scheduled scan for a large public folder, you should scan associated subfolders on a rotating basis until you have scanned all the subfolders in the large folder.

  • During a virus "outbreak" scenario, enable the Scan after engine update setting for the realtime scan, causing files to be scanned each time they are accessed after an engine update. You will achieve the best protection because you are always scanning with the latest definitions. When the outbreak passes, disable this setting again, because it can slow system performance.

    You would not normally enable this setting, but if your server has a lot of free capacity and the user experience is not impacted, having this enabled all the time ensures the best possible level of protection. Keep in mind that enabling this setting can have a considerable performance impact on a busy server, as it leads to significantly more scanning. Enabling this setting also automatically enables proactive scanning. With proactive scanning, Mailbox servers that contain public folder databases scan files as they are posted to the server. Proactive scanning also causes a scan of messages in the Sent Items folder in mailbox databases.

    For more information about realtme scanning, see Scanning mailboxes and public folders for malware in real time.

  • The default values for the transport and realtime process counts are 4. On systems with greater than 4 processor cores, performance may be improved by increasing the number of processes towards the total number of CPU cores available. Each additional process will consume additional system resources. When increasing this setting, you should closely monitor resource consumption and performance prior to making additional adjustments. You must stop and then start the relevant Microsoft Exchange services in order for changes to these settings to take effect. For the transport scan, this is the Microsoft Exchange Transport service; for the realtime scan, this is the Microsoft Exchange Information Store service.

  • FPE can scan the actual message body for embedded viruses. Because message body scanning is performance-intensive, the Scan message body setting is disabled by default for the realtime scan. Normally, the best practice is to keep it disabled for realtime scanning except during a virus outbreak that might involve a message body virus. Message body scanning is always enabled for the transport scan.

  • Use inbound, outbound, and internal transport scanning on all servers.

    It is good Internet etiquette to scan your outbound e-mail messages for malware. In addition, this can protect you from legal liability should an infected computer in your organization attempt to send out malware (a common behavior of worms).

  • Change the value of the Maximum container file size: (megabytes) setting in Global Settings – Advanced Options to match your e-mail policy concerning the largest permissible file attachment size. If a filter match or malware is detected, attachments larger than this value will automatically be deleted. For more information about this setting and other threshold levels, see Configuring maximum file sizes and other threshold levels.

Filtering:

  • When selecting scan targets for a scan job (for example, selecting which mailboxes to scan with the realtime scan), be aware that this affects not only antimalware scanning but also any filtering options that are associated with that scan job.

  • The following are the recommended methods for configuring a file filter list:

    • If you want to filter e-mail attachments of a certain file type, create the filter list using the Filter files of specific types AND with specific name patterns option. Set the Filter criteria - by file type selection to the exact file type you want to filter, and in the Filter criteria - by file name section, type an asterisk (*) as the file name. For example, you can set the file type to Windows Executable (exe), and then type * as the file name. This ensures that all executable (exe/dll) files are filtered regardless of their file name or extension.

    • If you want to filter all files with a certain name, create the filter list using the Filter files with specific name patterns option, and then type the file name in the Filter criteria - by file name section. File name filter matching is not case-sensitive. For example: if a virus uses an attached file named Payload.doc, you can specify payload.doc as the file name. This ensures that any file named payload.doc is filtered, regardless of the file type.

    • If you want to filter all files with a certain file extension, create the filter list using the Filter files with specific name patterns option. In the Filter criteria - by file name section, type an asterisk (*), add the extension on which you want to filter, and then add another * (this prevents files with extra characters appended after the extension from bypassing the filter). For example, to filter all files with an .exe extension, type the following file name: *.exe*.

    For more information about file filtering, see Creating a file filter list.

  • To aid in filtering for profanity, example keyword lists in various languages are included with FPE. For more information about using these lists, see Using example keyword lists.

Engine and definition updates:

Use the Universal Naming Convention (UNC) method of updating your engines. That is, use one server (the redistribution server) to download updates from the Microsoft HTTP server and then share those updates among the rest of the servers (the receiving servers) in your environment. After the redistribution server downloads an engine update, it can share that update with any receiving server whose network update path points to it. This can save greatly on Internet bandwidth and make your updates quicker and more efficient.

For redundancy, you may want to configure a second redistribution server. Then you can enter this redistribution server in the secondary update path. If updating from the first redistribution server fails, the latest updates can still be retrieved by the second redistribution server.

Even if you are not using a particular engine, you should still continue updating the engine daily so that if you need to activate it the definitions will be up to date.

For more information about using UNC updating, see Distributing updates by using UNC updating.

Notifications:

In the event that FPE encounters issues and stops scanning properly (for example, if the Exchange Information Store starts and FPE is not hooked in or if the store shuts down abnormally), FPE sends a notification to all the e-mail addresses listed for the Critical error notification. Remember to separate multiple e-mail addresses with the semicolon character (;). Configure this setting as soon as the product is installed. For more information about notifications, see Configuring e-mail notifications.

Incidents and quarantine:

  • There is no hard limit for the incidents database size. The incidents database includes all incident item metadata as well as all quarantined item metadata (that is, database records representing items that have been quarantined, not the actual quarantined items). Therefore, you must monitor your hard disk drive space because the database can grow to fill the available space. For more information about reducing the size of the incidents database, see "Reducing the size of the incidents database" in Managing incidents.

  • The quarantine feature provides an added level of protection because you can retrieve a message that has been incorrectly tagged as malware. However, there is overhead involved in quarantining files, particularly if many viruses are captured each day. Large organizations can block millions of viruses in a month. Many of these, however, might be worms that are never quarantined, because all worms are purged. Ideally, you want to quarantine detected viruses and spyware, but you might determine that the better course is to simply delete them, even at the risk of losing valid e-mail message content. Not quarantining or sending notifications can greatly simplify your antimalware management, but it contains the risk of losing e-mail communications that users may want to receive.

    If you decide to quarantine malware detections, you should be aware of the purge feature, which enables you save space by purging items from the database after a set period of time. For more information, see “Configuring automatic deletion of quarantined items” in Managing quarantine.

High availability:

Note

When operating Forefront Protection 2010 for Exchange Server in a database availability group (DAG) high-availability environment, special considerations should be observed. During a server switchover, the database mailbox will switch to its favored target. Once the switch is complete, all mailboxes will inherit the FPE policies configured on that physical server. Since each FPE server is independent, and not DAG aware, this can lead to multiple policies and multiple incidents/quarantines. Because of this, it is recommended to do the following:

  1. Configure FPE identically, using a PowerShell script, between servers whose preferred database targets require the same policies. For example, if a particular set of users on a particular server have FPE configured with less stringent filtering rules, their target switchover server with FPE configured should also have the same filtering rules, in order to preserve minimal disruption. For more information on using PowerShell with FPE, see Using Windows PowerShell.

  2. A user's Incidents and Quarantine items will be held based on when the database was associated with the physical server where FPE is installed. Therefore, it should be expected that a user's quarantine items can span multiple physical servers, based on the switchover history. Administrators should be prepared to check a user’s switchover history to help reference which physical server to go to in order to release that user's quarantined items for the particular time period.

  3. If a physical server has been offline for some time, the administrator should force an engine update, to ensure all engines are up to date, before initiating database switchover and replication.