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 1st, 2009 (as announced on July 1st, 2009). Previous builds of the product will still function after December 1st, 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
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 KippKnowledge Engineer
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.
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 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.
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 changes mean for Antigen 8.0 customers.
· Antigen for Exchange 8.0 and Antigen for SMTP Gateways 8.0
Because engines are being retired on Dec. 1, 2009, 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
Customers running these products will continue to be protected 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. Customers should upgrade to this build.
· Antigen for Instant Messaging 8.0
If you have questions on end-of-life for Antigen 8.0 products or need updated license files, please contact fssadm@microsoft.com.
Brita JenquinSr. Product ManagerForefront Protection Suite
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
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
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.
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 4th 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 4th, 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 4th, 2010.
Microsoft Antigen 9 for Exchange Server SP1 (Version 9.1.1097.xx)
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 4th, 2010.
Microsoft Forefront Security for Exchange Server SP1
Possible versions (including rollups):
10.1.0746.xx
10.1.0809.0
Microsoft Forefront Security for Exchange Server SP2 (Version 10.2.0942.0)
Microsoft Forefront Security for SharePoint Server (Version 10.0.0566.xx)
Upgrade to Microsoft Forefront Security for SharePoint Server SP3 prior to January 4th, 2010.
Microsoft Forefront Security for SharePoint Server SP1
10.0.0720.0
10.0.0700.20
10.0.0703.xx
Microsoft Forefront Security for SharePoint Server SP2
10.1.0802.0
10.1.0815.0
Microsoft Forefront Security for SharePoint Server SP3
Version 10.2.0942.xx
Microsoft Forefront Security for Office Communications Server
Version: 10.2.0308.xx
Gary Hauck
Development LeadForefront RRE Services
We are very happy to announce that the Forefront Server Security Management Console (FSSMC) Hotfix Rollup 3 shipped on July 30th. 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
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
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
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 ShahDeveloper - FSS
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 WiandMicrosoft Forefront Escalation Engineer
Microsoft announced today the release of four service packs from the Antigen and Forefront product families that provide leading protection for customer’s Exchange and SharePoint environments.
· Forefront Security for Exchange Server
o Download Forefront Security for Exchange Server with Service Pack 2
o Description of Forefront Security for Exchange Server Service Pack 2
· Forefront Security for SharePoint
o Download Forefront Security for SharePoint with Service Pack 3
o Description of Forefront Security for SharePoint Service Pack 3
· Antigen 9.0
o Download Antigen for Exchange with Antigen Spam Manager 9.0 with Service Pack 2
o Download Antigen for SMTP Gateways with Antigen Spam Manager 9.0 with Service Pack 2
o Description of Antigen 9.0 with Service Pack 2
The service packs introduce technology that will notify customers of engine changes – including the addition or elimination of engines – and allow administrators to update their engine configurations without having to deploy any new product updates. This update allows customers to accommodate engine changes effortlessly, helping maintain the high level of security provided in the Forefront server security products.
Microsoft continually monitors antivirus engine quality and detection rates using internal and 3rd party independent testing organizations. We have found that using
a multi-engine protection approach provides superior detection of the latest threats when compared to single engine solutions. In fact, AV-Test.org has tested our products with competitors and found our detection rates have an average response time of 3-6 hours for new viruses. In contrast, competitive single-engine solutions average response times are more than 2-9 days.
Testing for the last several years has indicated that using more than five malware engines concurrently does not improve overall detection rates. In order to develop stronger technology relationships with our antimalware partners and ensure continued customer value for the longer term, we are making available a set of five antimalware engines, with confidence that this solution will continue to offer industry leading detection rates and response times.
As an example of Microsoft’s commitment to continual improvement of our malware detection leadership, we are investing in new antispam technology through a partnership with Cloudmark that will provide an overall better antispam experience including higher detection rates, lower false positives, and improved submission and service experience. The Cloudmark engine is now included in latest service pack releases of Antigen for Exchange with Antigen Spam Manager 9.0 and Antigen for SMTP Gateways with Antigen Spam Manager 9.0 products as Beta while it undergoes customer trials. Upon the near term completion of the customer trials, it will be released by Microsoft for both the Antigen 9.0 products, as well as be included in the next generation releases of Forefront server security products later this year. More information is available on TechNet at the Antimalware Engine Notifications and Developments page.
For more information on the service packs, please read on…
· Forefront Security for Exchange Server with Service Pack 2 Now Available
Make protecting your Exchange 2007 environments easier by downloading the latest release of Forefront Security for Exchange Server with SP2. New features include visibility of all actively published engines, alerts and notifications of new engine availability, and rollup of software fixes. For more information on antimalware engine updates with this service pack, please refer to Antimalware Engine Notifications and Developments.
· Forefront Security for SharePoint with Service Pack 3 Now Available
Help better protect your Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 collaboration environments from malware and inappropriate content by downloading the latest release of Forefront Security for SharePoint with SP2. New features include visibility of all actively published engines, alerts and notifications for new engine availability, and rollup of software fixes. For more information on antimalware engine updates with this service pack, please refer to Antimalware Engine Notifications and Developments.
· Microsoft Antigen 9.0 with Service Pack 2 Now Available
Improve protection for Exchange Server 2003 and Exchange 2000 Server by downloading the Microsoft Antigen 9.0 with SP2 releases. New features include visibility of all actively published engines, alerts and notifications of new engine availability, improved anti-spam detection through integration of Cloudmark engine, and rollup of software fixes. For more information on antimalware engine updates and Cloudmark antispam integration with this service pack, please refer to Antimalware Engine Notifications and Developments.
Download the new Antigen service packs here:
o Antigen for Exchange with Antigen Spam Manager 9.0 with Service Pack 2
o Antigen for SMTP Gateways with Antigen Spam Manager 9.0 with Service Pack 2
Today, Microsoft released a new version of Forefront Online Security for Exchange (FOSE) (Release 9.1). FOSE online filtering helps protect inbound and outbound e-mail traffic from spam and viruses. FOSE can be used to provide an additional layer of protection for your Microsoft Exchange messaging infrastructure.
Read more about the new release on the Forefront Team blog here.
FSS UE Team
Hello –this is Kelly Borndale, a PM from the Forefront Services/Ops Team!
Due to growing threats, the size of files downloaded within the antivirus engine definition update packages has grown over time (previously mentioned here). In order to get definition updates to Antigen and Forefront Server products as efficiently as possible, we have begun to move parts of our definition updates to a content distribution network (CDN). This brings the larger parts of the definition updates to servers located closer to you, in the Internet sense. It also allows your servers to download definition updates faster, during “normal” definition production times, as well as in the event of an outbreak, when definition production would occur more frequently.
Previously, there had been concern about how CDNs would work with our product’s frequent update pattern. CDNs are historically very good at having cached copies of files which don’t change very frequently, but what happens when you have files that change frequently, such as our manifest and metadata files? Internally, we had concerns about our clients getting old update information because of file age and the constant re-writing of our metadata and manifest files. We wanted to make sure that the latest definition updates were always available, but, we also needed to make sure that we could react to surges in definition update size or frequency, on the fly
Working with our Operations team, we came up with a plan to address these concerns. We’ve set up our file cache policies to make sure that all the manifest and metadata requests go directly to our origin servers. These are the servers where our back-end definition processing service publishes definition updates directly to, meaning these files are not served via the CDN. This alleviates any concerns about the CDN’s handling of frequently changing files, as the CDN isn’t the entity providing these files.
This change is largely invisible to anyone using the product line. We’ve worked to come up with a solution that will work with in-market products, as well as upcoming releases. That said, there is one customer scenario that may be affected by this change. If the server that downloads the definition packages from the Internet is behind a firewall that restricts outbound access via port 80 to the Internet, definition updates may fail. To work around this, make sure that your Antigen and Forefront Servers are able to send http traffic to the Internet. If there are security concerns around opening up the outbound traffic for your Antigen or Forefront Servers, redistribution servers can be used as a tool to bring updates from the Internet into your internal network. This set up has a redistribution server accessing the Internet over port 80. The redistribution server then hosts the packages, internally, for the mail servers. This allows you to continue to restrict the mail server’s access to the Internet. For information on configuring distribution servers, please read the following help topics:
For FSE: http://technet.microsoft.com/en-us/library/bb795083.aspx
For Antigen: http://technet.microsoft.com/en-us/library/bb914037.aspx
For FSSMC: http://technet.microsoft.com/en-us/library/bb878182.aspx
K.Borndale
IT/Ops Program Manager
Hello.
My name is Frank Trujillo, and I want to tell you about a new capacity planning tool the FSS team just released.
The Forefront Security for Exchange Server capacity planning tool helps you understand what hardware, architecture, and configuration settings will produce recommended system performance and message throughput results for comprehensive protection of your Exchange Servers. The tool is an Excel spreadsheet with built in workflow and can be used to help plan your Forefront Security for Exchange Server 10 SP1/SP2 deployment.
With the tool, you will be able to plan the details for a new deployment or understand the impact of adding security protection to an existing deployment. To use the tool, you will need to have information on hand about your Exchange environment, server hardware, and user load.
Once this information is entered into the workflow, the tool will make deployment recommendations that can be used to meet your specific objectives. You can also take the liberty to augment the results based on relative hardware performance – links are provided in the resource tab of the tool.
You can download a free copy of the FSE capacity planning tool at: http://www.microsoft.com/downloads/details.aspx?FamilyID=522da65d-5263-4f5d-b929-8428a394b9af&displaylang=en
After downloading the tool, you should first read the “Directions” and “Readme” tabs for complete information on using the tool. A “Resource” tab is also provided with links to obtain additional data to help make an informed decision during the planning stage.
Please keep in mind, however, that the FSE tool is not a replacement for thorough Exchange capacity planning. The expectation is that the deployment architecture adheres to the Exchange 2007 capacity planning guidelines.
Feedback or enhancement requests about the tool are appreciated. You can send comments directly to frankt@microsoft.com.
Thanks for reading.
Frank Trujillo
Program Manager - FSS
Hey folks,
We get lots of questions on our forums and lots of calls to our support staff about installing FSE and Antigen on clustered Exchange servers. Obviously, installing on clustered servers is a whole different animal from installing on single servers and requires additional guidance.
In response to that need, our UA team produced cluster install guides in 2008 for FSE and Antigen. These guides give you system requirements, step-by-step installation guidance for installing on several different types of clustered servers, upgrading guidance, and step-by-step guidance for uninstalling FSE and Antigen from clustered servers.
The guides can be found in our technical library on TechNet:
Forefront Security for Exchange Server: http://technet.microsoft.com/en-us/library/bb892168.aspx
Antigen for Exchange: http://technet.microsoft.com/en-us/library/bb913988.aspx
Our excellent support team has also written many Knowledge Base articles about installing FSE and clusters that you may want to review before installing FSE on clustered servers or if you are having problems with FSE on clustered servers. These include:
· http://support.microsoft.com/kb/939365
· http://support.microsoft.com/kb/950586
· http://support.microsoft.com/kb/943616
· http://support.microsoft.com/kb/941272
· http://support.microsoft.com/kb/929081
If you have feedback on the guides or any of our documentation, please send us a note at fss-ue@microsoft.com.
Be safe out there-
FSS User Experience team
Hello from TechEd 2009!
I want to thank all of the attendees that have come to our booth and sessions.
The conference has been well received by the attendees. Overall there has been great interest in the virtualization and Software as a Service (SAAS) offerings. Windows 7 and Windows Mobile are also attracting a lot of interest.
On the FSS side we have seen a lot of interest in our Forefront Online Security for Exchange (FOSE), Forefront Security for SharePoint (FSSP), and Forefront Security for Office Communications Server (FSOCS) products. There is also great interest in the Stirling wave, which will bring central security management and enterprise security visibility. From a broader perspective there is also great interest in the future directions of security + identity solutions as well as data leakage protection(DLP).
If you are here at TechEd, stop by our booth and see us today.
Mitch Hall
Program Manager, Forefront Server Security
(Warning: If you’re looking for anything insightful or related to Forefront technology, you can skip this post.)
After hitting numerous development target dates for FSE and doing some serious work to deliver the next generation of Forefront, the Long Island development team got a chance to take some time off. The Forefront Server team went to a local theatre on Friday for the first showing of Star Trek.
This was one of those things that makes life in software development more fun. Doing software development is already a lot of fun. However, taking the morning off to see the latest Star Trek is kind of like getting a gift when you don’t expect it. (Did I mention that I love stadium seating?)
So more than 100 of us went out to see Star Trek. They don’t call it anything else, just “Star Trek.” It’s about the original crew before they were the original crew. If you remember the original series, you’ll probably like the movie. It had some interesting twists and stayed close enough to the original to keep our diehard Trekkies happy. Everyone was well behaved, except for Ken’s cell phone, which went off during Spock’s life changing event.
When we got back we spent a lot of time at lunch talking about the technology. If you go see the movie, you should know that:
1. It really is possible to free fall from outer space and land safely with a parachute.
2. Warp drive is not impossible, although it might take longer than 140 years for us to develop one.
3. I didn’t see any computer technology of particular interest. Most of the cool things were kinetic.
Jim Molini, CSSLP
As you might guess, DNSBL stands for DNS Blocklist. While it’s not a new technology, the usefulness of various DNS/RBL blocklists in fighting spam is indisputably immense. Over the years I’ve heard both the success stories from folks who implemented RBLs in their Exchange server deployments, and I’ve heard some horror stories from the folks who’s IPs were maliciously or mistakenly added to RBLs and the difficulties they had working with blocklist providers to delist their IPs from the RBLs. Another contributing factor to the overall painful experience with RBLs is the fact that you need to configure them with appropriate response codes and delisting logic etc. It’s manual work and as such is very error-prone. Also, some of the blocklist providers will expose their lists for free to small customers only. For example, they will allow only a certain number of queries against the blocklist per day and if the query volume exceeds the allowed (and very small in reality) free amount they will either block the queries (firewall) or ask the customer to receive the blocklists via paid subscription. If you are going to use a free DNS blocklist, you need to make adjustments (lower expectations) regarding the quality of service. Considering these factors, some Exchange admins prefer to stay away from blocklists because they just do not want to go through the headache generally associated with maintaining multiple RBL providers’ configurations.
The Forefront DNSBL
So what’s up with the Forefront DNSBL? What is it and how is it different from the rest? In short, the Forefront DNSBL is an aggregated list of multiple feeds from various RBL providers combined into a single lookup and hosted by Forefront Online Security for Exchange (FOSE) on its own DNS infrastructure. The list of feeds includes both Microsoft-internal contributing teams and external vendors (for example, Spamhaus). Forefront DNSBL is already available to customers in the next generation of Forefront Security for Exchange Server (Beta 2) (you can get Beta2 here) and it is royalty-free (hey, we all like free stuff, do we not?) to Beta 2 customers. So if you are thinking of evaluating Forefront Security for Exchange Server (Beta 2), I encourage you to download it and give it a shot.
With Forefront DNSBL implementation you will get configuration and maintenance-free DNSBL solution that is enabled out of the box without any manual work needed from the administrator to configure and maintain the filter. Forefront DNSBL will start working immediately after the setup (just do not forget to opt-in to antispam during the setup phase) and there is nothing to configure. This is how it looks in the Forefront Security for Exchange Server UI:
As you can see, there is nothing to configure, just a simple checkbox to enable/disable the DNSBL checking. Similar to the basic Exchange 2007/2010 server RBL functionality, Forefront DNSBL has been implemented as an agent and executes based on the connecting IP address. However, this is where the similarities end. So what’s in the guts of Forefront DNSBL and how does it work?
While Forefront DNSBL agent also makes the trip to the DNS blocklist provider (maintained by FOSE), the DNS query itself has been encrypted. You might ask why is it encrypted? Well, due to the nature of DNS (which is not secure) and having an obligation to preserve our contributing vendors’ proprietary data from unauthorized access by the non-Forefront customers, we decided to hash the DNS query. On the DNSBL provider end, the hosting DNSBL server runs the same algorithm to decrypt the incoming query and verify its integrity. If the query is confirmed to be legitimate, (only the Forefront agent knows how to encrypt and decrypt the query) the DNSBL provider will service it. If the query has been constructed incorrectly or the hash does not compute correctly, the returned query will contain NXDOMAIN response. Yes, we go the extra mile in protecting our vendors’ intellectual property (RBL data) and will service only Forefront customers (As a legit Forefront customer, you really do not care whether the query is encrypted or not but you do care about the quality of service, right?).
So the original query to the DNSBL provider is hashed. However, the returned query is not and if a match is found on one of the contributing feeds, the DNSBL service provider will return the appropriate response. For example, if the match is found on the FOSE internal blocklist, the returned query will contain 127.0.0.5 response. If the match is found on Spamhaus’ XBL list, the return query will be 127.0.0.4 and if it’s found on SBL, the query will be 127.0.0.2. Accordingly, the Forefront DNSBL agent will reject the e-mail transaction inside of SMTP session with a response explicitly crafted for the particular DNS query return code. This is how the response looks like if the IP match was found on one of the blocklists:
There are 3 parts in the Forefront DNSBL response issued by the agent:
1. Default machine code (understandable by the server’s SMTP stack)
2. Default human-readable response string
3. FSE-specific delisting information.
The human-readable response string contains vital information about the blocklist (feed) name that contains a match for the IP address. Having this information will help alleviate the pain of delisting if the IP was blocklisted mistakenly and expedite the delisting process and time.
The FSE-specific delisting information references specific action for the end user to take. In most cases, the end user needs to forward the NDR to the delist@frontbridge.com alias. The forwarded message (NDR) will then be evaluated by the Forefront analysts (DNSBL support services) and corrective action will be taken to delist the IP from the appropriate blocklist. If the IP was blocklisted by one of the external feeds, the delisting string will contain appropriate information about how to correct the problem. In essence, delisting is a very easy and almost pain-free process as we made it as simple and straightforward as possible.
Now let's talk about the effectiveness of the Forefront DNSBL. Having multiple data feeds combined into a single database and a single lookup not only increases the efficacy and robustness of the solution but improves the performance of Exchange server because now it's a single DNS trip instead of multiple (if you have more than one RBL provider configured as most Exchange admins do). Based on the feedback from Beta 2 customers, the contribution of Forefront DNSBL to overall spam rejection rate is around 90% (it varies by the geographical location/regions of the world). This effectively means ~90% of all incoming e-mail transactions get immediately rejected at the gate without pushing unnecessary payload through the network layers. This preserves network bandwidth and Exchange server processing time, which translates into money saved (Plus, the service is free.).
Quite frankly, it took me more time to write this blog than for a Forefront admin to enable and start using DNSBL! The bottom line – Forefront DNSBL is maintenance-free, hands-off, built-in feature capable of producing very impressive results in antispam protection. So, YEAH or NAY? I’d say YEAH BABY! Let me know if you disagree.
Alex Nikolayev Program Manager, Forefront Server Security
Recently, customers have been asking whether Microsoft supports Antigen 9.0 and Forefront Security for Exchange Server on third-party clusters (meaning non-Microsoft Cluster Service clusters). The following blog describes Microsoft’s official support policy for Microsoft Antigen 9.0 for Exchange and Forefront Security for Exchange Server running on non-Microsoft clusters.
Microsoft Customer Support Services (CSS) supports Microsoft Antigen 9.0 for Exchange Server and Microsoft Forefront Security for Exchange Server clustering based on the failover clustering features of the Microsoft Cluster Service (MSCS). The MSCS is provided with applicable versions of Microsoft Windows operating system software. To be fully supported by CSS, a Microsoft Exchange installation that is running on MSCS must be installed on hardware that has passed Windows Catalog testing as a cluster system. For more information about the Microsoft support policy for server clusters and the Hardware Compatibility List, see the article “The Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server Catalog” in the Microsoft Knowledge Base: 309395 (http://support.microsoft.com/kb/309395/)
Several third-party vendors offer clustering services and solutions for applicable versions of Microsoft Windows operating system software that do not rely on MSCS. CSS will try to help a customer troubleshoot and provide support for an Exchange-related issue when Exchange is installed on a third-party clustering solution. CSS will try to help a customer with such issues until it is reasonably believed that the cause of the issue is an incompatibility between the third-party clustering solution and Exchange. As part of making this determination, CSS may try to independently reproduce the issue. If the issue cannot be reproduced in a fully supported Exchange clustering environment, (For example, MSCS clustering on a Windows Catalog certified cluster system.) CSS may refer the affected customer to the vendor of the third-party clustering solution or suggest removing the third-party solution to help resolve the issue.
To be very clear, removal of the third-party clustering solution is not a precondition to receiving CSS’s support services. However, if less drastic troubleshooting efforts do not effectively resolve the issue, and there is a reasonable basis for CSS to believe that the third-party clustering solution may be the cause of the problem, CSS may have to request that the customer remove the third-party solution in order to continue troubleshooting. Otherwise, CSS may have to refer the customer to the vendor of the third-party clustering solution for additional troubleshooting support.
The customer will be completely responsible for engaging a vendor’s support organization. CSS will try to provide the customer with reasonable assistance in working with a vendor’s support organization to help resolve a customer’s cluster service issues. However, CSS should not be considered the primary liaison between the customer and the vendor. We strongly recommend that customers develop support relationships with each vendor whose hardware or software is part of their Exchange solution.
Microsoft does not perform in-depth testing of applicable versions of Windows or Antigen 9.0 for Exchange Server or Microsoft Forefront Security for Exchange Server software with third-party vendor services and solutions. Additionally, there is no Microsoft hardware or application certification program for these solutions. Therefore, we cannot provide information about the actual performance or interaction of third-party clustering services and solutions that are running Exchange.
The following table outlines the specific versions of Microsoft Antigen 9.0 for Exchange Server and Microsoft Forefront Security for Exchange Server and Windows software that are required to create MSCS-based Exchange clusters.
Operating system version/Exchange version
Microsoft Antigen 9.0 for Exchange
Microsoft Windows Server 2003 Enterprise
Microsoft Exchange Server 2003
Microsoft Antigen 9.0 for Exchange Server SP1
Microsoft Forefront Security for Exchange Server
Microsoft Exchange Server 2007
For more information about the configurations for Exchange running on MSCS-based clusters that we recommend, visit one or both of the following Microsoft Web sites:
· Antigen for Exchange Cluster Installation Guide http://technet.microsoft.com/en-us/library/bb913988.aspx
· Forefront Security for Exchange Server Cluster Installation Guide http://technet.microsoft.com/en-us/library/bb892168.aspx
Holly L. Kipp
CSS Security Senior Support Engineer
Hi, my name is Shrey Shah and I am a developer on the Forefront Server Security team based in Long Island, NY. I work on various projects related to engine update delivery for the Forefront Server products as well as feature development for new products. I played an active role in the design and development for the Forefront for OCS release over the past year and a half.
The Office Communications Server Team provides a load simulation tool for OCS 2007 R2 deployments to aid in capacity planning. This tool can also be used to estimate the capacity of an OCS server with Forefront Server for Office Communications Server (FSOCS) installed. The remainder of this article provides a high level overview of steps an administrator can take to measure FSOCS throughput performance. These measurements can be used to estimate the capacity of a particular server given a usage model and an FSOCS configuration. It is assumed that the server hardware complies with the recommended hardware for an OCS 2007 R2 installation.
· Familiarity with Forefront Server product configuration
· OCS 2007 R2 Capacity Planning Toolkit
1) Install FSOCS on an OCS 2007 R2 Front-end or Standard Edition server.
2) Configure FSOCS with a desired set of engines as well as any other filter options that would be used in a production deployment. Make note of the number of scanning processes FSOCS is configured to use (default is 4); this value will be used later.
3) Install and configure the OCSLoader simulation tool according to the documentation provided by the OCS capacity planning documentation.
4) Configure the tool using the low or medium setting and 1000-2000 users (this assumes that the hardware being tested can sufficiently process this workload). When selecting the types of content to simulate, note that only IM traffic will be processed by FSOCS.
5) Before running the tool, configure the Windows Performance Monitor to capture and log the following counters:
a. Microsoft FSOCS Scan Filter : AverageProcessingTimeIMConversations
b. LC:SIP – 03 – Requests : SIP – 011 – Incoming MESSAGE Requests/sec
1) Run the load simulation for 3-4 hours (this allows for sufficient time for all the users to be logged in and produce a steady state of IM traffic).
2) Stop the Performance Monitor log capture.
1) Open the performance monitor log.
2) When viewing the collected counters, notice that the “Incoming MESSAGE request/sec” counter first ramps up, then reaches a steady state. Make note of the time period in which the message rate is at steady state.
3) Restrict the log data view to only the time period where the message rate is at steady state.
4) For the specified time period, make note of the average value for the “AverageProcessingTimeIMConversations” FSOCS performance counter. This value indicates the average scanning time in seconds per IM message. For a given FSOCS configuration, the inverse of this value provides an estimate of the message throughput rate FSOCS can achieve on the given hardware per scanning process configured. For example, an average scan time of 0.018 seconds with 4 scanning processes configured (default), yields:
1 / 0.018 = 55 messages / sec / scanning process
55 messages / sec / scanning process * 4 scanning processes = 220 messages / sec
This calculation provides an estimate as to what throughput FSOCS is able to scan on the hardware the test is being run on given a specific configuration (engine selection, number of scanning processes, configured filters, etc.).
5) Compare the values calculated above to the average value of the “Incoming MESSAGE request/sec” OCS counter and note the relative differences.
6) A system with FSOCS installed on it should, on average, have an “Incoming MESSAGE request/sec” rate that is less than or equal to the calculated value above. Even though FSOCS is able to process bursts of activity where the incoming message rate exceeds its processing capacity, a system in which the average rate is higher than the capacity will experience unwanted behavior. Since instant messages should be “instant”, queuing messages isn’t a tangible option and thus a system’s throughput can go only as fast as FSOCS can scan messages.
By varying the simulated IM rate and/or the number of users, one can determine the maximum number of users an OCS server can support when FSOCS is installed. The table below summarizes the pre-defined usage profiles that are included as part of the OCSLoader tool. The XML file that is generated during the load simulation setup process can be modified to simulate a custom profile. Additionally, the table shows the profile based on which OCS defines its notion of “Maximum Supported Users” per server.
IM Usage Model Profile
Conversations/day
Conversation Length (min.)
IM Sent/Minute
IM Rate / sec / 1000 users
Low
7
120
2
20
Medium
14
40
High
24
67
Max Supported Users*
1
6
Note*:
The OCS 2007 R2 Capacity Planning documentation references a usage model based upon which supported configurations are defined. The notion of “maximum” supported users per server depends primarily on the server hardware and the usage model for IM traffic. The “Max Supported Users” profile setting is based on the user model defined in the OCS 2007 R2 Capacity Planning documentation for IM Sessions. This model is not automatically generated by the OCSLoader tool, however it is provided as a point of reference.
7) Once the average scanning rate of FSOCS has been determined, an administrator can estimate the number of users that can be supported by the server by using the table above or through experimentation using the OCSLoader tool. For example, if an organization’s IM usage model fits the pre-defined “medium” profile, we can use the calculated value above:
220 / 40 = 5.5 * 1000 = 5,500 users
Using the FSOCS configuration that was measured, a server similar to the one measured could support approximately 5,500 users.
When going through the process described in this article, there are a number of factors to consider that can affect the potential throughput that FSOCS is able to process. The items listed below summarize some of the key variables that may affect performance; this list should not be considered all-inclusive.
· Engine Selection: Forefront provides protection from multiple antivirus engines. Each individual engine has a different performance profile and as such may have different impacts with regards to scanning throughput. Some engine selections may be better suited for the type and/or rate of traffic a particular environment processes.
· Number of scanning processes: FSOCS can be configured to use a varying number of scanning processes. The number of scanning processes determines the maximum number of messages that can be scanned in parallel. It is recommended that this number matches the number of CPU cores on a particular server since these processes perform CPU bound computations. By default, this value is 4, however it can be changed using the Forefront Server Administration Client.
· Memory Requirement: The memory footprint of FSOCS grows linearly with the number of scanning processes. That is, its requirement would be modeled as <base> + <# of Scanning Processes> * <memory / scanner>. <base> accounts for the invariable FSOCS processes such as FSCController.exe, ForefrontRTCProxy(64).exe, and ForefrontNotificationAgent.exe. The <memory / scanner> value will vary depending on the selected set of engines.
Process Name
Memory Utilization Pattern
FSCController.exe
Average size can be estimated by measuring size after Forefront services have been started.
ForefrontNotificationAgent.exe
FSEMailPickup.exe
ForefrontRTCProxy(64).exe
Memory utilization may vary depending on system load and the schedule of the .NET garbage collection.
FSOCScanner.exe
Memory utilization will vary depending on the selected set of engines. Total memory requirement should account for multiple instances of this process, each of which consume a similar amount of memory. Average size can be estimated by measuring the size of the process after messages have begun to flow.
· Enterprise Topology: FSOCS can be installed on multiple OCS server roles (i.e. Access Edge, Director, Front-end). By default, FSOCS optimizes message scanning by ensuring that messages are only scanned by a single server as it is routed from sender to recipient. The guidance above shows a methodology that allows one to measure the capacity on a server by server basis. In an enterprise topology where some considerable percentage of the traffic flows through the Access Edge and/or a Director server roles, the impact of scanning with FSOCS on the front-end (or standard edition) servers can be reduced by installing FSOCS on the Access Edge and/or Directors.
· Message Sizes: Typically IM messages are expected to be small. The OCSLoader tool simulates using very small messages by default. If the default message sizes are smaller or larger than what an administrator expects in their environment, these message sizes should be changed before running the simulation to give a better estimate as to how FSOCS will perform in an production setting.
· Consolidated OCS Server Roles: If an OCS server is running a consolidated configuration with multiple roles on a single server, both OCS and FSOCS will be competing for both memory and CPU. When performing the simulation described in this document, be sure to simulate traffic for any role that is expected to be consolidated with IM presence and messaging.
· Engine Updates and Bias Settings: FSOCS can be configured with various bias settings for antivirus scanning. For more information about each setting, please refer to the FSOCS user guide for details. By default, the bias is set to “Favor Certainty”. If the bias setting is changed to “Max Certainty”, this provides the maximum level of antivirus protection in that all selected antivirus engines are required for every message scan. Typically this does not pose an issue, however one side effect of using this setting is that when a selected engine is being updated, message scanning is suspended until the update is committed. Due to the real-time nature of instant messaging, this may have an adverse effect on the perceived user experience.
I hope this information will help you plan your OCS deployments with FSOCS more effectively. Feel free to use the Microsoft Forefront Security for OCS TechNet Forum to reach us.
Shrey Shah
Developer - FSS
Hello. This is Jim Molini from the Forefront Server team and it’s that time of year again. The Forefront team is at RSA 2009 and people are asking about the new Forefront Security line. After two days of meeting with customers we are seeing lots of interest in integrated security and the new features being offered with the Stirling wave.
This year, I came early to attend the (ISC)2 20th Anniversary Dinner and Reception hosted over at the JW Marriott. It was a great gathering of people from the Information Security Community. We had Donn Parker, Bill Murray, Dr. Jae Woo Lee, Hal Tipton, Rolf Moulton, and many of the early pioneers in our industry all in the same place for an evening. Everyone had a wonderful time.
At the conference site, the opening reception on Monday went smoothly. We’re staffing it with more than 30 people from all over the division and we’ve got some partners who are helping to extend the Forefront line with related technology.
Tuesday, Scott Charney talked about Trustworthy Computing and Business Ready Security. He summarized some of the work our team has been doing to prevent the kinds of criminal activities that seem to affect every corporation today. You can find a link to that talk here.
I’d like to highlight a couple of items from the show today. First, the public beta of Forefront Security for Exchange is available for download and has industry leading capabilities. As we’ve done for years, we continue to provide the highest malware catch rate in the industry for Exchange servers. We’ve added premium antispam to the mix to significantly reduce the threats coming through common network entry points. Then with the integration of the central management console in the "Stirling" suite, you will be able to manage large installations from a single location. Stop by the booth this morning and I’ll show you how it works.
Also at this show we have unveiled a new partner initiative that takes the best technology from a number of well known industry organizations and extends the reach of Forefront beyond the traditional scope. These partners are building enhancements and bringing new capabilities to the Forefront line by integrating their advanced security technology with the new centralized console in Forefront code named “Stirling.” Today we have 10 partners who have signed on as charter members of this team and we expect to have more coming in every month. If you want to be a partner with the Forefront team, come by the Partner spot and see how we can work together on better security solutions.
Like I’ve said, if you’re at the RSA conference, stop by the booth and say hello. If you’re online, follow my movements today on Twitter.
Jim Molini, CSSLPSenior Program ManagerForefront Server Security
Microsoft is pleased to announce the beta 2 release of Forefront Security for Exchange Server (FSE) and Forefront Security for SharePoint (FSSP). Each product contains new features and abilities that will make it easier to protect your environment.
Each of the areas of our documentation (Deployment Guide, Operations Guide, Technical Reference, and Troubleshooting Guide) has been augmented to enable you to use these features. In addition, there are many new topics that can be accessed on Microsoft TechNet.
New FSE topics include:
The FSE Deployment Guide now includes instructions for:
http://technet.microsoft.com/en-us/library/dd639342.aspx
http://technet.microsoft.com/en-us/library/dd639345.aspx
http://technet.microsoft.com/en-us/library/dd639353.aspx
http://technet.microsoft.com/en-us/library/dd639344.aspx
The FSE Operations Guide now includes instructions for:
http://technet.microsoft.com/en-us/library/dd639375.aspx
The FSE Technical Reference now includes details about:
http://technet.microsoft.com/en-us/library/dd639406.aspx
http://technet.microsoft.com/en-us/library/dd639408.aspx
http://technet.microsoft.com/en-us/library/dd639413.aspx
http://technet.microsoft.com/en-us/library/dd639411.aspx
http://technet.microsoft.com/en-us/library/dd639409.aspx
New FSSP topics include:
The FSSP Deployment Guide now includes instructions for:
http://technet.microsoft.com/en-us/library/dd639421.aspx
http://technet.microsoft.com/en-us/library/dd639419.aspx
The FSSP Technical Reference now includes details about:
http://technet.microsoft.com/en-us/library/dd639434.aspx
http://technet.microsoft.com/en-us/library/dd639427.aspx
http://technet.microsoft.com/en-us/library/dd639433.aspx
http://technet.microsoft.com/en-us/library/dd639430.aspx
http://technet.microsoft.com/en-us/library/dd639428.aspx
To find out more about the new beta 2 release and to get started using it, see the complete documentation at the following Microsoft TechNet locations:
Forefront Security for Exchange Server:
http://technet.microsoft.com/en-us/library/cc482983.aspx
Forefront Security for SharePoint:
http://technet.microsoft.com/en-us/library/cc482990.aspx
http://technet.microsoft.com/en-us/library/cc482995.aspx
Marv Goldberg
Technical Writer – FSS UA