Exchange 2013 Malware Engine Updates Troubleshooting

As we have introduced Anti-malware filtering by default in Exchange 2013 we have noticed that some Exchange servers fail to update the engines.

We do have a couple of scripts designed to manage Anti-malware filtering, all these scripts are located in the Scripts folder of Exchange 2013 so you have to go the folder by using :

cd $ExScripts

Available scripts

After running any of the above scripts you have to restart "MSExchange Trasport" service by running :

Restart-Service MSExchangeTransport

To manually force an update you can use the .\Update-MalwareFilteringServer.ps1 script

.\Update-MalwareFilteringServer.ps1 <Server_Name>

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:

If the engine updates fail, you will see an Event ID 6027 similar to the following :

How to troubleshoot this issue ?

We will start by making sure there is no Proxy rule so just open your browser and open

This is the page that should be returned

What we will do to solve Event ID 6027 is to create a centralized server for downloading and distributing the malware engines.

After deciding on what server you will store the malware engines please create a local directory structure on the computer on which you want to download the scan engine updates. To do this, follow these steps:
 a. Create a directory. For example, create a directory that is named "ScanEngineUpdates."
 b. Set the NTFS file system and share permissions on the directory so that the exchange servers and "NT AUTHROITY\Network Service" have access to the directory.
Please visit the below KB article to download the Update-Engines.ps1 Powershell script

Execute the Update-Engines.ps1 Powershell script, providing any necessary parameters. The format of the command is as follows:
Update-Engines.ps1 -EngineDirPath <string> -UpdatePathUrl <update url> -Engines <engine names> -Platforms <platform names>
 o EngineDirPath <string> The directory to serve as the root engines directory, created in step 2. This is a required parameter
 o UpdatePathUrl <update url> The update path used to pull the updates from
 o Engines <engine names> The list of names of engines to update
Note: Multiple engine names should be separated by commas, with or without spaces.
Platforms <platform names> The list of names of platforms to update
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\ -UpdatePathUrl -Engines Microsoft -Platforms amd64, x86
Update-Engines.ps1 -EngineDirPath C:\ScanEngineUpdates\ -UpdatePathUrl -Engines Microsoft -Platforms amd64, x86
You can now configure Exchange servers to download updates from the directory created
Open a PowerShell window on the Exchange server where you want to distribute the engine
Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell
Set-EngineUpdateCommonSettings –SecondaryUpdatePath \\server\ScanEngineUpdate\

This will be removed at the next server reboot. To make this change permanent please use :

Set-MalwareFilteringServer -PrimaryUpdatePath \\server\ScanEngineUpdate\

To verify if the Engine Update was successful you can run

Get-EngineUpdateInformation | fl

If the update fails we will see the UpdateStatus : UpdateAttemptFailed and we will also have the Event ID 6027

If the above will not resolve your issue check that "NT AUTHROITY\Network Service" has full access for the folder Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin, in case you have installed Exchange in different drive, you need to add "NT AUTHROITY\Network Service" on the drive itself.

If you have closed the Exchange Powershell you have to add the ForeFront PSSnappin again to have access to Forefront cmdlets.

Add-PSSnapin -Name Microsoft.Forefront.Filtering.Management.PowerShell


Restart Microsoft Filtering Management Service.

After few minutes update will be finished and if you run Get-EngineUpdateInformation again it should show if it was updated.

If the above fail the final way to get this solves it to manually add the files to the FIP-FS folder

Download latest manifest file (xml compressed in cab file) from

Unpack manifest.xml and verify engine number - for today and change the number with red from the link below :

Download and unpack to a separate folder somewhere on disk.

Open C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin (if you installed Exchange with default path)

Do a backup of the existing files first in the above folder and the copy the files unpacked from the cab file to this folder.

Restart Microsoft Filtering Management Service.

After few minutes your first update will be finished and if you run Get-EngineUpdateInformation again it should show you actual data.

Make sure "NT AUTHROITY\Network Service" has full access for the folder Program Files\Microsoft\Exchange\V15\FIP-FS\Data\ in case you have installed exchange in different drive, you need to add "NT AUTHROITY\Network Service" on the drive itself.

For any questions please feel free to contact me.

Cristi Timofte

Comments (6)
  1. Stefan Korn says:

    What kind of permission should I add for NT-AuthorityNetwork Service to the drive itself if I have installed Exchange on a different drive?

    Thanks for your help.

  2. Leonardo says:

    Great article! I am just experiencing a problem that my secondary path disappears everytime the server reeboots or when I execute the Start-EngineUpdate. I need then to reexecute " Set-EngineUpdateCommonSettings –SecondaryUpdatePath \serverScanEngineUpdate"
    to get it back running. Is there a GPO or a configuration somewhere that overwrites this input, making me have to do it when my server restarts?

  3. Anonymous says:

    I had an interesting case where a HTTP proxy server was preventing Exchange 2013 from updating the malware

  4. Jon says:

    I get "The term ‘Get-MalwareFilteringServer’ is not recognized as the name of a cmdlet, blah blah error. I have loaded the PSSnapins for exchange. the commonsettings command worked, but not the malware one. what gives?

Comments are closed.

Skip to main content