Best practices
Applies to: Forefront Protection 2010 for SharePoint
The following are best practice recommendations for configuring and operating Forefront Protection 2010 for SharePoint (FPSP). As a general rule, the default configuration settings are the recommended settings.
The default for scheduled and on-demand scanning is to scan all sites, including the SharePoint Central Administration sites and all user sites on the SharePoint server. It is recommended that you manually select the user sites you want to scan in order to avoid scanning the SharePoint Central Administration sites.
Scans targeting large sites or many sites 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. When using the scheduled scan for a large site, it is recommended that you scan associated sub-sites on a rotating basis until you have scanned all the sub-sites in the large site.
Before running the scheduled scan or on-demand scan, you should ensure that the Delete corrupted compressed files, Delete corrupted UUEncoded files, and Delete encrypted compressed files settings are disabled (cleared) in the Global Settings – Advanced Options pane (they are disabled by default). This will prevent the inadvertent deletion of files.
Extreme care should be taken when implementing actions for filter lists because they affect files submitted for scanning by SharePoint. This can potentially include ASPX and other operational pages. It is recommended that you tune your filter lists by using an action of Skip detect prior to implementing a Delete or Suspend action.
During a virus "outbreak" scenario, it is recommended that you enable the Scan after engine update setting for the realtime scan, causing files to be scanned repeatedly when accessed after each 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 negatively impact 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.
It is recommended that you 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.
The default value for the realtime process count is 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 Microsoft Forefront Server Protection Controller Service and World Wide Web Publishing Service in order for changes to this setting to take effect.
There are a number of settings and situations that require you to restart services. In the event that FPSP does not recognize the current settings, stop and then restart the relevant FPSP services. For more information, see Restarting services.
To calculate the recommended FPSP scan process count, follow these steps:
Add the count of worker processes to the number of object model applications.
Multiply the sum from the first step by the number of SharePoint antivirus threads.
The FPSP scan process count should be equal to, or slightly less than, the result of the previous steps. For more information about the SharePoint object model, see Server and Site Architecture: Object Model Overview.