When this happens, these users will not appear to Forefront and it will not be possible to scan their mailboxes using either the Manual or Scheduled scans, (Real-time scanning will still be performed).

To work around this issue, we must use the Exchange PowerShell, together with the Forefront PowerShell commandlets, and then run the Manual or Scheduled scan also using PowerShell.

To do this you should first open an instance of the Exchange PowerShell on the server where Forefront is installed. Then we need to add the Forefront PowerShell commandlets to this PowerShell instance using the command:- “Add-PsSnapin FSSPSSnapin”.

Now that we have the Forefront PowerShell commandlets within our PowerShell instance, we next need to make all of the other domains visible. To do this, we use the Exchange PowerShell command:- “Set-ADServerSettings –ViewEntireForest $true”.

At this point, user from different domains that are located on this server, should be visible.

Now we should be able to use this PowerShell instance to configure the scheduled and/or manual scans within Forefront. The PowerShell commandlets that are probably the most interesting are:-

Set-FseScheduledScan  -  Sets the configuration of the scheduled scan.

Get-FseScheduledScan  -  Retrieves the configuration of the scheduled scan.

Start-FseScheduledScan  -  Starts a scan of the mailbox store immediately.

Stop-FseScheduledScan  -  Halts a scan of the mailbox store that is currently running.

 

Set-FseOnDemandScan  -  Sets the configuration of the on-demand scan.

Get-FseOnDemandScan  -  Retrieves the configuration settings of the on-demand scan.

Start-FseOnDemandScan  -  Starts the on-demand scan.

Stop-FseOnDemandScan  -  Stops the on-demand scan.

Suspend-FseOnDemandScan  -  Pauses the currently running on-demand scan.

Resume-FseOnDemandScan  -  Resumes a paused on-demand scan.

You can find further details of these and other Forefront Protection for Exchange related commandlets at the following location:-

Using Windows PowerShell 

Or by running one of the following PowerShell commands:-

Get-Help commandlet 

Get-Help commandlet –examples

Get-Help commandlet –detailed

Get-Help commandlet –full

Any comments and/or constructive feedback are most welcome.

This error is normally caused because one of the Web Sites/Application pools, is trying to load the ISAPI DLL – “FSSPUsernameFilter.dll”, but is unable to do so successfully.

By default, when Forefront is installed on a SharePoint server, the Forefront ISAPI Filter, is installed in the root level of IIS. As such, all web sites created below this, inherit this ISAPI filter.

The ISAPI filter can be seen in the IIS manager:-

Normally the reason that this ISAPI Filter cannot load correctly is due to NTFS permissions. To troubleshoot NTFS permissions, my personal “tool of choice” is process monitor from system internals, (available here).

Using Process Monitor to capture at least one instance of the error being logged to the Application Event log, I will create a new filter, (CTRL-L), for all entries which have a path which contains the string, “FSSPUsernameFilter.dll”:-

In the filtered log, we will probably see something similar to the following:-

Double clicking one of these entries, we can see exactly which user account is requesting access and what access it is requesting:-

(If the user account does not appear as a “normal” user account, but rather as an IIS user account or Application Pool Identity, (IIS APPPOOL\DefaultAppPool), as in the example above, please see Application Pool Identities)

Once we have the username for the account that is failing, we then need to ensure that this has permission to access the FSSPUsernameFilter.dll file, located by default in the “C:\Program Files\Microsoft Forefront Protection for SharePoint” folder. This is done in the normal way to set NTFS permissions. This account should be configured with “Read, Read & Execute” permission to this file.

For further details regarding permissions within Windows, please see:- Managing Permissions

Finally, we need the w3wp.exe processes to be restarted, in order for them to pick up . The easiest way to do this is to open a command prompt with elevated privileges and run the command “iisreset”. Please note, when the IISReset command is run, the w3wp.exe processes will be stopped and will then restart again with the next request made to the website. During this time, your webpages will temporarily be unavailable, but normally this runs fairly quickly.

