Microsoft Forefront Server Protection Blog

11 Languages MUI out of the box

FSSTeam — Fri, 20 Nov 2009 16:28:00 GMT

Forefront Protection 2010 for Exchange Server will soon be available in 11 languages: US English, Japanese, German, French, Italian, Spanish, Korean, Simplified Chinese, Traditional Chinese, Brazilian Portuguese, and Russian. This is the same set of languages that were available in Forefront Security for Exchange Server 2007 but there is a big difference. In the 2007 release the product was single language, which means you had to choose which language you wanted and stick with it. In the 2010 release we are using multilingual technologies to simplify the user experience.

How does it work from a user's perspective? It is easier than ever, just download “the” package for Forefront Protection 2010 for Exchange Server (there is only 1 package, no need to choose a language) and run it. If your language is in the list, the product will display everything in the language you are currently using. If your language is not in the list, it will be displayed in English.

Multilingual technologies can be particularly helpful for very large multinational organizations distributed geographically. Imagine a mail security administrator working in the US feeling right at home because everything shows up in English; then when the 24x7 shift changes and it is time for the administrator working in Japan to work with the product, he will be able to run it comfortably in Japanese; finally when the administrator in France takes over, she will have no difficulties because the product will be displayed in French. We are talking about the same installation of the product, running in the same machine, not multiple installs. This benefit is directly available from the default installation; there are no additional patches or language packs to apply.

The language displayed is based on the user settings in Windows. For the above scenario to work correctly, all that needs to be done is for each administrator to have different accounts and use the control panel in Windows to select their language (which we expect to be the case for the multinational scenario described here).

The only caveat I should mention in our multilingual scenario is in the defaults for user-configurable text, for example, the message that is sent out as a replacement when a virus is detected. This text is configured at install time using the language for the person running setup. Users can later configure it to any language they want, possibly a multilingual message if appropriate, but that is a manual step that needs to be done afterwards. The language used at install time will also affect minor items such as names in the Start menu and service names.

There are a few questions that may arise due to these localization changes:

Q: Can I see a different language on a server running a localized administrator console? For example, can I view the English Forefront administrator console on a server where Windows is configured to display German text?

A: Yes, the Forefront administrator console will be displayed in the language of the current user. Even if the server is configured to display German text by default, you can access the server using an account configured for displaying English. Forefront will respect the account preferences rather than the server default.

Q: I only need one language, so how will this change impact disk space on my server? Can I just delete the other language packs?

A: The language packs take up about 4 MB per language, which should not have a big impact on your server. If you do need to free up some space, you can delete the language files that are not used.

For example, if the ja-jp, de-de, fr-fr, it-it, es-es, ko-kr, zh-cn, zh-tw pt-br and ru-ru folders are all deleted, the only effect is that the program will always be displayed in English but everything else in Forefront Protection 2010 for Exchange Server will run exactly the same as it did before deleting the folders.

Eusebio Rufian-Zilbermann

Forefront Server Protection

How do I disable these engine end-of-life notifications I am receiving from Antigen and Forefront?

FSSTeam — Mon, 16 Nov 2009 15:53:00 GMT

Many of you may have noticed warning notifications about the upcoming end-of-life date for several antivirus engines and the Spamcure antispam engine being generated by Antigen and Forefront Server Security. These notifications are intended to ensure that you take the appropriate steps to keep your antivirus and antispam protection up to date when these engines are retired. (For more information, read the most recent blog article about the upcoming engine changes.)

We have received several requests, however, for information about disabling these notifications that are generated by Antigen for Exchange and SMTP Gateways and Forefront for Exchange, SharePoint, and Office Communications Server related to deselecting the antivirus engines about to be retired. This article provides instructions for deselecting engines from scan jobs, which will disable the notifications for affected Forefront and Antigen products.

Stopping the notifications

To stop these notifications, you must stop using the engines that are being discontinued in the Forefront/Antigen products. The steps to disable the engines in the products are listed below. If you are aware of the engine retirement and wish to suppress the errors temporarily without disabling the engines, you need to contact Microsoft support for help.

Follow these steps to completely disable the specific antimalware engines within the Forefront and Antigen products.

Note: The steps below need to be followed for the AhnLab, CA, and Sophos, and the Spamcure engines, which are being retired on December 1, 2009. Customers using SpamCure need to ensure that they are using Antigen 9 with service pack 2 that was released on July 1,2009. For additional information, refer to Antimalware Engine Notifications and Developments.

To properly disable an engine and definition updates, you will need to:

1. Remove the engine from all antivirus scan jobs.

2. Disable definition updates for the engine.

3. Remove the engine from the Quick Scan job. (This step is not necessary for Antigen SMTP only installations as the Quick Scan functionality is disabled in this configuration.).

1. To remove the engine from all antivirus scan jobs

a. Open the Forefront/Antigen Administrator.

b. Under Settings, select Antivirus.

c. Deselect the engine you want to remove under “File Scanners” for each scan job that is listed there.

d. Click the Save button.

2. To disable engine updates

a. Open the Forefront/Antigen Administrator.

b. Under Settings, select Scanner Updates.

c. Select the engine you want to disable updates for and click the Disable button on the right-hand side to disable scheduled updates for this engine.

d. Click the Save button.

3. To remove an engine from the Quick Scan job

a. Open the Forefront/Antigen Administrator.

b. Under Operate, click on Quick Scan.

c. Deselect the engine under File Scanners.

d. Click the Save button.

