Microsoft Forefront Server Protection Blog

Microsoft Forefront Protection 2010 for SharePoint Release Candidate (RC) is available!

FSSTeam — Sat, 06 Feb 2010 01:28:00 GMT

We are pleased to announce that the Forefront Protection 2010 for SharePoint (FPSP) RC is available on the Microsoft Download Center at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=01bfa7c6-84be-478f-8b78-6875ad71a98b

This release has many performance enhancements, stress improvements, and bug fixes. This is a stand-alone release and cannot be managed with Forefront Protection Manager. The Forefront Protection 2010 for SharePoint RTM standalone will ship in the same time-frame as Office 14.

Upgrades from previous products and beta versions are not supported. Any previous version will need to be uninstalled and the Microsoft Forefront Protection for SharePoint data folder will need to deleted.

Mitch Hall

Program Manager

Forefront Server Protection

Microsoft Forefront Protection 2010 for SharePoint RC documentation updated on TechNet

FSSTeam — Fri, 05 Feb 2010 18:48:00 GMT

Hi, my name is Scott, and I'm a technical writer in the Forefront Server Security (FSS) User Assistance (UA) group here on Long Island, New York. This post is to let you know that the documentation for our just-released Forefront Protection 2010 for SharePoint (FPSP) Release Candidate (RC) product has been updated and posted to our TechNet Library at the following location:

http://go.microsoft.com/fwlink/?LinkID=111584

Please use the feedback feature on TechNet, because we do attempt to address all feedback received. Also feel free to e-mail any concerns to me directly at scfloman@microsoft.com or fss-ue@microsoft.com.

