Forefront Security for SharePoint Manual Scan Issues

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

Now Available – Antigen and Forefront server security service packs!

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 3^rd 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

Forefront Online Security for Exchange (FOSE) version 9.1 is released

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.    

Michel LaFantano

FSS UE Team

Downloading antivirus definition updates from a content distribution network

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

Introducing the Forefront Security for Exchange capacity planning tool

Help with installing Forefront Security for Exchange Server on clustered Exchange servers

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-

Michel LaFantano

FSS User Experience team

Forefront Server Security at TechEd 2009

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

Trek Day for the FSS Team

(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

Forefront Server Security

Forefront DNSBL… Yeah or Nay?

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. 

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

Microsoft Support Policy for Antigen 9.0 and Forefront Security for Exchange Server Installed on Third-party Clusters

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.

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 

Estimating the Capacity of an OCS 2007 R2 Server with FSOCS

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.

Pre-requisites

·         Familiarity with Forefront Server product configuration

·         OCS 2007 R2 Capacity Planning Toolkit

Configure the Test Bed

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

Run the Load Simulation

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.

Analyze Results

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.

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.

Other Considerations

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.

·         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

RSA 2009 – Show Notes

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)² 20^th 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, CSSLP
Senior Program Manager
Forefront Server Security

New documentation for FSE and FSSP beta 2 releases

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:

• Installing FSE on Database Availability Groups (DAG):

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

• Installing FSE on a Hyper-V platform:

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

• Installing and maintaining FSE in a multiple server environment:

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

• Enabling public folders for the on-demand scan (for Exchange Server 2010):

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

The FSE Operations Guide now includes instructions for:

• Purging worm-infected messages:

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

The FSE Technical Reference now includes details about:

• Installing FSE in unattended mode:

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

• FSE services:

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

• Default folders:

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

• Incidents reported by FSE:

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

• Event ID codes:

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

New FSSP topics include:

The FSSP Deployment Guide now includes instructions for:

• Installing FSSP on a Hyper-V platform:

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

• Installing and maintaining FSSP in a multiple server environment:

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

The FSSP Technical Reference now includes details about:

• Installing FSSP in unattended mode:

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

• FSSP services:

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

• Default folders:

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

• Incidents reported by FSSP:

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

• Event ID codes:

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:

• Main documentation site:

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

• Fast link to the release notes:

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

Forefront Security for SharePoint:

• Main documentation site:

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

• Fast link to the release notes:

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

Marv Goldberg

Technical Writer – FSS UA

Announcing the beta 2 public release of Forefront Security 2010 for SharePoint

We are proud to announce the release of Forefront Security 2010 for SharePoint Beta 2 (FSSP).

·         FSSP provides industry leading antimalware protection by simultaneously using up to 5 individual antimalware engines.  Protection is provided for both viruses and spyware. Protection is also provided by 3 separate types of scanning processes: 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.

·         FSSP’s new UI delivers monitoring, configuration, and management capabilities. The monitoring section provides a dashboard displaying the individual engine status information. It also includes incidents and quarantine management screens. The monitoring section also provides for the configuration of incident and event notifications.  The tasks section provides the ability to scan individual sites or site collections. The Protection Settings panel allows the configuration of the scan processes. There is also a section for building file and keyword filters.  Finally, it contains sections for scan and engine update settings.

·         FSSP’s UI is built on top of a fully scriptable PowerShell interface. This interface provides access to the full range of management capabilities through a programmatic interface. This interface can be leveraged for interactive use through the Forefront PowerShell console or programmatically though PowerShell scripting or other .Net based programming language.  Common tasks can be automated and integration can be achieved through this flexible interface.

Introducing Forefront Security for Exchange Beta 2 Antispam Technologies

Hi, my name is Alex Nikolayev and you might remember me for my previous work with Exchange server Transport.  Having an unconditional love for Transport, I moved to Forefront Server Security team to help with delivering cool new features to protect it from all sorts of malware (spam included). 

Over the years, talking about the spam problem and how to get it under control, we were referencing four major pillars that contribute to the overall strategy and success in the fight against spam:

1.       Effective Legislation,

2.       Innovative Technologies,

3.       Industry Cooperation and Collaboration,

4.       User Education.

While I can’t really talk about the legislation (I’m not a lawyer) and user-ed (this needs to be done by every Forefront admin in every Exchange organization), I want to tell you about the new antispam technologies Forefront team delivers in close collaboration with the industry partners.

Forefront Server Security is well known for integrating the most efficient antimalware engines into the product, so it’s no wonder we decided to do the same for the antispam.  The new Beta 2 release of Forefront Server Security 2010 comes with features that were jointly developed with our external partners.  So what is under the FSE 2010 Beta 2 hood? 

Today I will talk about the new content filter.  I know it’s an impossible task to cover a wealth of new information in a single blog so this time I will provide only a high level “introductory” overview of what it is and how it functions (do not worry, I will write more blogs about the filter internals, best deployment and configuration practices, and how to get the most out of it). 

The new Forefront content filter is a result of collaborative work between my team and Cloudmark^®.  At the heart of the filter is the Cloudmark Authority® Engine which is natively integrated into Forefront’s antispam framework.  It functions exactly the same way as the antispam content filter engine in Exchange 2007 by verifying the content of the message for spamminess.  The engine produces a raw spam score that is normalized by the content filter agent (actually by the adaptor which does the translation from the raw spam score to SCL) and at the end the content filter agent stamps an SCL value onto the message.  The SCL value is in the same format as the SCLs previously stamped by the Exchange 2007 and Forefront 2007 content filter agents.  So if you have any custom agents acting upon an SCL value on the message, they will continue to function without the need for modification.  The biggest difference in SCL assignments is the SCL range distribution.  Do not expect to see a lot of SCLs between SCL:5 and SCL:9 and do not expect to see anything in the range between SCL:1 and SCL:4 inclusively.  The bulk of messages will be assigned either SCL:-1 or SCL:9.  This means no more garbage in the Junk E-mail Folder!  Sure, occasionally there could be a couple of messages with an SCL:5 or SCL:6, but the bulk of e-mail will be correctly classified as the legitimate or unsolicited bulk e-mail.  Look at the chart below (from the real data supplied by one of the Forefront Beta 2 TAP customers who is running with the Beta 2 build in production):

As you can see, almost 100% of all incoming mail was classified either as good mail or spam!  These results may vary depending on the deployment configuration, but the general trend is that you won’t see a whole lot of messages with SCLs between 0 and 8.

You might ask what about the accuracy of the engine and whether you can trust these results?  Just recently, the Forefront Security for Exchange running on Beta 2 build with the new Cloudmark-based content filter was rigorously tested by the West Coast Labs on live spam for 2 weeks. At the end of the test, FSE was awarded a Checkmark certification as a Premium product. Throughout the testing cycle the filter maintained a detection rate of 99%. 

I realize it’s quite a departure from the model and behavior we all got so used to – open the Junk E-Mail Folder in the morning and comb through the junk triaging it for potential false positives…  Guess what – no more junk with the new Forefront content filter so you’ll get your time back! 

Now keep in mind that this is not a silver bullet against spam.  Spammers constantly find ways to penetrate through the best defenses and deliver spam.  However, with our new Forefront Content Filter backed by Cloudmark’s technology with real-time response via Global Threat Network™ and advanced fingerprinting algorithms allowing for identification of spam mutations in real time, you will feel much safer and better protected from new spam outbreaks.