Any comments and/or constructive feedback are most welcome.

Basically this issue is caused because, by design, if an email is pass to an Exchange server via an authenticated connection, Exchange will assume that this is a “safe” email (as it comes from a trusted source) and will bypass the Anti-Spam scanning.

To address this you must ensure that all connections coming from machines which could be passing Spam emails to this server, are forced to use “Anonymous” authentication and will then be subjected to Anti-Spam scanning.

Ok, so how do we do this.

In this example I will assume that in front of the Server performing Anti-Spam scanning, we have 2 edge servers, routers or SMTP relay servers, which have the IP addresses:- 10.0.0.51 & 10.0.0.52.

1) First we need to edit the default receive connector to exclude these 2 IP addresses

2) Next we need to create the new connector, through which all possible Spam emails will flow

3) Next we need to set this to accept only anonymous connections

4) Then finally we need to restart the Exchange transport service for the changes to be applied.

To test that this new connector is the connector that is being connected to from your front end/SMTP relay/Edge server, you should open the new connector in Exchange and set the “Protocol logging level” to Verbose under the “General” tab and this should then start to log entries to the Exchange protocol logs, (by default this is located in “C:\Program Files\Microsoft\Exchange Server\v14\TransportRoles\Logs\ProtocolLog\SmtpReceive”).

There is also a “dirty” (and unsupported method I would assume) to test this, which is to temporarily change the FQDN in the receive connector (General Tab), and then connect to the server from your front end/SMTP relay/Edge server on port 25 (putty is a good tool to use for this if you would prefer not to install the telnet client).  This should then display the FQDN name configured in the connector.

Additionally, I would recommend that you review Van’s great blog describing another very common issue we see relating to Spam detection:-

https://blogs.technet.com/b/msfss_stuff/archive/2010/04/23/forefront-protection-for-exchange-blocks-outlook-block-sender-functionality-and-exchange-imf.aspx

Any comments and/or constructive feedback are most welcome.

First you need to log into the Admin centre and navigate to the Message Trace page (Tools –>Message Trace).

Here you must enter a sender and a recipient address. One of these addresses can be just a domain but not both.

(in the screenshots above, the domain only address is entered in the form “@domain.com” but this can be entered as well in the form “domain.com”).

Also you should specify the “Start Date” and “End Date” as accurately as possible. The maximum date range that you can search for in this tool is limited to 30 days.

If you know the Message ID, Please enter this as then it will just display the exact message that you are interested in. (This can be seen in the header of the email, in Outlook 2010 you can see this by opening the email and navigating to “File Menu->Info->Properties” and should be present in the “Internet Headers” section of the window that appears – often it is easiest to copy and paste the “Internet Headers” information to a text file editor such as notepad).

When you have found the “interesting” email listed at the bottom of the window, click “details” and you will then open a new window which should provide you with a more detailed view of this particular email.

This can occur for a large variety of reasons, too many to discuss in full within the confines of a single blog article, so I would like to just cover the two most common causes.

The most common cause of this behaviour is that the file was created using third party software and the files do not follow fully the RFC/File format standard.

In this case, Office will open the file and allow you to access it fine, but as a security product, Forefront and Antigen need to be strict in this respect.

This is fairly easy to test, you simply need to open the file using Microsoft Office and then click “Save As” and save it with a new filename. This will cause the file format to be recreated. You then send or upload/download the new “resaved” copy of the Office document and confirm if the behaviour is still occurring.

The second most common cause of this behaviour is due to the file format not being correctly interpreted by Antigen/Forefront. This has usually already been addressed in a hotfix, roll up or service pack, as such you should ensure that your product is at the latest service pack, roll up level.

Details of the latest Service Packs and Roll Ups for Antigen/Forefront can be found at:-

Updates for Microsoft Forefront and Related Technologies