IMPORTANT: Customers using Antigen version 9 with Service pack 2 (released as of July 1^st) need to apply Rollup 1 that was released in October 2009. The rollup contains a needed fix for an issue regarding notifications when Antigen is installed on a SMTP only configuration. For more information on the fix as well as the download location, please see the following Kb (http://support.microsoft.com/kb/975355#4).

Krishnan Venkatasubramanian

Program Manager - Forefront Server Protection

Forefront Protection 2010 for Exchange Server RTM Capacity Planning Guidance

FSSTeam — Fri, 13 Nov 2009 01:09:00 GMT

The purpose of this article is to provide guidance for Forefront Protection 2010 for Exchange Server (FPE) capacity planning. This includes hardware information such as the number of processing cores and memory requirements. The guidance will provide information that will utilize the existing Forefront Security for Exchange Server (FSE) SP1 capacity planning tool for Exchange 2007 deployments and then provide enough detailed information to help with new Exchange 2010 deployments.

The goal is to provide guidance in-line with the documentation provided by Exchange. In all cases, this is the underlying data that was used to develop the guidance provided within this document.

A tool and additional updates to this document will be available in the future.

Note: All organizations are unique and they have requirements, policies, behaviors, and cultures that guide their requirements and inform hardware purchasing decisions. This document provides information about the additional load created by Forefront Protection 2010 for Exchange Server (FPE) on sample server environments and provides guidance to help with capacity planning decisions. This information should be combined with your experience, the Exchange capacity planning guidelines, and your general knowledge of your organization and IT landscape.

Reference Architectures and Server Roles

Enterprise Reference Architecture

There are two main reference architectures that are used for FPE deployments. The first is the Enterprise Reference Architecture show in Figure 1. This is a scalable unit that is intended to be deployed within a larger organization and is composed of an edge server, a hub server, multiple mailbox servers, an active directory server and a CAS server.

Figure 1. Enterprise Reference Architecture

Standard Reference Architecture

Figure 2 depicts the Standard Reference Architecture, which is intended to be a scalable unit, targeted at small to medium sized organizations. This architecture is composed of a dedicated edge server, one or more multi-role servers that encompass the hub server, mailbox server and CAS server roles and then a dedicated active directory server.

Figure 2. Standard Reference Architecture

Server Roles

Given the two reference architectures, the unique server roles are identified as follows:

FPE Edge Server

This is where the SMTP data stream comes into an organization and where message hygiene is performed. Message hygiene includes antispam as well as antivirus, antispyware and custom filtering. The FPE protection technology software resides on this server along with the Exchange Transport services. The messages that pass an enterprise’s message hygiene will be routed to the appropriate hub server for additional processing/routing. Messages that have undergone scanning as part of the message hygiene at the Edge do not have to be scanned again at the hub.

FPE Hub Server

This server accepts routing SMTP information from the FPE edge server, can perform additional message hygiene – based on configuration, and then routes the messages to their appropriate mailbox server or additional hub servers. The FPE protection technology software and the Exchange Transport services reside on this server.

FPE Mailbox Server

The FPE mailbox server accepts the incoming messages from the hub and can perform additional message hygiene – based on configuration. In addition, the mailbox server can perform scheduled scanning requests, and on-demand scanning requests. The FPE protection services in addition to the Exchange Mailbox services reside on this server.

FPE Multi-Role Server

This server contains the capabilities of the FPE hub server, FPE mailbox server, and Exchange CAS server in one server. Hence it provides the aggregate functionality.

FPE Server Performance Guidance for Exchange 2010 Deployments

Each of the FPE server roles are broken down and guidance is then provided.

FPE Edge Server

Factors Impacting Performance

On the FPE Edge Server it is critical to understand the load requirements for performing message hygiene. This can be broken down into two main components, SMTP traffic that results in messages delivered to a user in your organization and SMTP traffic that is detected as spam and/or malware. The FPE Edge Server can also be configured to send outgoing email from your internal users but the load from this activity is fairly minimal.

Another critical component for evaluating proper sizing on the FPE Edge Server is the configuration. There are several ways the FPE Edge Server can be configured, but only a few select ones are highlighted for sizing.

Note: Additional configuration information will be provided in an updated Capacity Planning Tool for FPE 11.0 RTM.

The three main areas of configuration are:

Engine Management

Engine management has two different components. The first is the Intelligent Engine Management (IEM) configuration which allows the user to have FPE automatically update and select the most appropriate engines to use based on a the default Engines and Performance setting of scanning with all available engines. This results in all engines scanning incoming mail when available. (Availability based on non-side-by-side engine updating.) This setting can be modified to manually select a certain number of engines.

The second component configures the number of engines used for each scan. Again, by default, the subset of available engines will be selected to perform message hygiene. The user can select a setting that ranges from always scanning with all the enabled/selected engines to only scanning with one engine

Enabling Premium Antispam

By default, the Premium Antispam functionality is enabled on all FPE Edge Servers. This can be disabled on the FPE Edge Server.

Number of Scanning Processes

By default, the number of scanning processes is set to 4. That means that there will be 4 processes utilized to perform malware message hygiene.

Performance Data

Figure 3 shows the CPU performance of a recommended FSE Edge configuration. This graph shows the relative performance of the previous product – FSE against the current version of the product, FPE 2010. There were samples taken and then a linear interpolation to see the projected CPU utilization against the incoming message rate.

Processors: 2x2 => 4 cores; Intel Core 2 Duo; 2.66 MHz

Memory: 4G RAM

Message Mix: Sample of Microsoft IT

Configuration: IEM (5 Engines), Scan with available engines => Bias: Prefer Certainty (No A/S)

Scanning Processes: 4

Figure 3. FPE 2010 CPU Utilization

Figure 4 shows the CPU performance relative to the number of scanning processes on a higher performance machine – 8 cores. This graph represents the scale up capacity using the default configuration verses a configuration that is tuned for a scanning process per core. The measurements represent the areas for normal throughput without the submission queue backing up.

Note: the submission queue starts to back up even though the CPU utilization never reaches more than an aggregate 23% of the server.

Processors: 2x4 => 8 cores; Dell R610; 2.93 GHz Xeon

Memory: 16G RAM

Message Mix: Sample of Microsoft IT

Configuration: IEM (5 Engines), Scan with available engines => Bias: Prefer Certainty (No A/S)

Scanning Processes: 4 and 8

Figure 4. Throughput Scalability on 8 Core Server

During these tests, the malware scanning detection was turned off with only the premium antispam capabilities enabled. The CPU utilization increased 3.3% on an incoming message rate of 100 messages per second. This was relative to the baseline numbers with FPE 2010 enabled on the Exchange Edge server w/o any message hygiene.

Memory measurements were also conducted on a variety of configurations and the recommendations are captured in http://technet.microsoft.com/en-us/library/cc482970.aspx. The overall memory footprint of the product is larger than that of its predecessor due to a new service. This increases the memory footprint approximately 650 MBs.

Capacity Planning Guidance

Processor

The recommendation is to use a 4 core server (not hyper-threaded) for the FPE Edge. Although the product does support 1 and 2 core server configurations, this will impact your overall throughput. You can also use more than 4 cores, however, in doing so, you should also change the configuration of the number of scanning processes to align with the number of cores on your server. The default configuration is 4 scanning processes and this will need to be increased to 8, for an 8 core server – for example.

Memory

The memory recommendation is outlined in http://technet.microsoft.com/en-us/library/cc482970.aspx. Overall, you should size your server configuration for at least 2GB over the recommended Exchange 2010 Edge Server guidance.

Scaling Up / Out

The default configuration, at about 75% utilization, will allow for approximately 45 incoming SMTP messages per second. This is on top of whatever incoming rate you experience for SPAM. The 45 incoming SMTP messages per second are those messages that are eventually routed to the Hub servers. This is with 5 scanning engines enabled.

If you desire to support a larger incoming rate, you can either (a) increase the number of cores on your server (b) decrease the number of engines used by each of the scanning processes, (c) or add another FPE Edge Server. The data on how this will impact scale will be available in a future technet article. However, there can be significant scale gain by going from 5 scanning engines to 4, or 3.

FPE Hub Server

The FPE Hub Server is a very similar configuration to that for the FPE Edge Server. There are two significant differences. First, the premium antispam functionality is not enabled by default on this particular role and, if an FPE Edge Server is forwarding mail to a FPE Hub Server, then message hygiene has already been accomplished except in cases where the configuration differs from the default. Hence, the message hygiene provided by the FPE Hub Server is for internally originating mail.

Factors Impacting Performance

Using these calculations and the numbers from the FPE Edge Server, at peak times you will realize a message rate of ~8 messages per second to be scanned

Performance Data

The guidance from Exchange 2010 for a user with 50 messages per day is 1000 mailboxes per core. Using the default configuration, this is 4000 mailboxes that send/receive 50 messages per day on the recommended processor configuration. This results in a peak realization of approximately 8 messages per second that will require message hygiene from the Hub as it routes the messages.

Capacity Planning Guidance

Processor

The recommendation is to use a 4 core server (not hyper-threaded) for the FPE Hub Server. Although the product does support 1 and 2 core server configurations, this will impact your overall throughput and hub to mailbox fan-out. You can also use more than 4 cores, however, in doing so, you should also change the configuration of the number of scanning processes to align with the number of cores on your server. The default configuration is 4 scanning processes and this will need to be increased to 8, for an 8 core server – for example.

Memory

Hub to Mailbox Fan-Out

Based on the recommended hardware, with 5 scanning engines and fully loaded mailbox servers being serviced by the hub, there is a 1:5 hub to mailbox relationship. In terms or cores, 1 core can support a downstream of 5000 users that send/receive 50 messages per day. You can scale this linearly, so if the representative users send/receive 100 messages per day, the hub can support 2500 per core; 200 sent/received per day yields 1250 downstream users per core.

Scaling Up / Out

If you desire to support a larger hub to mailbox ratio, you can either (a) increase the number of cores on your server, or (b) decrease the number of engines used by each of the scanning processes. The data on how this will impact scale will be available in a future technet article. However, there can be significant scale gain by going from 5 scanning engines to 4, or 3.

FPE Mailbox Server

Factors Impacting Performance

There are three factors that impact performance on the mailbox server: scanning of mailboxes via schedule and on-demand scan, the configuration of the server, and the load of the users that generate traffic that require message scanning.

The based paradigm that aligns with Exchange is a user that sends/receives a total of 50 messages per day that average 75 KBs/message. Out of the 50 messages per day, an estimated 20% are sent, and estimated 25% of the remaining 80% are received from the internet, and the remaining 75% of the 80% are received from internal recipients. Most of the activities that generate real-time scanning will be on-access scanning of the messages. This traffic can be modeled conservatively by assuming 20% of all access mails will be scanned out of two times the number of mails received on a daily basis. This is constant given the correlation between the Exchange server recommendations and the mail being received.

Two areas in configuration need special attention. First, the number of engines used in scanning on the FPE Mailbox Server role. As with all other roles, the number of engines will impact performance. Secondly, the user can enable rescanning of the messages – referred to as proactive scanning, if they enable scanning on signature updates.

Scheduled scanning is intended to run on a schedule and will scan all the mailboxes serviced by the Exchange Mailbox Server role. This should not be done during the day as it will significantly impact the overall performance of the mailbox server. On-demand scan is used to scan a small set of mailboxes at any given time. This will introduce a temporary performance impact on the mailbox server but is recoverable and dependent upon the number of mailboxes to be scanned and their size. Given the variety of the inputs for on-demand scan it cannot be adequately modeled to determine the overall impact on the mailbox server.

Performance Data

The guidance from Exchange 2010 for a user with 50 messages per second is 1000 mailboxes per core. Using the default configuration, this is 4000 mailboxes that send/receive 50 messages per second on the recommended processor configuration. Using the conservative approach of 20% of messages rescanned per user on twice the set of incoming messages, the impact of the scanning and overhead of the FPE protection software should not exceed 20%.

Capacity Planning Guidance

Processor

The recommendation is to use at least a 4 core server (not hyper-threaded) for the FPE Mailbox Server. Please consult the Exchange 2010 processor guidelines and make sure the minimum requirements are met. If using more than 4 cores, you must change the configuration of the number of scanning processes to align with the number of cores on your server. The default configuration is 4 scanning processes and this will need to be increased to 8, for an 8 core server – for example.

Memory

Scaling Up / Out

In terms or cores, 1 core can support 20% less than the Exchange 2010 recommended users per core. For example, for a profile users receiving and sending 50 messages per day, 1000 users can be supported per core for an Exchange 2010 mailbox server. With FPE installed on the mailbox server, the value will be 20% lower, thus 800 users per core. Hence, you can up by sizing your mailbox server appropriately with more cores, or scale out by adding additional mailbox servers to support your profile number of users. Please refer to Microsoft Exchange Server Profile Analyzer for help in identifying our user requirements on the Mailbox server.

The 20% factor is with the default IEM and 5 engines. You can reduce this overall impact by changing the number of engines used to scan on the Mailbox server.

FPE Multi-Role Server

The FPE Multi-Role Server supports the FPE Hub functionality as well as the FPE Mailbox functionality. In addition, the CAS server may also be hosted on this machine. Hence, understanding the performance implications are a bit more complicated, especially when the FPE Hub server is really used as a message hygiene server w/o an associated FPE edge role somewhere in the organization.

Factors Impacting Performance

The main factor impacting performance is the overall responsibility of the server that directly relates to the expected load it must handle. In general, the Hub Server role is not meant to be the main message hygiene role in an organization and our assumptions are that it is not in this case.

In addition, the server has 8 total scanning processes associated with FPE protection technologies – 4 dedicated to the FPE Hub Server role and 4 dedicated to the FPE Mailbox Server role. This impacts the overall scanning throughput capabilities.

Performance Data

In lab measurements, the overall impact of the message scanning throughput is roughly a 25% impact. Exchange recommends no more than 500 users per core on a multi-server role configuration based on a user sending/receiving 50 messages per day. This leads to an aggregate impact of ~6.2 scanning messages per second on the server which correlates to 10% cpu impact. When factoring in the 25% scanning impact, this comes out to a 12.5% reduction in the number of users that can be supported on a multi-server role with FPE protection technologies installed.

Messages/Sec per 1000 users (Mailbox) : ((1000*40*2)/5) / (80*60*60/2) = 1.11

Messages/Sec per 1000 users (Hub) : (1000*(.75*.8*50)/(8*60*60/2)) = 2.083

Total impact => 3.19 messages/sec per 1000 users

Capacity Planning Guidance

Processor

The recommendation is to use at least a 4 core server (not hyper-threaded) for the FPE Multi-Role Server. Please consult the Exchange 2010 processor guidelines and make sure the minimum requirements are met. If using more than 4 cores, you must change the configuration of the number of scanning processes to align with the number of cores on your server. The default configuration is 4 scanning processes for Hub and 4 for Mailbox. Hence, you should increase the numbers proportionately on if using a server with more than 8 cores.

Memory

The memory recommendation is outlined in http://technet.microsoft.com/en-us/library/cc482970.aspx. Overall, you should size your server configuration for at least 3.5GB over the recommended Exchange 2010 Edge Server guidance.

Scaling Up / Out

The FPE Multi-Server role can support ~437 users per core that send/receive 50 messages per day. You can sale up by (a) increasing the number of cores on your multi-server role, (b) decreasing the numbers of engines used on the hub server role and mailbox server roles, or (c) migrating users to additional hardware.

FPE Server Performance Guidance for Exchange 2007 Deployments

Please reference the previous tool for FSE SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=522da65d-5263-4f5d-b929-8428a394b9af&displaylang=en

Please use this tool with the following guidance:

(1) If using the recommended hardware of a 4 core processor, you should be able to reduce CPU utilization by ~ 20% and increase the number of supported users by 25%.

(2) Please increase the amount of expected server memory by 500 MBs.

Frank Trujillo

Senior Program Manager

Forefront Protection 2010 for Exchange Server now available!

FSSTeam — Thu, 12 Nov 2009 21:10:00 GMT

I am excited to announce the availability of Forefront Protection 2010 for Exchange Server for use with Exchange 2010 and Exchange 2007 SP1. The team is ecstatic about this release and above is a conceptual box we printed out and signed in our ship celebration.

This release brings:

· Premium antimalware via multiple antimalware engines which provide 38 times faster detection than any single vendor solution according to AV-test.org

· Premium antispam that is deeply integrated with Exchange and provides a 99% catch rate with less than 1 in 250,000 false positives

· Innovative, hybrid solution to optimize email hygiene in the cloud with joint on-premises management and monitoring

· Deeper integration with Microsoft technologies and infrastructure, such as SCOM and PowerShell

· Brand new user interface and easy-to-use console that allows administrators to rapidly identify and respond to security threats

· Set and forget smart defaults.

· Premium Certification from West Coast Labs and Gold certification from VB.

And so much more....

Here are some testimonials from customers in our Technology Adoption Program, who deployed and provided feedback on pre-release versions of the software.

“Easy and straightforward, everyone can install FSE without any problems, because the setup is streamlined and easy” – Sporton International Inc
“I really like FPE.. it is easy to deploy and easy to configure and does what it is supposed to do." -University of Mainz
“The new anti-spam agent has gotten some pretty amazing results and [the] DNSBL is just as amazing. Their new backscattering option should also prevent the VPs from complaining when they get NDRs for spam they never sent…Sorry [name withheld] your anti-spam is nothing compared to Forefront. I was very happy to enable content filtering on Forefront today - Marquette University
“Two days ago, we installed another E2K10 with FSE Edge server and removed our last E2K7 Edge. The SPAM for me and almost all of my colleagues has gone to zero. No SPAM, None, Nadda, nothing! This is now a truly enterprise AS/AV product… Well done [Exchange] Edge and FSE teams!!!! – Horizon Consulting
“FPE UI organized in an easy-to-understand style and our IT can learn how to use all the features within 30 minutes. We don’t need to study all the contents of documentation in order to use it. Most of the features are straightforward and we can immediately know how to use most of them.” – Sporton International Inc

Let me close out by showing you some screenshots and telling you where you can learn more.

Dashboard with summary information about the system:

Anti-spam Configuration Screen:

You can find out more about this release at the links below. And stay tuned into this blog for continuing discussions and answers to your questions about Forefront Protection 2010 for Exchange Server!

1. Official Microsoft Site

2. Trial download

3. White Papers

4. TechNet Library documentation

We hope you will give Forefront Protection 2010 for Exchange a try.

Thank You,

Neetu Rajpal

Principal Group Program Manager

Forefront Protection for Exchange Server

Correction to Antigen 8 end-of-life date

FSSTeam — Thu, 12 Nov 2009 15:24:00 GMT

Hey folks-

On October 26th we posted an article here to remind Antigen users about the end-of-life date for Antigen 8 for Exchange and SMTP Gateways and provide guidance for migrating to Antigen 9. The article said the end-of-life date is December 1, 2009, but it should have said December 31, 2009. The article has been corrected.

You can view the corrected article here: http://blogs.technet.com/fss/archive/2009/10/26/migrating-from-antigen-8-products-to-antigen-9-or-forefront-products.aspx

Keep fighting that malware!

Michel LaFantano
FSP UA Lead

Rollup 1 for Antigen 9.0 with Service Pack 2 has been released

FSSTeam — Mon, 09 Nov 2009 20:48:00 GMT

Please use the following link to download Rollup 1 for Antigen 9.0 with Service Pack 2.

http://support.microsoft.com/kb/975355

This rollup includes solutions to issues with the Cloudmark antispam feature released in Service Pack 2. Listed below are issues resolved with this rollup release:

· Rollup 1 for Antigen for Exchange version 9.0 with SP2 contains additional diagnostic logging features for the Cloudmark engine

· The StarEngine service is stopped when SpamCure is deselected

· Scan engine updates fail and the Antigen logs do not provide a valid error

· Mail is not scanned after you apply a new template in Antigen 9.0

· The AntigenClient.exe process in Antigen for Exchange version 9.0 may crash. This generates a Dr. Watson crash that references Bucket ID 1177692600

· Engine deprecation notifications continue to be sent even though the engine was disabled from all scan jobs and scanner updates.

· AntigenService crashes in Antigen 9.0 after you save changes that you made in the Antigen General Options panel

· Antigen 9.0 may detect that valid Office 2003 Word documents contain CorruptedCompressedFile viruses

· Antigen 9.0 may generate the following error in the ProgramLog.txt: "ERROR: AntigenInternet process returned 80010105 while processing message"

· A scan engine update fails and generates a warning in the ProgramLog.txt file

As a reminder, please review the following information regarding upcoming antivirus and antispam engine changes on Dec. 1, 2009:

Antimalware Protection

The AhnLab, CA, and Sophos engines will be retired on Dec. 1, 2009. As of this date, customers will not receive any updates for these retired engines. In order to make sure your Antigen and Forefront products continue to scan efficiently and effectively for malware, any customers running the AhnLab, CA or Sophos engines must DISABLE these engines before Dec. 1, 2009 and select from the new set of five engines – Authentium, Kaspersky, Microsoft, Norman, and VirusBuster.

Antispam Protection

One of the most important changes in our engine revision strategy is moving to the Cloudmark antispam engine*, which provides 99%+ detection rate and less than 1 in 250,000 false positives (West Coast Labs). The Mail-Filters SpamCure antispam engine will be retired on Dec. 1, 2009. Customers using Antigen products for antispam protection must upgrade to the latest service pack releases listed below BEFORE DEC. 1, 2009 to maintain their antispam defenses. This is the only way to gain access to the new Cloudmark engine. The service packs can be accessed on the Microsoft MVLS and VLSC sites:

- Antigen for Exchange Server with Antigen Spam Manager 9.0 with SP2

- Antigen for SMTP Gateways with Antigen Spam Manager 9.0 with SP2

For more information on the engine revision strategy, see the Antimalware Engine Notifications and Developments Web page or contact Forefront Contract Administration . Again, we strongly urge all customers to update to the newest service packs before Dec. 1, 2009 to get the full protection benefits of the Forefront and Antigen server products.

Brita Jenquin

Sr. Product Manager

Action Required by Dec. 1, 2009: Keep your Protections Current!

FSSTeam — Mon, 09 Nov 2009 20:47:00 GMT

As we announced on July 1, 2009, Microsoft is revising its engine mix on Dec. 1, 2009 for the Forefront and Antigen products. This change will allow customers to utilize a set of engines that help optimize detection, while also allowing us to invest in new areas for increasing overall protection for customers.

Antimalware Protection

The AhnLab, CA, and Sophos engines will be retired on Dec. 1, 2009. After December 1st, customers will not receive any updates for these retired engines. In order to make sure your Antigen and Forefront products continue to scan efficiently and effectively for malware, any customers running the AhnLab, CA, or Sophos engines must DISABLE these engines before Dec. 1, 2009 and select from the new set of five engines – Authentium, Kaspersky, Microsoft, Norman and VirusBuster.

- SPECIAL NOTE: Antigen for SharePoint 8.0 and Antigen for Instant Messaging 8.0 customers – In order to gain access to the new engine set and provide optimal protection for your messaging and collaboration environments, please download the Service Pack 1 releases of these products on the MVLS or VLSC site prior to Dec. 1, 2009. The updates for the new engine set will use a new update infrastructure as of Dec. 31, 2009 – the Service Pack 1 releases will allow you to continue to receive updates correctly from their new location.

- SPECIAL NOTE: Antigen for Exchange 8.0 and Antigen for SMTP Gateways 8.0 customers –These products will end of life on Dec. 31, 2009. Customers must upgrade to Antigen 9.0 for Exchange before this date, as the product will no longer continue to receive antimalware updates starting Jan. 1, 2010. With the retirement of the CA, Sophos and AhnLab engines on Dec. 1, customers running Antigen for Exchange 8.0 or Antigen SMTP Gateways 8.0 will only be protected by the Norman engine. For customers who need to continue using this product between Dec. 1, 2009 and the end-of-life date of Dec. 31, 2009, please contact Forefront Contract Administration for access to the revised engine set.

- SPECIAL NOTE: Forefront Security for Office Communications Server customers –

The current engine set includes the CA Vet engine that is scheduled to be retired Dec. 1, 2009. A license file download has been created to provide Forefront Security for Office Communications Server customers with access to the revised set of engines available as of 12/1/2009. It replaces the retired CA Vet engine with the Authentium Command engine.

Antispam Protection

The Mail-Filters SpamCure antispam engine will be retired on Dec. 1, 2009. Customers using Antigen products for antispam protection must upgrade to the latest service pack releases listed below BEFORE DEC. 1, 2009 to maintain their antispam defenses. This is the only way to gain access to the new Cloudmark engine. The service packs can be accessed on the Microsoft MVLS and VLSC sites:

- Antigen for Exchange Server with Antigen Spam Manager 9.0 with SP2

- Antigen for SMTP Gateways with Antigen Spam Manager 9.0 with SP2

Brita Jenquin

Sr. Product Manager

*Please note: Customers using Forefront Security for Exchange Server will get access to the Cloudmark engine in the next version release – Forefront Protection 2010 for Exchange Server – scheduled to be available in Q4 CY09.

Join the Forefront Protection 2010 for SharePoint TAP Program

FSSTeam — Thu, 05 Nov 2009 20:57:00 GMT

Forefront Protection 2010 for SharePoint is the next generation of Forefront Security for SharePoint.

We are currently recruiting customers to join our TAP program for this product. By participating in the Forefront TAP program, you will have the opportunity to gain exposure to this new release prior to general availability. In addition you will have the opportunity to provide feedback that will help Microsoft improve the quality of the release.

As part of the TAP program, you will be required to install the product and provide feedback on a regular basis. Feedback usually involves email status and occasional meeting with members of the Forefront product team.

If you are interested in joining out TAP program please fill out a TAP Nomination Form at:

http://connect.microsoft.com/forefrontsecurity/InvitationUse.aspx?ProgramID=3398&InvitationID=FS-RMY4-QD8H

For questions regarding connect site please contact: v-ameber@microsoft.com

Forefront Server Protection and Support for Windows 2008 R2

FSSTeam — Fri, 30 Oct 2009 14:17:00 GMT

We have been receiving questions about our support for Windows Server 2008 R2, so we would like to clarify the information about our support for the release. The following products are designed to be compatible with Windows Server 2008 R2:

· Microsoft Forefront Protection 2010 for Exchange Server (FPE)
Microsoft Forefront Protection 2010 for Exchange Server will be available in Q4 2009.

· Microsoft Forefront Protection 2010 for SharePoint (FPSP)
Microsoft Forefront Protection 2010 for SharePoint will be available in Q1 2010.

· Forefront Server Security for SharePoint
Microsoft Forefront Server Security for Share Point version 10 with Service Pack 3 and later versions are supported.

Additionally, support policy for running Microsoft server software, desktop applications, and technologies running on Windows Server 2008 R2 can be found at:

http://www.microsoft.com/windowsserver2008/en/us/supported-applications.aspx

At this time Microsoft Antigen 9.0 for Exchange / SMTP Gateways and Forefront Security for Exchange Server 10 are not compatible with Windows Server 2008 R2.

Krishnan Venkatasubramanian

Program Manager

Forefront Server Protection

Antigen 8 for SharePoint Service Pack 1 and Antigen 8 for IM Service Pack 1 are now available!

FSSTeam — Wed, 28 Oct 2009 15:50:00 GMT

The Forefront Server team is pleased to announce that Antigen 8 for SharePoint Service Pack 1 and Antigen 8 for IM Service Pack 1 are now available for download. It is important for customers to upgrade to these service pack releases before the AV engine mix is changed on December 1^st, 2009 (as announced on July 1^st, 2009). Previous builds of the product will still function after December 1^st, but only one engine will be updating (Norman).

Another important thing to note is that these service packs update engines from the MICROSOFT.COM download location used by all the other Forefront Server products. This is important as the SYBARI.COM update location will no longer be available as of 2/1/2010.

The service packs can be downloaded from the Microsoft Volume Licensing Service Center by opening the “Servers” group and finding the corresponding Forefront Server product. Antigen 8 for SharePoint SP1 (part number X16-09934) can be found under “Forefront Security for SharePoint with Service Pack 3”. Antigen 8 for IM SP1 (part number X16-09863) can be found under “Forefront Security for Office Communications Server”.

Avoid any gaps in your multi-engine AV protection. Upgrade today!

Tom Canino

Lead Program Manager

Forefront Server Team

Migrating from Antigen 8 Products to Antigen 9 or Forefront Products

FSSTeam — Mon, 26 Oct 2009 18:09:00 GMT

Because Antigen 8 for Exchange and Antigen 8 for SMTP Gateways are reaching their “End of Life” date on December 31, 2009, you will need to migrate to Antigen 9 or the appropriate Forefront product if you are currently running either of these products.

Additionally, the Antigen 8 for IM and Antigen 8 for SharePoint products will also eventually reach their own End of Life dates, and you will also have to migrate off of these products and onto supported versions.

The recommended procedures for migrating from Antigen 8 products to Antigen 9 or Forefront products are provided in this article.

Migrating from Antigen 8.0 for Exchange to Antigen 9.0 for Exchange:

You may upgrade Antigen 8 for Exchange to Antigen 9 for Exchange in one of two ways – by using a management tool (the Antigen Central Manager [ACM]) or by performing the upgrade locally on the Exchange server.

Note: You must be running Exchange 2000 or 2003 to upgrade from Antigen 8.0 to Antigen 9.0. If you are running Exchange 5.5 you must first uninstall Antigen 8.0, upgrade Exchange to 2000 or 2003 following Microsoft Exchange upgrade procedures, and then install Antigen 9.0.

To upgrade Sybari Antigen 8.0 SR3 to Microsoft Antigen 9.0 using a management tool, follow these steps:

1.	Download the Antigen 9.0 installation package, and save it to a temporary folder.
2.	Double-click the Antigen 9.0 installation package to extract the files.
3.	Open the Antigen Central Manager.
4.	On the Jobs menu, click Default Options.
5.	In the Global Settings dialog box, enter the source folder name, add the location of the files that you have extracted in step 2, and click OK.
6.	On the Jobs menu, click Create Job.
7.	In the Task box, click to select Install.
8.	Click Add to add the Antigen 8.0 SR3 server that you want to upgrade to Antigen 9.0.
9.	Click Options to open the Installation Options dialog box.
10.	Verify the information.
11.	Click OK to close the Installation Options dialog box.
12.	Click OK to close the Create Job dialog box.
13.	Select the installation job that you created, and click the green arrow to start the job.
14.	When the install has completed successfully, the following message will appear under Status in the ACM – “The job has completed successfully.”

To upgrade Sybari Antigen 8.0 SR3 to Microsoft Antigen 9.0 locally, simply double click the Antigen 9 for Exchange Setup.exe that you have previously downloaded from the Microsoft Volume License Site and following the prompts in the install.

For more information about the Antigen 9.0 for Exchange install, see Chapter 2 - Installing Microsoft Antigen for Exchange in the Antigen for Exchange User Guide found here:

Migrating from Antigen 8.0 for Exchange to FSE:

Since FSE is only supported on Exchange 2007, you must first uninstall Antigen 8.0 for Exchange, upgrade your Exchange 2000 or 20003 installation to Exchange 2007 following the Exchange 2007 product documentation, and then perform a fresh installation of FSE.

- To uninstall Antigen 8.0 for Exchange, stop all Antigen and Exchange services in the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for Exchange installation folder (default path of Program Files\Sybari Software\Antigen for Exchange).

- To upgrade Exchange 2000 or 2003 to Exchange 2007, follow the recommended upgrade procedure outlined the Exchange 2007 product documentation.

Migrating from Antigen 8.0 for IM to Forefront Security for Office Communications Server (FSOCS):

As there are no Antigen 9 products for IM, you must first uninstall your Antigen 8 product, then upgrade your existing IM installation to one of the supported versions, and then perform a fresh install of FSOCS.

· To uninstall Antigen 8.0 for IM, stop all Antigen services in the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for IM installation folder (default path of Program Files\Sybari Software\Antigen for IM).

· To upgrade Microsoft Live Communications Server 2003 or Microsoft Live Communications Server 2005 to Microsoft Office Communications Server 2007 or Microsoft Office Communications Server 2007 R2, follow the recommended upgrade procedure outlined the OCS product documentation.

Migrating from Antigen 8.0 for SharePoint to Forefront Security for SharePoint (FSSP):

As there are no Antigen 9 products for SharePoint, you must first uninstall your Antigen 8 product, then upgrade your existing SharePoint installation to one of the supported versions, and then perform a fresh install of FSSP.

· To uninstall Antigen 8.0 for SharePoint, stop all Antigen and SharePoint services from the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for SharePoint installation folder (default path of Program Files\Sybari Software\Antigen for SharePoint).

To upgrade Windows SharePoint Services 2003 or SharePoint Portal Server 2003 to Microsoft Office SharePoint Server 2007 or Microsoft Windows SharePoint Services version 3, follow the recommended upgrade procedure outlined the SharePoint 2007 or version 3 product documentation.

Holly Kipp
Knowledge Engineer

Action Required by Dec. 1, 2009: Keep your Protection Current!

FSSTeam — Wed, 21 Oct 2009 19:51:00 GMT

Antimalware Protection

The AhnLab, CA, and Sophos engines will be retired on Dec. 1, 2009. After December 1^st, customers will not receive any updates for these retired engines. In order to make sure your Antigen and Forefront products continue to scan efficiently and effectively for malware, any customers running the AhnLab, CA, or Sophos engines must DISABLE these engines before Dec. 1, 2009 and select from the new set of five engines – Authentium, Kaspersky, Microsoft, Norman, and VirusBuster.

SPECIAL NOTE: Antigen for SharePoint 8.0 and Antigen for Instant Messaging 8.0 customers – In order to gain access to the new engine set and provide optimal protection for your messaging and collaboration environments, please download the Service Pack 1 releases of these products on the MVLS or VLSC site prior to Dec. 1, 2009. The updates for the new engine set will use a new update infrastructure as of Dec. 31, 2009 – the Service Pack 1 releases will allow you to continue to receive updates correctly from their new location.

For more information about Service Pack 1 for Antigen for SharePoint and Antigen for IM, see the following KB article:

http://support.microsoft.com/kb/975850/

- SPECIAL NOTE: Antigen for Exchange 8.0 and Antigen for SMTP Gateways 8.0 customers –These products will end of life on Dec. 31, 2009. Customers must upgrade to Antigen 9.0 SP2 for Exchange before this date, as the product will no longer continue to receive anti-malware updates starting Jan. 1, 2010. With the retirement of the CA, Sophos, and AhnLab engines on Dec. 1, customers running Antigen for Exchange 8.0 or Antigen SMTP Gateways 8.0 will only be protected by the Norman engine. For customers who need to continue using this product between Dec. 1, 2009 and the end-of-life date of Dec. 31, 2009, please contact Forefront Contract Administration for access to the revised engine set.

For more information on upgrading your Antigen for Exchange 8.0 or Antigen for SMTP Gateways 8.0 to Antigen 9.0, see the following KB article:

http://support.microsoft.com/kb/932396/

Antispam Protection

- Antigen for Exchange Server with Antigen Spam Manager 9.0 with SP2

- Antigen for SMTP Gateways with Antigen Spam Manager 9.0 with SP2

Brita Jenquin

Sr. Product Manager

Backscatter protection: how to do it with Forefront Protection 2010 for Exchange Server

FSSTeam — Tue, 29 Sep 2009 21:27:00 GMT

Backscatter is a problem that has been known to the messaging community for a long time. In essence, backscatter is a DSN (Delivery Status Notification) delivered to a recipient who never sent the original mail in the first place. While the DSN itself is perfectly legitimate and valid notification initiated by a reputable MTA, it has been sent to a user who never initiated the original mail transaction. How is this possible? Well, spammers just spoof a valid P1 MAIL FROM: address and an innocent user will get a bounce. Most backscatter victims (bogus bounce recipients) are in the same bucket with the rest of us (we are all humans and not very tech-savvy, are we?) so emotions fly high (“Ahhhh!!!!! I’ve been hacked!!!”, “My mail account is a zombie sending spam behind my back when I sleep!!!”, “Our corporate address book has been leaked!” etc.) These are some of the concerns I’ve heard from the victims after they got bogus NDRs. So what’s going on with this and how to stop it? Here is how the mail flow in a backscatter attack works:

Originally, spammers did not use and did not care much about providing valid P1.MAIL FROM addresses, so backscatter was much less of a problem. As defenses against spam grew, some MTAs deployed a logic that contributed to the backscatter problem in geometrical progression. Particularly, during an incoming SMTP transaction the “callback verification” logic causes the receiving MTA to immediately initiate a connection to the connecting MTA to verify the existence of the P1.MaiFrom address for the incoming e-mail transaction (these MTAs will verify P1.MailFrom on RCPT TO: command). If the address does not exist, the original e-mail transaction gets rejected. While it looks cool, this logic is fundamentally flawed and contributed to the widespread pandemic of backscatter.

Because the MTAs with “callback verification” only verify that the address exists in the org, spammers quickly realized this essential shortcoming and started to spoof legitimate addresses harvested all over the internet. As an example of the headache created by this flawed logic, one of the “Klez” virus iterations spoofed “support at microsoft.com” address to distribute the virus resulting in hundreds of thousands of backscatter messages sent to the Microsoft alias.

The right place to verify the legitimacy of incoming transactions is to plug in e-mail authentication technologies such as SenderID Framework. This is where the authenticity of incoming SMTP transactions should be verified without exercising rude and intrusive behavior that does more harm than good. There are, however, still plenty of MTAs that have been configured with this logic and continue to contribute to the backscatter problem. Sure, these MTAs get onto various DNS Black Lists rather quickly, but they get delisted from there pretty quickly as well after an administrator initiates a complaint and request for delisting.

In many cases backscatter presents serious danger to Exchange organizations, because it will consume significant resources on the backscatter-receiving server. What is even worse is the fact that spammers use social engineering to cleverly craft the backscatter to carry their payload. A few days ago I got a bounce, and my first reaction was “What’s going on???” Then I realized I just eyeballed this bogus NDR and its payload. This is exactly what spammers want – your eyes on their message in whatever form it is, especially an NDR as we are all naturally curious about what happened and why our mail was not delivered. Only after we open the NDR do we realize it’s bogus, but the spammers have already achieved their goal.

It’s been like this for many years without a sign of relief for Exchange users. Finally, with the introduction of Forefront Protection 2010, Exchange administrators will be able to protect their orgs from this vector of spam attacks. In the Forefront Protection 2010 for Exchange server release there is a new filter – the Backscatter Filter. Upon installation of Forefront 2010, the agent is the only agent in the antispam framework that is not enabled by default. If you were asking “What is backscatter anyway?” prior to reading this blog, then most likely you do not need this agent to be enabled. If after reading the preamble you think you are one of the victims, then Forefront 2010 will help you to counter backscatter. Let’s see how to do it.

On the Forefront Protection 2010 Administrative Console you will notice the new Backscatter Filter. Here is what it looks like:

So what’s under the backscatter filter hood? The filter has been implemented based on BATV technology. There are already many implementations/deployments using BATV technology to counter backscatter (for example, Exim, Sendmail, Postfix, Qmail, McAfee, SonicWALL, Panda, Ironport, and others). Forefront is right there and implements BATV in a very simple, flexible, and secure way. In order to use the filter, an admin needs to do the following:

1. Enable the filter

2. Generate a set of Backscatter Keys

3. Transfer the keys to all servers that participate in sending/receiving inbound/outbound mail

4. Start enjoying the benefits of being protected from backscatter attacks/spam!

To successfully implement backscatter protection the administrator must generate the backscatter keys for the filter to use, otherwise protection will fail. While there is no need to re-generate the keys on a daily/weekly or even monthly basis, if the key set is compromised, an administrator can regenerate the set, but only one new set of keys is allowed during a 24hr period.

To generate new keys, you click a button and get yourself a new set. What then? It is imperative to transfer the keys to all hub and edge servers that either send outbound or accept mail from the internet. With the new key set, the filter will start using the keys for generating BATV tokens on outbound mail but will respect the old keys for 24 hrs in order not to lose legitimate DSNs coming to Exchange org.

You might say – “Hey, I’m under backscatter attack, and I explicitly re-generated the keys to prevent bogus NDRs entering my org, but it looks like this is not going to take effect until 24hrs after!” Ahh, this is a case you can accommodate by adding the offending domain onto the antispam filter Reject DSNs from Domains. This will ensure that all NDRs from the attacking domain will get rejected and the rest will come through just fine.

Here is how the backscatter filter works. It has been implemented as two agents:

· An Outbound agent that works inside the CAT (Categorizer)

· An Inbound agent that works inside the SMTP Receive pipeline of Exchange server.

On the outbound side, the agent will stamp outgoing messages with a token (it will add it to the P1.MailFrom address) and on the outbound side, it will verify if the DSN is coming with the token attached and whether the token computes correctly. Every outbound token contains information about the original sender (sender’s address), the key used to compute the token, and the time interval when the token is valid. This means the spammers, even if they get a hold of the token, won’t be able to re-use it because the inbound agent will verify the token for integrity and if it does not compute correctly, will reject the e-mail transaction.

Any of the internal logic protection pieces will contribute to the failure, for example, if a spammer rips the token off and attaches it to multiple recipients. The token also has a limited lifetime so after its expiration the inbound backscatter agent won’t accept incoming NDRs. This is because legitimate MTAs will send their NDRs within a reasonable time interval. For the filter, the life duration of the token is seven days. However, even with all these protection layers there is a possibility of a token replay within seven days of the token origination.

Another possibility to discuss for the administrators is the possibility that the key set may get leaked or stolen (don’t ask me how or why as I believe if a malicious user gets a hold of your server, there are much bigger fish to fry than to steal backscatter keys). Anyway, if you feel your keys have been leaked somehow, you can regenerate a new set and you’re done. Maybe the next step for you would be to look into the problem and investigate what happened and why the keys got leaked/stolen from your server.

Here is a quick “Forefront Backscatter” guide or Q&A about Backscatter Filtering:

Q: Is the filter enabled by default?

A: No, you need to enable it manually.

Q: What needs to be done to get the filter working?

A: Enable the filter, generate the key set, and transfer the keys to all outbound/inbound mail processing servers.

Q: Do I need to restart Exchange Transport services?

A: Yes, you need to restart Exchange Transport manually for the agent to start working.

Q: I have two internet-facing servers in my org. How do I transfer the keys?

A: There are two buttons in the Backscatter area of the Forefront Administrator Console – “Import Keys” and “Export Keys”. When you generate the set on one server, use these buttons to transfer the keys to a file and import them to the second server.

Q: Can I have multiple key sets (one per server)?

A: No, you can’t, because the servers will start rejecting valid DSNs. You must have the same key set on all servers in your org where backscatter protection is enabled.

Q: Do I need to have the filter enabled and keys transferred to the servers that do not send mail outbound or receive directly from the Internet?

A: No, you don’t. Only servers that directly receive from the Internet or send to the Internet must have the filter enabled.

Q: How do I know when the keys were created?

A: the string on the Backscatter Filter UI indicates the creation time as shown below.

Q: I want to use the filter but I need to exclude my partner domain from being tagged with the BATV token. How do I do this?

A: You need to enter your partner’s domain onto the “Excluded Domains” list as shown below. The Outbound agent won’t stamp the P1.MailFrom with the BATV signature, and on the Inbound servers the DSNs coming from your partner domain will be excluded from backscatter processing. The screenshot below shows how to do it (enter the domain name, click Apply and Close and you are done).

Q: I’m under backscatter attack from an MTA that is reputable (not know to send spam), how do I reject DSNs from its domain?

A: Look at the screenshot below – all you need to do is to navigate to the “Reject DSNs from Domains” list, enter domain name sending you backscatter, and click Apply and Close. That’s it.

Q: Will my safe listed IPs be exempted from backscatter filtering?

A: No, but we are rationalizing this for the next release. The right way for you to exempt your safe listed IPs from backscatter processing is to enter their domains onto the “Excluded Domains” list.

Q: What is the logic behind not respecting safe listed IPs?

A: Safe listed IPs might (as legitimate RFC-compliant MTAs) unwillingly participate in backscatter as the mail originally does not originate at the safe listed IP (The safe listed IP will just send an NDR to you and it’s a backdoor for spammers that we are closing).

Q: Are there any shortcomings with the BATV technology?

A: Potential problems with BATV implementation have been listed here and here. Please read them to better understand this technology.

Antigen 8.0 End-of-life and Engine Revision

FSSTeam — Thu, 10 Sep 2009 18:44:00 GMT

I wanted to take the opportunity to remind all customers using Antigen for Exchange 8.0 and Antigen for SMTP Gateways 8.0 that the end-of-life date for these products is creeping closer. As of Dec. 31, 2009, these Antigen 8.0 products will no longer be supported, and will no longer receive any engine updates. We encourage customers to upgrade to the Antigen 9.0 products as soon as possible.

Equally important, I wanted to make sure that Antigen 8.0 users were aware of the engine revision plans announced on July 1, 2009 – and specifically, what these engine changes mean for Antigen 8.0 customers.

· Antigen for Exchange 8.0 and Antigen for SMTP Gateways 8.0

Because the CA and Sophos engines are being retired on Dec. 1, 2009, from Dec. 1 to the Dec. 31 end-of-life date customers will only be protected by the Norman engine. Therefore, it is recommended that customers upgrade to Antigen 9.0 prior to Dec. 1 to maximize their protection.

· Antigen for Exchange 8.0 with Advanced Spam Manager and Antigen for SMTP Gateways 8.0 with Advanced Spam Manager

With the retirement of the CA, Sophos and AhnLab engines on Dec. 1, customers running these products will continue to be protected by the Authentium, Kaspersky, Norman and VirusBuster engines until the product end-of-life on Dec. 31, 2009.

· Antigen for SharePoint 8.0

There will be a new build released in October 2009 that will give customers access to the revised engine set. If customers do not upgrade to this build, they will only be protected by the Norman engine as of Dec. 1, 2009.

· Antigen for Instant Messaging 8.0

For more information on engine revision plans, please visit the Antimalware Engine Notifications and Developments site. If you have questions on end-of-life for Antigen 8.0 products or need updated license files, please contact fssadm@microsoft.com.

Brita Jenquin
Sr. Product Manager
Forefront Protection Suite

Announcing the Release Candidate of Forefront Security 2010 for Exchange Server

FSSTeam — Tue, 18 Aug 2009 23:18:00 GMT

Today, we are excited to announce the release of our Forefront Security 2010 for Exchange Server RC (FSE) build for use with Exchange 2007 SP1 and Exchange 2010. FSE provides industry leading antimalware protection by simultaneously using up to 5 individual antimalware engines. Protection is provided for both viruses and spyware. Protection is provided by 4 separate types of scanning processes: Transport, Realtime, Scheduled, and On-demand. Each type of scan can be configured to use a different set of engines, providing a balance of protection and performance.

This RC release marks an important quality milestone for the latest version of the product, which includes:

· Significant UI improvements

· The addition of antispam backscatter support

· Hybrid antispam configuration from within the UI

· Integration with the Exchange 2010 RBAC model

· SCC cluster support

· Localized versions available in 11 languages (English, Spanish, French, German, Italian, Russian, Portuguese, Chinese Simplified and Traditional, Japanese, Korean).

Microsoft Forefront Security 2010 for Exchange Server (RC) is now available at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=b8a7d36f-cc8d-4335-ae60-8f27c48f3a37

Updated user documentation for the RC release is available at:

http://technet.microsoft.com/en-us/library/cc482977.aspx

Note: FSE 2010 RC is not compatible with the Stirling multi-node management console. If you would like to continue to manage FSE 2010 with Stirling you must continue to use the Beta 2 release which can be found at our TechNet site here.

Dave Friedman

Release Manager

Forefront Server Security