Today we are excited to announce formal support for Forefront Server Security for Exchange SP1 and Forefront Server Security for SharePoint SP1 running on the Hyper-V platform. This is part of a larger announcement that affects multiple Microsoft products, including Microsoft Exchange Server and Microsoft SharePoint Server.

Both products have been tested to confirm that all the functional aspects have the same behavior in Hyper-V virtual server environments as on physical servers.  They are also approved for any hypervisor based virtualization technology certified under the Microsoft Server Virtualization Validation program. 

This post provides an overview of deployment and operational considerations when running on Hyper-V. This information will also be made available as a TechNet article at a later date.

System Requirements:

The minimum server and client requirements for Forefront Security for Exchange and Forefront Security for SharePoint are essentially the same when installing in a virtual Hyper-V environment.   The application, OS, and hardware platform versions are limited, however, to those that are supported by Microsoft Exchange and Microsoft SharePoint on the Hyper-V platform.

For more details about Exchange and SharePoint support recommendations on Hyper-V, you should refer to the documents “Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments” and “Using SharePoint Products and Technologies in a Hyper-V virtual environment.”

Running Forefront in a guest virtual machine does not change the basic deployment, configuration, and operation guidance for the product. Refer to the Best Practices Guides and Operations Guides available on Microsoft TechNet for additional deployment and configuration considerations.

Forefront virtualization guidelines:

Once Exchange’s requirements for running in a Hyper-V environment have been met, there are specific guidelines for Forefront that must be followed:

Host specific:

• The host machine must have enough hardware resources to accommodate the virtual machines being deployed and their intended roles, and should be deployed with no other roles other than to provide virtualization.
• Memory and CPU intensive applications should not be run on the same host machine as the guest hypervisor.
• File level anti-virus scanning should be disabled on directories hosting the guest VHDs.

Guest specific:

• Guest VHD disks must be fixed.
• For performance reasons, it is recommended you choose SCSI or iSCSI based storage to host Forefront’s database files, preferably separately from the guest OS.
• File level anti-virus scanning should exclude all necessary Exchange and Forefront directories. 
• Snapshots in guest virtual machines is strongly discouraged and not supported.

Performance considerations:

Adding Forefront to an Exchange environment will add resource utilization on top of what Exchange, the guest OS, and host resource will be using.  To ensure that your virtual environment can handle the anticipated load from Exchange and Forefront, it is helpful to measure the performance counters before and after Forefront has been installed.  You can follow these steps to take these measurements:

• Prior to installing Forefront, take baseline performance counters on each of your virtualized Exchange servers.  We recommend you take counters based on (1) time of day, and (2) severity of load over several days to establish a general baseline.  You may also want to stress test your virtualized Exchange servers to understand the upper limits of CPU, disk I/O, and memory utilization requirements.
• Once Exchange performance figures have been established, install Forefront, re-take performance counters as described above, and note the differences.  This will give you an idea of the overhead Forefront will be adding to your environment.
• Based on the differences, you may want to adjust your virtual hardware requirements.  This may include allocating more memory, CPU affinity, and/or improved disk I/O.  Memory and CPU utilization are usually the most heavily impacted.
• Video settings within the guest OS should also be set to “best performance” to minimize guest CPU utilization.  Any unnecessary virtual hardware that will not be used by the guest or host OS or applications should be removed.
• Be cautious when adjusting process counts (Transport or Realtime), as this can quickly deplete memory resources in your guest virtual machine.  For example, Transport is set by default to 4 process counts.  If all 4 are in use, then the number of selected scan engines is multiplied by the number of Transport processes in use plus the size of the files being scanned.  For example:

(4) Transport Processes  X  (5) Scanner Engines @ 100mb each + File sizes = Memory utilization

Note: This is an example only and real world results will vary depending on multiple factors.

If you increase the Transport or Realtime process counts, add more scanner engines, and increase the engine bias, memory will quickly be exhausted.  In most cases, the default number of process counts is adequate; however, you should consult the best practice guide for further information on fine tuning these settings.  Additionally, use the performance data you collected earlier to help gauge how many process counts you should be using.

Krishnan Venkatasubramanian

Project Manager, Forefront Server Security