Anti-Spam and Anti-Malware Protection in Exchange 2013 (Part 2)

If you would like to read the other parts in this article series please go to:

Anti-Malware in Exchange 2013

Exchange 2013 comes out of the box with basic built-in anti-malware protection designed to help organizations combat viruses and spyware in their e-mail messaging environment. As a quick recap, viruses infect other programs and data, and spread throughout computers looking for programs to infect. Spyware, on the other hand, gathers personal information, such as login details or personal data, and sends it back to its author.

This basic anti-malware protection can be turned off, replaced, or paired with a cloud-based service (such as Microsoft Exchange Online Protection (EOP)) in order to provide a layered and more in-depth defense.

Forefront Protection for Exchange (FPE) vs. Exchange 2013

As we all know, in September 2012 Microsoft announced it was discontinuing further releases of all of the Forefront suite products, with FPE support expiring December 31, 2015. With this, Microsoft changed their security offerings in favor of a lightweight built-in, anti-malware filter in Exchange 2013. But how exactly does FPE compare to the built-in anti-spam and anti-malware capabilities of Exchange 2013?

The first difference from FPE is that the built-in anti-malware feature in Exchange 2013 uses only a single scanning engine, not multiple. This might not be a show stopper for some organizations, but it is definitely something to keep in mind.

Another limitation is the fact that Exchange 2013 only performs transport-level scanning, i.e., e-mails are scanned as they pass through the transport pipeline. Although transport-level scanning is very important, this means that it does not scan a mailbox store, meaning that imported items never get scanned unless they are sent to someone, for example. Also, imagine that an e-mail containing a virus that Exchange does not yet detect, gets delivered. When Exchange is updated with a signature for the virus, the e-mail will never be scanned and the user is free to open the infected e-mail as opening an e-mail that has already been delivered to the user's mailbox does not require the e-mail to pass through the transport pipeline.

The following table should provide some clarity around what is offered and what is not with Exchange 2013:



Exchange 2013

Scanning e-mails in   real-time (transport scan)



Scanning mail store   (mailbox scan)



Scanning e-mails   when accessed (mailbox scan)









Attachment filter



Table 1

Enabling, Disabling and Bypassing Malware Filtering

If the default installation options of Exchange 2013 are selected, anti-malware filtering is enabled by default. If, for any reason, you chose to disable it during installation and now wish to enable it, you use the Enable-AntimalwareScanning.ps1 script. This script enables the malware agent and configures regular updates.

Start by navigating to the Exchange Scripts folder and then run the script mentioned above:

CD $ExScripts


Restart-Service MSExchangeTransport

Figure 2.1: Enabling Anti-Malware Scanning

It is also possible to disable or bypass malware filtering of all e-mails in transit. For example, administrators may want to disable Exchange 2013 malware filtering if they are using another product for malware filtering. When malware filtering is disabled, the Exchange malware agent is unhooked and not running, and engine updates are not kept up-to-date.

Bypassing malware filtering should only be done when troubleshooting a problem. When malware filtering is bypassed, the Exchange malware agent remains hooked, and engine updates are kept up-to-date. However, malware filtering is skipped while administrators attempt to resolve whatever problems they are facing. After finishing troubleshooting, malware filtering should be restored.

Disabling Malware Filtering

To disable malware filtering, run the Disable-Antimalwarescanning.ps1 script and restart the Exchange Transport Service:

CD $ExScripts


Restart-Service MSExchangeTransport

Figure 2.2: Disabling Anti-Malware Scanning

To verify that malware filtering is disabled, run the following cmdlet and confirm that it returns a value of False:

Get-TransportAgent “Malware Agent”

Figure 2.3: Checking Anti-Malware Scanning Status

Bypassing Malware Filtering

To temporarily bypass malware filtering, run the following cmdlet:

Set-MalwareFilteringServer <Server_Name> -BypassFiltering $True

Figure 2.4: Bypassing Anti-Malware Scanning Status

To verify that malware filtering is being bypassed, run the following cmdlet and confirm that it returns a value of True:

Get-MalwareFilteringServer | Select BypassFiltering

Figure 2.5: Checking Anti-Malware Bypassing Status

To restore malware filtering, simply set the -BypassFiltering parameter back to $False:

Set-MalwareFilteringServer -BypassFiltering $False

Engine and Definition Updates

When malware protection is enabled, Exchange automatically checks for engine and definition updates every 30 minutes. You can check when and what version of the engine and definitions is in use by running the Get-EngineUpdateInformation cmdlet:

Figure 2.6: Engine Update Information

If you want to manually force an update check, run the Update-MalwareFilteringServer.ps1 script (basically a wrap around the Start-EngineUpdate cmdlet):

CD $ExScripts

.\Update-MalwareFilteringServer.ps1 <Server_Name>

Figure 2.7: Starting Engine Update

To verify that updates were successfully downloaded, check the event log:

  1. Open Event Viewer;
  2. In Event Viewer, expand the Windows Logs folder, and then click Application;
  3. In the Actions menu, click Filter Current Log;
  4. In the Filter Current Log dialog box, from the Event sources drop-down list, select the FIPFS check box, and then click OK.

If engine updates were downloaded successfully, you will see an Event ID 6033 similar to the following:

MS Filtering Engine Update process performed a successful scan engine update.

Scan Engine: Microsoft

Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate

Last Update time: ‎2013‎-10‎-28T14:18:23.000Z

Engine Version: 1.1.8601.0

Signature Version: 1.131.2169.0

You can configure the update settings using the Set-MalwareFilteringServercmdlet with the –UpdateFrequency parameter. This parameter specifies the frequency interval in minutes to check for malware scanning engine updates. A valid value is an integer between 1 and 38880 (27 days), with the default being 30.

You can also use the -UpdateTimeout parameter to specify the timeout interval in seconds to use when checking for malware scanning engine updates. A valid value for this parameter is an integer between 60 and 300, with the default being 150 seconds (2.5 minutes).

Using the Get/Set-EngineUpdateCommonSettings cmdlet you can also change these and other settings on a global scale:

Figure 2.8: Engine Update Global Information

Rescan E-mails Already Scanned by EOP

Exchange 2013 can be configured to rescan e-mails that have already been scanned by a hosted e-mail filtering service such as EOP. As EOP only scans inbound and outbound e-mails, enabling this feature provides another layer of defense against malware as the on-premises Exchange will scan for internal e-mails. By default, e-mails scanned in the cloud are not resubmitted for malware scanning on-premises.

To rescan e-mails already malware scanned by the hosted filtering service, run the following cmdlet:

Set-MalwareFilteringServer <Server_Name> -ForceRescan $True

Figure 2.9: Forcing E-mail Rescan

To return to the default setting of not rescanning e-mails, simply reset the above parameter to $False:

Set-MalwareFilteringServer <Server_Name> -ForceRescan $False

Exchange on-premises uses the following Xheaders for AVStamp to check if an e-mail has already been scanned by EOP or not:

  • Exchange 2013 on-premise: X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
  • Exchange 2013 in the cloud (Exchange Online/EOP): X-MS-Exchange-Organization-AVStamp-Service: 1.0


In this article we started exploring the new features surrounding anti-malware protection in Exchange 2013. In the next and final article, we will have a look at anti-malware policies and finish with some common questions and answers.

If you would like to read the other parts in this article series please go to: