Microsoft Forefront Server Security Blog

Join the Forefront Protection 2010 for SharePoint TAP Program

2009-11-05T20:57:00Z

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

2009-10-30T14:17:00Z

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!

2009-10-28T15:50:00Z

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

2009-10-26T18:09:00Z

Because Antigen 8 for Exchange and Antigen 8 for SMTP Gateways are reaching their “End of Life” date on December 1, 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!

2009-10-21T19:51:00Z

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

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.

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

Brita Jenquin

Sr. Product Manager

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

2009-09-29T21:27:00Z

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

2009-09-10T18:44:00Z

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

2009-08-18T23:18:00Z

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

New update of the Forefront Server Security and Antigen documentation on TechNet

2009-08-10T23:11:00Z

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. Every few months or so, we update our existing “legacy” documentation on our TechNet Web site, and this post is to make you aware of our recent August 2009 update. (p.s. By “legacy” content I mean products that are already supported in production environments, such as Antigen Version 9 and our Forefront Server Security Version 10 products).

Some of the things we added or provided updated information about are:

· Antigen antispam functionality. The Cloudmark antispam engine was introduced in Antigen Version 9 with Service Pack 2. (See the “Antigen Spam Manager” chapters in the Antigen User Guides, and the “New Features” section in the Antigen Release Notes.)

· Scan engine provisioning. (See the file scanner updating chapters in the Forefront Security for Exchange Server (FSE) User Guide, Forefront Security for SharePoint (FSSP) User Guide, Antigen User Guides (Exchange and SMTP Gateways). Also see the “New Features” section in Release Notes.)

· Added information about a known issue when upgrading to FSE/FSSP/Antigen service packs. (See the “Important Notes” section in Release Notes.)

· Updated steps for applying Exchange and FSE/Antigen service packs or rollups. (See the installation chapter in the User Guides.)

· Added details about how to specify queries in a keyword filter list. (See the keyword filter chapter in the User Guides.)

· Made several updates to the Forefront Server Security Management Console User Guide, including information about:

· System requirements

· Templates

· Managing servers across forests or domains

· Using the FSSMC diagnostic utility

· How the “Enable” settings affect different products

· Updated Hyper-V virtual documentation for FSE and FSSP based on feedback. (See the installation chapter in the FSE and FSSP User Guides.)

· Added information about the FSSP bypass feature. (See the Realtime Scan Job chapter in the FSSP User Guide.)

· Set expectations for what CSS can provide for customers using clustering with third-party vendors. (See the FSE and Antigen Cluster Installation Guides.)

· Added steps for increasing scanning processes for the FSE realtime and transport scans. Clarified and synced definitions for “process counts” across documentation sets. (See the FSE User Guide.)

So, that’s that, I just wanted to say a few words about our latest TechNet update. It’s also worth noting that the main page of the FSS TechNet Library is located at the following URL http://go.microsoft.com/fwlink/?LinkId=143540, that our TechNet Library always contains the “latest and greatest” versions of our documentation, and that we will continue to update our legacy content as needed. Please used the feedback feature on TechNet, because we do attempt to address all feedback received. We are also working on updating our robust doc set for the “next generation” of our FSE and FSSP products; the RC version of the FSE product will be posted to TechNet the second week of August.

Finally, another good resource for obtaining info 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. Hope that this information has been useful and thanks for reading.

Scott Floman

Technical Writer

Forefront Server Security

Downloading Antigen 9.0 with SP2

2009-08-04T23:24:00Z

We’ve had several inquiries from customers regarding the download of Antigen 9.0 with Service Pack 2 on the MVLS and VLSC sites – both on the download location and the format of the bits.

First, to find the Antigen 9.0 with SP2 release on the MVLS/VLSC site, you can look in two places:

1) Under “Messaging Security”

2) Under “Forefront Security for Exchange Server 10.0 with Service Pack 2”

On VLSC, you will have to select your language and download speed, then hit “continue”, which will bring up the below download screen where you can download the Antigen 9.0 with SP2 products:

We understand that this creates some confusion for customers looking under “Antigen”, so we will also be adding these downloads to the MVLS and VLSC sites as “Antigen for Exchange with Antigen Spam Manager 9.0 with SP2” and “Antigen for SMTP Gateways with Antigen Spam Manager 9.0 with SP2” by September 1, 2009.

Second, we’ve had customers ask about why we no longer post stand-alone builds for Antigen for Exchange and Antigen for SMTP Gateways, and whether this means that they are downloading new “Antigen Spam Manager” bits that were not previously installed. The answer to this is two-fold:

1) The Antigen 9.0 with SP2 release includes new antispam technology from Cloudmark that we want to make available to all customers. This antispam engine will provide a better overall antispam experience including higher detection rates, lower false positives, and improved submission and service experience.

