We are seeing cases where the Microsoft scan engine is failing to update in Forefront Protection for Exchange with the following errors.

6019 GetEngineFiles An error occurred while testing the scan engine.

6012 GetEngineFiles An error occurred while loading the scan engine. Scan Engine: Microsoft. Error Code: 0x80004005.

This only seems to be effecting FPE and not other products that the Microsoft engine is included with.

We are working to resolve this issue and it should be resolved automatically once the cause is found. I will update this post if there is any change to how the fix will be delivered.

The only Impact is that the engine fails to update. All other engines are updating correctly and this should not effect mail flow and the other engines should provide coverage for new viruses.

We are in the process of adding this information to our setup documents.

-When implementing FOPE or O365/Live@EDU and you have mail coming to your on premise servers, you need to turn off any SPF checking at your mail server/firewall. The connecting server will always be one of the Forefront Online servers and any domains with SPF configured hard fail will end up getting deleted. Forefront Online has its own spf check so you are still protected.

One common issue with FOPE (this also happens in FSS/Antigen) is the 0 day Virus’s that pretend to be a legitimate mail from other senders.

These tend to be small emails asking you to open the file in a zip attached to the email. The file will look like a pdf but its really an executable named “delivery.pdf                    .exe”

These exe files are not caught by any engine right away so some customers see them come through.

There are multiple ways you can block these messages (SPF, policy rules) But I suggest the following.

My first question is always “Do you have any reason to allow executable files via email?” I have yet found a customer that says they need exe’s in emails.  If your email policy allows blocking these message types then I suggest you set up two rules to lower your chances of getting any viruses.

Inbound reject rule (deletes any inbound mail with a compressed file that contains executable attachments)

The 2nd rule is to block files not in compressed files that fit he header information that matches an executable type.

To verify this is due to a password issue you can check the event logs for

Event ID 10004, Distributed COM

DCOM got error “1326” and was unable to logon <account name> in order to run the server:

{9738A91E-222B-4F3F-8962-6B01144D6ACB}

If that’s there you need to go into Com+ applications under component Services.

Get the properties of the MFSMC.Services object and change the password on the Identity page.

That should resolve the error.

The most common scenario is that the bypass is enabled for anonymous connections.

This is simple to fix with some PowerShell commands to remove the permissions from the connectors.

In exchange PowerShell.

Get-ReceiveConnector

Take the names you get and run
Get-ReceiveConnector " Receive_Connector_name" | Get-ADPermission -User "NT Authority\Anonymous Logon"|fl

You are looking for this

You can then remove the right for bypass by running the following on any connector with the bypass right
Get-ReceiveConnector " Receive_Connector_name" | Remove-ADPermission -User "NT Authority\Anonymous Logon" -ExtendedRight ms-exch-bypass-anti-spam

Checking again with Get-ReceiveConnector " Receive_Connector_name" | Get-ADPermission -User "NT Authority\Anonymous Logon"|fl shows that bypass has been removed from the rights for anonymous.

You can then do the same thing for each connector and recycle transport to make the changes take effect.

Last night we pushed out an update that resolves this issue. Updating your engines should resolve this issue and you can go back to your previous configuration.

This is being looked at but for now it is recommended that you set Cloudmark to update only every 24 hours to avoid lowering your detection rate as the microupdate folder get deleted with each update.

This issue is due to how Antigen processes updates and is not due to the Cloudmark engine itself.

We believe this will be resolved with a package update and no hotfix will be needed.

If you are having issues with timeouts after updating your Cloudmark engine between Friday and Saturday afternoon this post should help you out.

On Friday night we released a Cloudmark engine that had an issue being validated by scan engine test.

This results in a rollback update loop that can cause timeouts and mail flow issues on Antigen 9.x servers.

Forefront Protection for Exchange is not effected by this update.

We rolled the engine back this weekend so no new issues should occur,

if you happen to still have the bad engine on your server you will need to delete the Cloudmark engine folder manually and re-download the re-packaged update.

By default the engine folder is located at c:\Program files\Microsoft Antigen for Exchange\engines\x86\Cloudmark

If you are on a cluster the folder would be <clusterdrive>:\AntigenCluster\Engines\x86\Cloudmark

The new update should then download and resolve your issue.

Hope that helps.

As of last week, customers still running Kaspersky5 started getting errors during attempted updates.

This is normally due to one or more files being missing in the following directories.

%databasepath%\Engines\localenginemapping.cab

%databasepath\Engines\Metadata\universalmanifest.cab

Database path is your install path \ Data on a standalone server

or

<drive>:\Antigencluster\Data on a cluster server.

You should have copies of These files in your Antigen install files directory.

If you do not please open a free case to get copies of these files to get Kaspersky up to date.

1. Spam filtering not working for User X

This one was due to a setting in content filtering.

There is a setting called AntispamBypassEnabled  for each user.

In forefront the agent log will show a content bypass enabled, skipping for every mail to that user.

You can find and fix this setting by doing the following…

 

[PS] C:>get-mailbox USERMAILBOXNAME | fl *spam*,*

SCL AntispamBypassEnabled : False

SCLDeleteThreshold :

SCLDeleteEnabled :

SCLRejectThreshold :

SCLRejectEnabled :

SCLQuarantineThreshold :

SCLQuarantineEnabled :

SCLJunkThreshold :

SCLJunkEnabled :

The above settings will bypass organization level settings.

In this case, the user was set to true for bypass. So nothing got deleted or rejected or put in junk.

2. The next issue was a customer that had everything up and running but no scanning on real-time.

There is a per-database setting for VSAPI. You can find the keys in the following registry locations.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\EXCHANGE-SERVERNAME\DATABASENAME-GUID-OF-YOUR-DATABASE]

"VirusScanEnabled"=dword:00000000

"VirusScanProactiveScanning"=dword:00000000

0 = no scanning

1= scanning