If you find that, after resaving the Office file it is still being blocked as Corrupted Compressed and you are running the latest service pack and roll up, then the next step is to raise a support case with Microsoft.

I hope this helps. Any comments are gratefully received.

The good news is that a command line tool needed to do this is included within Forefront Protection installation.

To use this tool to format the Programlog.etl file, open a command prompt and change folder to the Forefront Program files folder. By default this should be, “C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server.

Next run the following command line:-

fsctraceformat.exe .\data\programlog.etl –p .\data\tmf –o .\data\programlog.txt

This should then create a text file, within the Forefront “Data” folder, called Programlog.txt containing the formatted log entries

If you find that when the tool finishes, it appears to have been partly successful but has reported numerous “Unknowns” or that within the formatted log file, there are several entries in the form:-

Unknown( 18): GUID=2435de0f-d5ac-dfd1-77cdfed6a7d0 (No Format Information Found)

This is probably due to the FPSMC agent TMF files not being present in the TMF folder we are using.

By default, these TMF files can be found in “C:\Program Files (x86)\Forefront Protection Server Management\DeploymentAgent\TMF\TraceFormat.cab”. These files should be extracted from the CAB file and copied to the TMF folder within the Forefront Protection for Exchange TMF folder, “C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server\Data\TMF”.

I hope this helps. Again any constructive feedback is very welcome

The situation that a customer was facing was that they had mailboxes for users from multiple domains hosted on their mailbox server.

Forefront, by default, can only see the mailboxes for users from the domain where the machine account of the server resides, meaning we were unable to scan, using the manual or scheduled scan, any mailboxes for any user from a different domain, (Real Time and Transport scanning worked fine).

To address this, we imported the Forefront PowerShell commandlets into an instance of the Exchange PowerShell and enabled full domain visibility for this PowerShell command prompt window. After this we could scan (but not see using the Forefront PowerShell commands), mailboxes for the users from different domains.

The PowerShell commands that we used to do this were:-

Add-PsSnapin FSSPSSnapin

Set-ADServerSettings –ViewEntireForest $true

If anyone else has this setup and tests this, I would be very interested to hear if this works for you (we only tested this using the manual scan) 

"The SharePoint Service is running but the Forefront VSAPI Library is not registered"

Normally you would like to know why this is occurring and how to address this error.

Before I begin to provide possible causes for the error message, I would like to give a quick overview of what is the function that this component performs.

The VSAPI (Virus Scanning API) is a way for Microsoft products to interface with Anti-Virus products. This takes the form of a DLL, in Forefronts’ case this is “SPVsapi.dll”, and is referenced in the Sharepoint registry via a Class ID.

This Class ID is registered with Windows and refers to our DLL. This can then be called by any process within Windows.

SharePoint will then call this DLL and load it into all w3wp.exe processes that Sharepoint controls, all SharePoint application pools and all apps that use the SharePoint Object Model (OM). This is loaded when the SharePoint object/process is loaded and receives its first call.

We can see the Forefront VSAPI DLL loaded within the w3wp.exe in the following image:-

This can also occur if any of the requirements above are not 100% correct; i.e. the CLSID is incorrect or missing, the DLL is not accessible, the entry within the SharePoint registry is not correctly configured, etc.

The Forefront Controller process runs as a DCOM server:-

A DCOM server will automatically start if any attempt is made to access it. This can happen for various reasons, but normally these are if the Forefront console is started or a monitoring package, such as SCOM, makes a call to this DCOM server.

The entries within the Sharepoint registry and all dependencies between SharePoint and Forefront services and processes are removed when “FSCUtility /disable” is run, and recreated when “FSCUtility /enable” is run. As such, when we are faced with situations where we believe that something within this chain is incorrect or the chain is broken for some reason, we request that the customer runs “FSCUtility /disable” followed by “FSCUtility /enable” as this will force all the chain to be recreated.

I hope you find this useful. Any comment are greatfully received.