2) The previous “stand-alone” builds of Antigen for Exchange and Antigen for SMTP Gateways were exactly the same bits as the “with Antigen Spam Manager” versions – the only difference was a built-in license key which deselected the spam engine by default.

For customers upgrading existing Antigen 9.0 installations to Antigen 9.0 with SP2, the antispam engine settings will carry over from the previously installed version. Therefore, if you do not want the antispam functionality, there is no action required.

For customers installing Antigen 9.0 with SP2 on new servers who do not want the antispam functionality, you can follow the below steps to easily disable it:

1. In Run Job, select the Internet scan job and de-select Spam Scanning.

2. In Scanner Updates select the SpamCure engine and press the Disable button on the right side of the screen.

3. In Scanner Updates select the Cloudmark Authority Engine and press the Disable button on the right side of the screen.

4. Open the Service Control Manager and Stop the Star Engine service.

5. Go to Start->Settings->Control Panel->Scheduled Tasks and delete any entry related to SpamCure or Cloudmark

For more information on the Antigen 9.0 with SP2 releases, please visit the Antimalware Engine Notifications and Developments page.

Brita Jenquin
Sr. Product Manager
Forefront Protection Suite

Prepare now for an upcoming change in Kaspersky Antivirus Technology

2009-08-03T20:58:00Z

Hi, this is Gary Hauck from the Forefront Rapid Response Engineering Services team. My team is responsible for providing engine and definition update packages for the Forefront Server and Antigen products. I am writing today to inform you of an upcoming change to the Kaspersky Antivirus engine and the important action that many of you will need to take within the next several months to prepare for this change.

In early 2010, Kaspersky will end of life the engine version that is being distributed today in the Forefront Server and Antigen 9 products. Microsoft is planning to commence distribution of Kaspersky’s newest SDK 8 engine to replace this on January 4^th 2010. This new Kaspersky engine has a requirement that certain files that are part of the engine reside within a subfolder tree. Due to a limitation in older releases of Forefront and Antigen, this new engine requirement is a problem that will result in engine update failures. Microsoft has resolved this limitation in the latest shipping build for all Antigen and Forefront products. This means that in order to continue to consume Kaspersky engine updates after January 4^th, 2010 you must be running a release that can accommodate this new Kaspersky engine subfolder structure.

Please review the table below to determine if this change affects you and plan for the specified action:

Product Version	Required Action
Microsoft Antigen 9 for Exchange Server (Version 9.0.1055.xx)	Upgrade to Antigen 9 for Exchange Server SP2 prior to January 4^th, 2010.
Microsoft Antigen 9 for Exchange Server SP1 (Version 9.1.1097.xx)	Upgrade to Antigen 9 for Exchange Server SP2 prior to January 4^th, 2010.
Microsoft Antigen 9 for Exchange SP2 (Version: 9.2.1097.xx)	No action required.
Microsoft Forefront Security for Exchange Server (Version: 10.0.0566.xx)	Upgrade to Microsoft Forefront Security for Exchange Server SP2 prior to January 4^th, 2010.
Microsoft Forefront Security for Exchange Server SP1 Possible versions (including rollups): 10.1.0746.xx 10.1.0809.0	Upgrade to Microsoft Forefront Security for Exchange Server SP2 prior to January 4^th, 2010.
Microsoft Forefront Security for Exchange Server SP2 (Version 10.2.0942.0)	No action required.
Microsoft Forefront Security for SharePoint Server (Version 10.0.0566.xx)	Upgrade to Microsoft Forefront Security for SharePoint Server SP3 prior to January 4^th, 2010.
Microsoft Forefront Security for SharePoint Server SP1 Possible versions (including rollups): 10.0.0720.0 10.0.0700.20 10.0.0703.xx	Upgrade to Microsoft Forefront Security for SharePoint Server SP3 prior to January 4^th, 2010.
Microsoft Forefront Security for SharePoint Server SP2 Possible versions (including rollups): 10.1.0802.0 10.1.0815.0	Upgrade to Microsoft Forefront Security for SharePoint Server SP3 prior to January 4^th, 2010.
Microsoft Forefront Security for SharePoint Server SP3 Version 10.2.0942.xx	No action required.
Microsoft Forefront Security for Office Communications Server Version: 10.2.0308.xx	No action required.

Gary Hauck

Development Lead
Forefront RRE Services

Forefront Server Security Management Console Hotfix Rollup 3 Available Now!

2009-07-30T20:10:00Z

We are very happy to announce that the Forefront Server Security Management Console (FSSMC) Hotfix Rollup 3 shipped on July 30^th. Here are the new features and some important information for the rollup. For a complete list of the fixes included in the rollup and to obtain it, see the following Knowledge Base article “Hotfix Rollup 3 for Microsoft Forefront Server Security Management Console”:

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