Lastly, I want to point out that another good resource for obtaining information about our products is the Forefront Server Security Forums (http://social.technet.microsoft.com/Forums/en-US/category/forefrontserversecurity), where you can easily interact with other customers and trained support professionals. Note that a passport account is needed to access the Forums.

That's all for now. Looking forward to hearing from you.

Scott Floman

Technical Writer

Forefront Server Protection

Using Forefront Protection 2010 for Exchange in Hyper-V virtual environments

FSSTeam — Wed, 03 Feb 2010 21:00:00 GMT

Hey Folks,

People have been asking on our forums if Forefront Protection 2010 for Exchange Server (FPE) can be run in a Hyper-V virtual environment. The short answer is yes. The deployment, configuration, and operation of FPE are the same in Hyper-V virtual server environments as on physical servers.

For details about installing in and running in a Hyper-V virtual environment, read our documentation on TechNet: http://technet.microsoft.com/en-us/library/dd639345.aspx

Michel LaFantano

Forefront Server Protection UA

TechNet Edge video about Forefront Protection 2010 for Exchange Server

FSSTeam — Thu, 28 Jan 2010 16:31:00 GMT

Hey Folks-

Check out this recent video of an IT pro talking about his experience with Forefront Protection 2010 for Exchange Server:

http://edge.technet.com/Media/FPE-Customer-Story/

If you are not familiar with TechNet Edge, it is a great resource for IT pros to get news, information, and tips about Microsoft technologies. There are tons of videos and other resources on the site.

Enjoy!

Michel LaFantano
Forefront Server Protection UA

Forefront Protection 2010 for Exchange Server and 32-bit vs. 64-bit

FSSTeam — Mon, 21 Dec 2009 19:43:00 GMT

Microsoft Forefront Protection 2010 for Exchange Server (FPE)¹ is a leading solution for securing your messaging environment. Its antimalware solution is a proven security product that has helped many customers to secure their e-mail system.

A multi-engine solution provides the maximum protection for our customers, but it also requires we take dependencies on multiple engine partners. The engines Forefront leverages remain in service for many years, most were created when only 32-bit machines were available, and some partners are still developing their native 64-bit engine. To release a 64-bit engine is not an easy task, for instance, this often involves porting and testing a large volume of assembly code.

Forefront made a cautious decision to preserve 32-bit scanning processes until the next release. One reason to do this is the 32-bit engines are field proven to be stable. Another reason is that we provide a shield so that the 32-bit scanning processes remain transparent for our customers. Forefront customers receive the same level of malware protection regardless if the scanning processes are 32-bit or 64-bit.

Now that the world is moving toward 64-bit architecture – Windows 2008 R2, Exchange 2007, Exchange 2010, and Office 2010 only support 64-bit releases and some of our engine partners have had 64-bit engines running in the field for some time now, we believe we are ready to move to a native 64-bit solution. Besides aligning with Server and Office applications, a 64-bit application has the advantage of being able to leverage more virtual memory (up to 8 TB) than a 32-bit application (up to 2 GB). This will allow Forefront to scan increasingly large files in memory and allow customers to scale out in a high volume traffic environment.

The upcoming releases – Microsoft Forefront Protection for SharePoint 2010 (FPSP) and Microsoft Forefront Protection for Exchange Server 2010 with Service Pack 1 – will be entirely native 64-bit solutions. For those engines that are not yet available in 64-bit, or that have not been thoroughly tested in the field, we continue to provide the same level of malware protection by hosting the 32-bit version of those engines in a separate process. These upcoming releases will also have the ability to seamlessly switch to the native 64-bit version of these engines without affecting the Forefront deployment or involving additional administrative tasks when the engines become available.

1. Former releases include Microsoft Forefront Security for Exchange 2007, Microsoft Forefront Security for SharePoint 2007, Microsoft Antigen for Exchange, Microsoft Antigen for SharePoint.

Carolyn Liu
Senior Program Manager

Forefront Protection 2010 for Exchange Server (FPE) Capacity Planning Guidance v. 2

FSSTeam — Fri, 18 Dec 2009 16:32:00 GMT

The purpose of this document is to provide guidance into Forefront Protection 2010 for Exchange Server (FPE) capacity planning regarding hardware, such as the number of processing cores, memory requirements, and when to scale up based on CPU utilization and throughput. Performance guidelines using the capacity planning tool are provided for Exchange Server 2010 deployments. A new interactive capacity planning tool will be released in the future for FPE 2010.

Performance guidelines are also provided here on how to leverage the existing Forefront Security for Exchange Server (FSE) Version 10 with Service Pack 1 capacity planning tool for Exchange Server 2007.

Note: The performance measurement baseline information provided is based on the existing product documentation for Exchange Server.

All organizations are unique and driven by requirement specifications, policies, behaviors, and cultures that guide and inform hardware purchase decisions. This document can help clarify the additional load created by FPE for Exchange Server 2010 on sample server environments and provides guidance to help with capacity planning decisions. This information should be combined with your experience, the Exchange server capacity planning guidelines, and your general knowledge of your own organization and IT landscape.

1. Reference Architectures and Server Roles

There are two main reference architectures used for FPE deployments.

1.1. Enterprise Reference Architecture

The first is the Enterprise Reference Architecture shown in Figure 1. This is a scalable unit intended to be deployed within a larger organization and is composed of an Edge server, Hub server, multiple Mailbox servers, an Active Directory server, and a Client Access server (CAS).

Figure 1. Enterprise Reference Architecture

1.2. Standard Reference Architecture

Figure 2 shows 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 roles, and then a dedicated Active Directory server.

Figure 2. Standard Reference Architecture

1.3. Server Roles

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

1.3.1. Exchange Edge Server Role

In this server role, the SMTP data stream flows into an organization and message hygiene is performed. Message hygiene includes antispam, antivirus, antispyware, and custom filtering. The FPE protection technology software resides on this server along with the Microsoft Exchange Transport service. The messages that pass an enterprise’s message hygiene are routed to the appropriate Hub server for additional routing. Messages that have undergone scanning as part of the message hygiene at the Edge are not scanned again at the Hub.

1.3.2. Exchange Hub Server Role

The Exchange Hub server accepts routing SMTP information from the Edge server, can perform additional message hygiene based on configuration, and then routes the messages to the appropriate Mailbox server or additional Hub servers. The FPE protection technology software resides on this server, along with the Microsoft Exchange Transport services.

1.3.3. Exchange Mailbox Server Role

The Exchange Mailbox server accepts the incoming messages from the Hub server and can perform additional message hygiene based on configuration. In addition, the Mailbox server can perform scheduled and on-demand scanning requests. The FPE protection services reside on this server, along with the Microsoft Exchange Information Store service.

1.3.4. Exchange Multi-Role Server Role

In an Exchange multi-role server role, this server contains the capabilities of the FPE Hub server, FPE Mailbox server, and Exchange CAS all in one server. So, it provides aggregate functionality.

2. FPE Server Performance Guidance for Exchange Server 2010 Deployments

The following sections provide descriptions of each of the Exchange Server roles running FPE along with applicable guidance around performance.

2.1. Exchange Edge Server

Factors Impacting Performance

On the 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 detected as spam or malware. The Edge server running FPE can also be configured to send outgoing e-mail from your internal users, but the load from this activity is fairly minimal. You can assess your current message load by monitoring the following performance counters using Exchange Listener:

\MSExchangeTransportSmtpReceive\Messages Received/sec

Over a 24 hour period, you can obtain the average and peak message load.

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

Note: Additional configuration information will be provided in the future in an updated capacity planning tool for FPE.

The three main areas of configuration, in order of importance, are:

Engine Management

Engine management is comprised of two different components.

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

The second component is the Engines and Performance setting. Again, by default, the subset of available engines are selected to perform message hygiene. The user can select an Engines and Performance setting that ranges from always scanning with the enabled engines to only scanning with one engine.

Number of Scanning Processes

By default, the number of transport scanning processes is set to 4. That means there are 4 processes used to perform malware message hygiene.

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.

Performance Data

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

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

Memory: 4G RAM

Message Mix: Sample of Microsoft IT

Engines and Performance: Scans with all engines (5 engines) and no antispam.

Scanning Processes: 4

Figure 3. FPE CPU Utilization

The next graph, 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.

Figure 4. Throughput Scalability on 8 Core Server

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

Engines and Performance: Scans with all engines (5 engines) and no antispam.

Scanning Processes: 4 and 8

During these various tests, the malware scanning detection was disabled and only the premium antispam capabilities were 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 enabled on the Edge server without any message hygiene.

Memory measurements were also conducted on a variety of configurations and the recommendations are provided at http://go.microsoft.com/fwlink/?LinkID=163921. 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 MB.

Capacity Planning Guidance

Processor

The recommendation is to use a 4 core server (not hyper-threaded) for the Edge. Although the product supports 1 and 2 core server configurations, this impacts 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; this should be increased to 8 for an 8 core server.

Memory

The memory recommendation is provided at http://go.microsoft.com/fwlink/?LinkID=163921. Overall, you should size your server configuration for at least 2 GB over the recommended Exchange Server 2010 Edge server guidance.

Scaling Up / Out

The default configuration, at about 75% utilization, allows 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 want to support a larger incoming rate, you can:

· Increase the number of cores on your server.

· Decrease the number of engines used by each of the scanning processes.

· Add another Edge server.

The data on how this impacts scale will be available in a future Microsoft TechNet article. However, there can be significant scale gain by changing from 5 scanning engines to 4, or 3.

2.2. Exchange Hub Server

The Hub server uses a very similar configuration as the Edge server, however, there are two significant differences.

First, the premium antispam functionality is not enabled by default on this role. Secondly, if an Edge server is forwarding mail to a Hub server, then message hygiene has already been accomplished except in cases where the configuration differs from the default. So, the message hygiene provided by the Hub server is for internal originating mail.

Factors Impacting Performance

The basic paradigm that aligns with Exchange is a user that sends/receives a total of 50 messages per day that average 75 KB per message. Out of the 50 messages per day, an estimated 20% are sent, an estimated 25% of the remaining 80% are received from the Internet, and the remaining 75% of the 80% are received from internal recipients.

Using these calculations and the numbers from the Edge server, at peak times a message rate of 8 messages per second are scanned.

Performance Data

The guidance from Exchange Server 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 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 Hub server. Although the product supports 1 and 2 core server configurations, this impacts 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 should be increased to 8 for an 8 core server.

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 of 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 want to support a larger Hub to mailbox ratio, you can either:

· Increase the number of cores on your server.

· Decrease the number of engines used by each of the scanning processes.

The data on how this can impact scale will be available in a future Microsoft TechNet article. However, there can be significant scale gain by changing from 5 scanning engines to 4 or 3.

2.3. Exchange Mailbox Server

Factors Impacting Performance

There are three factors that impact performance on the Mailbox server: scanning of mailboxes using scheduled and on-demand scans, the configuration of the server, and the load of the users that generate traffic that require message scanning.

The basic paradigm that aligns with Exchange represents a user that sends/receives a total of 50 messages per day averaging 75 KBs/message. Out of the 50 messages per day, an estimated 20% are sent, an 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 realtime scanning will be on-access scanning of the messages. This traffic can be modeled conservatively by assuming 20% of all access mails are 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 Mailbox server role. As with all other roles, the number of engines used impacts performance. Secondly, the user can enable the rescanning of the messages if they enable the Scan after engine update option.

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

Performance Data

The guidance from Exchange Server 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 Mailbox server. Consult the Exchange 2010 processor guidelines and make sure that the minimum requirements are met. If using more than 4 cores, you should 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 should be increased to 8 for an 8 core server.

Memory

Scaling Up / Out

In terms of cores, 1 core can support 20% less than the Exchange Server 2010 recommended users per core. For example, for a profile of 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 is 20% lower, meaning 800 users per core. So, you can scale up by sizing your Mailbox server appropriately with more cores, or scale out by adding additional mailbox servers to support your profiled number of users. Refer to Microsoft Exchange Server Profile Analyzer for help in identifying your user requirements on the Mailbox server.

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

2.4. Exchange Multi-Role Server

The Multi-Role server supports Hub server functionality as well as Mailbox server functionality. In addition, the CAS may also be hosted on this computer. Understanding the performance implications is a bit more complicated, especially when the Hub server is really used as a message hygiene server without an associated Edge role 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 it is assumed that this is not in this case.

In addition, the server has 8 total scanning processes associated with FPE protection technologies – 4 dedicated to the Hub server role and 4 dedicated to the 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 per second per 1000 users (Mailbox): ((1000*40*2)/5) / (80*60*60/2) = 1.11

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

· Total impact => 3.19 messages per second per 1000 users

Capacity Planning Guidance

Processor

The recommendation is to use at least a 4 core server (not hyper-threaded) for the Multi-Role server. Consult the Exchange 2010 processor guidelines and make sure that the minimum requirements are met. If you are using more than 4 cores, you should 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. So you should increase the numbers proportionately if using a server with more than 8 cores.

Memory

The memory recommendation is provided at http://go.microsoft.com/fwlink/?LinkID=163921. Overall, you should size your server configuration for at least 3.5 GB over the recommended Exchange 2010 Edge server guidance.

Scaling Up / Out

The Multi-Server role can support 437 users per core that send/receive 50 messages per day. You can scale up by:

· Increasing the number of cores on your multi-server role.

· Decreasing the numbers of engines used on the Hub server role and Mailbox server roles.

· Migrating users to additional hardware.

Best Practices for a Healthy Deployment

In addition to capacity planning guidelines discussed previously, you should consider the following best practice attributes for a healthy deployment that affects overall performance:

*Best practice*	*Checklist*
Maintain the Submission Queue Length at zero.	· Apply the following script: \MSExchangeTransport Queues(_total)\Submission Queue Length
Maintain CPU utilization at less than 75%.	· Plan and conserve amount of resources required to maintain acceptable level of service.
Light-emitting diode (LED) light needs to be monitored for blinking.	· The hard drive LED should maintain a blinking state. Any other state (light always on) indicates thrashing. It is important to maintain adequate disk input/output and utilize memory swapping to prevent thrashing.
FPE (or FSE) databases should be monitored and routinely maintained.	· Clean/purge database to reduce size. · Enable retention policies. Note: If you are expecting the incident database to grow soon, it is a good idea to allocate more free space for the database.
Apply service packs as required.	· Perform update for all required service packs on a regular basis. Note: Exchange Server fixes are distributed in service packs. Service packs keep the product current. Service packs include updates, system administration tools, drivers, and additional components. If you do not stay up to date on service packs, performance and product functionality are seriously compromised.

3. FPE Server Performance Guidance for Exchange Server 2007 Deployments

Reference the previous tool for FSE Version 10 with SP1: http://go.microsoft.com/fwlink/?LinkId=179850

Use this tool with the following guidance:

· 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%.

· Increase the amount of expected server memory by 500 MB.

If you have comments or questions, please contact us at: fssperf@microsoft.com

Frank Trujillo

Senior Program Manager

New Planning and Architecture content available in our TechNet library

FSSTeam — Tue, 15 Dec 2009 21:00:00 GMT

Greetings! I am a new technical writer on the Forefront Server Protection UA team. I wanted to make you aware of some new user documentation our team recently made available for Forefront Protection 2010 for Exchange Server (FPE).

If you are looking for the big picture on how FPE protects your Exchange servers and how to develop an effective scanning strategy, look no further. The new Protecting your Exchange servers documentation in the Planning and Architecture section gives you the parameters to understand best practices for scanning malware without compromising your server load performance levels.

Because FPE can be deployed and configured in a variety of ways depending on the topology of the Exchange organization, the most effective route for your own deployment needs to include good planning strategies around what needs to be scanned and on which servers in your specific architecture. Before you dive into deployment and operation detail, check out this section first to help you make good configuration decisions.

Planning and architecture guidelines and strategy is now available for the new release of Forefront Protection 2010 for Exchange Server (FPE) and is available here.

Suzanne Greenberg

Forefront Server Protection UA

Watch this video overview of the new Forefront Protection 2010 for Exchange Server antispam filters

FSSTeam — Mon, 14 Dec 2009 21:30:00 GMT

Alex Nikolayev, a program manager on the Forefront Server Protection team, was recently interviewed on video about the new antispam filters available in Forefront Protection 2010 for Exchange Server (FPE). Alex gives an excellent overview of the antispam filters in FPE and how they are integrated into a seamless antispam solution for protecting Exchange servers from unwanted spam e-mail.

You can watch the video at: http://edge.technet.com/Media/Forefront-Protection-for-Exchange-FPE-Anti-Spam/

Michel LaFantano
FPE UA

We want your input for the next release of Forefront Protection for Exchange Server

FSSTeam — Fri, 11 Dec 2009 15:28:00 GMT

Although we just shipped Forefront Protection for Exchange Server 2010, we are already hard at work planning the next release. To that end, we are very interested in hearing feedback on your experience deploying and managing your current antimalware solution for Exchange. Please take 5-10 minutes to answer the survey questions. This type of feedback directly impacts future product decisions and we would appreciate your valuable input.

Survey link: http://www.surveymonkey.com/s/JYLMKCZ

If you could please forward the survey link to others in your organization, we would greatly appreciate it.

Andrew Schiano
FSP Test Engineer

Migrating from Forefront Security for Exchange Server to Forefront Protection 2010 for Exchange Server

FSSTeam — Thu, 10 Dec 2009 21:34:00 GMT

Hey Folks,

As you start looking at the new release of Forefront Protection 2010 for Exchange Server (FPE) and consider deploying it in your Exchange environment, you will need to know about migrating from previous versions of Forefront Security for Exchange Server (FSE).

There is no direct upgrade from FSE to FPE, but we have written some guidance that will help you migrate from FSE to FPE in your environment. The guidance can be found in our Forefront Server Protection TechNet library at: http://technet.microsoft.com/en-us/library/ee707326.aspx

Michel LaFantano

Forefront Server Protection UA

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 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