New features in the Rollup

Antigen version 9 with Service Pack 2 incorporates new anti-spam technology through a partnership with Cloudmark. FSSMC Rollup 3 now supports Cloudmark engine update redistribution and Engine Version Reports.

Note Rollup 3 only supports Redistribution Jobs for Cloudmark engine updates and not signature updates. The Cloudmark anti-spam engine receives its signature updates directly from the vendor’s site and not through Microsoft. This means that the signature updates are not distributed through the FSSMC. An engine update refers to updating to a new version of a scan engine (which replaces the old version), whereas a signature update refers to new signatures being added to an existing scan engine.

For more information about this feature, visit the following Microsoft Web page:

http://technet.microsoft.com/en-us/forefront/serversecurity/dd940095.aspx

FSSMC now can automatically provision the scan engines on managed Antigen and FSS servers. It does so by using the scan engine updates that are deployed to the managed servers through the Signature Redistribution Job. This feature gives customers the latest protection against malware by extending the updating capabilities of Antigen version 9 and Forefront Server Security (FSS) products. This feature can quickly notify users of the availability of a new threat scanning engine, or a planned change in the existing scan engines. These notifications advise administrators on how to make appropriate changes to their product configurations before any changes take effect. The notifications are registered in the Antigen and FSS event log entries and can also be configured for e-mail delivery through the "Virus Administrators" notification group.

For more information about this feature, visit the following Microsoft Web page, and then click the Engine Revision Overview and FAQ hyperlink:

http://technet.microsoft.com/en-us/forefront/serversecurity/dd940095.aspx

Important Information:

When upgrading from a previous version of FSSMC, you must re-deploy the FSSMC Deployment Agents to your managed servers. For information, see Deploying Agents under Getting Started in the FSSMC User Guide.

Holly Kipp

CSS Senior Security Support Engineer

Spamhaus RBL changes

2009-07-27T22:30:00Z

Hello Forefront and Antigen users. I want to call your attention to a blog posted recently by Andy Day of our exceptional support team about real-time block lists or RBLs. He recently posted an article about some changes to the Spamhaus RBL that may impact some of our users. You can find the details here: http://blogs.technet.com/fssnerds/archive/2009/07/06/spamhaus-update.aspx

The FSS Nerds blog is another great resource for information and tips about Forefront Server Security products.

Enjoy.

Michel LaFantano

FSS User Assistance team

Capacity planning for FSOCS on OCS 2007 R2

2009-07-08T22:35:00Z

Back in April, I wrote about a method to estimate the capacity of your Office Communication Server (OCS) with Forefront Security for Office Communications Server (FSOCS) installed (read more here). During the release process for FSOCS, the development team used a similar method that leveraged the OCS 2007 R2 Capacity Planning tool to capture performance data. We used this data to pull together an analysis that gives guidance to our customers for capacity planning an OCS 2007 R2 environment protected by FSOCS.

You can download the document here.

Have questions? Feel free to use the Microsoft Forefront Security for OCS TechNet Forum to reach us.

Shrey Shah
Developer - FSS

Forefront Security for SharePoint Manual Scan Issues

2009-07-02T22:59:00Z

Microsoft has become aware of two interrelated issues affecting a Manual Scan in Forefront Security for SharePoint.

The first issue is a memory leak which occurs when Keyword Filtering is enabled. In all versions of Forefront Security for SharePoint prior to Service Pack 3, whether you have Keyword Lists created or not, you may experience this issue. If, however, you have Forefront Security for SharePoint with Service Pack 3 installed (released 7/1/2009), this issue will only occur if you have Keyword Lists created. If you do not have any Keyword Lists, even if Keyword Filtering is enabled for Manual Scan, you will not experience the leak. Real-time scanning is not affected by this issue.

The second issue may occur as a result of the first. After a period of time the memory leak can cause memory allocations to fail. If these failures occur repeatedly in a specific way, it causes Forefront Security for SharePoint to incorrectly determine a valid document as “exceedingly nested”. Every file that is scanned and determined to be exceedingly nested will be deleted and the contents replaced with standard deletion text.

Microsoft is actively working toward a resolution for these issues. An update will posted as soon as more information becomes available. In the meantime, we recommend that any customers using Forefront Security for SharePoint that run a Manual Scan disable Keyword filtering for Manual Scanning (for more information on configuring the Manual Scan job, see "Running the Manual Scan Job" in the FSSP User Guide http://technet.microsoft.com/en-us/library/bb795164.aspx). This is extremely important, as manual scanning of your entire document library opens the potential of losing any document content incorrectly identified as “exceedingly nested”. Please note that, by default, Keyword Filtering is enabled for the Manual Scan job.

Thank you,
Craig Wiand
Microsoft Forefront Escalation Engineer