We have seen the following issue a few times in the last two weeks

Issue:

After installing Antigen or recycling the server where we are installed with, Exchange fails to start up. Error is dependency failed to start.

Trying to start Antigen Monitor results in a “%t is not a valid win32 application” message.

Cause:

Our paths are not wrapped in quotes in the registry.

Antigen is installed into a path with spaces in it (Program files)

A file matching the first word in the install path is in the root directory.

Example:

0 byte file called program in the root of c:

Analysis:

Without wrapping you paths in quotes you run into windows guessing what you mean when you pass it a command

For example

C:\program files\Microsoft antigen\exchange\antigenservice.exe

In a normal system would launch antienservice.

In a system with a file called program in the c:\ folder it would launch

C:\program

with the argument files\Microsoft antigen\exchange\antigenservice.exe

Solution:

Remove the file that matches the word before the first space (In my example the 0 byte program file)

You can also re-install in a path with no spaces (c:\antigen)

If you remove the file in the root of the drive and it comes back you can use process explorer to trace the creation of the file and then find out what program is dropping files in your root directory.

We should also be implementing a fix for this in the next hotfix rollup.

I had a good question today from one of my customers

What is the background scan.

here is my response.

You should never use a background scan.

Ever…

Background scanning was a clever idea back in the day when VSAPI 1.0 was released.

You have a background scan running in VSAPI that goes through every file in your database.

Then when that file is accessed, if it has been scanned with the latest definitions it skips the scan on access and the file is allowed to pass.

Problem is.. back in 1999-2000 when that came out, virus definitions updated on average once a week.

Today you can have engines that update every 1-4 hours. And with 5 engines.. you get the point.

The scan never finishes and basically acts as a resource pit.

We support it, because VSAPI still supports it.

The following error is logged every 60 minutes on Forefront Server for Exchange SP2

This is a informational warning but the way it is worded might cause some concern.

Log Name:      Application

Source:        FSEAgent

Date:          8/28/2008 2:13:21 AM

Event ID:      8048

Task Category: (8)

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      XXXXXXXXXXXXXX

Description:

1 messages have been archived and purged due to an error while scanning. Please ensure that mail is not queuing.

This error stems from mail being stuck in the Undeliverable folder of our archive folder.

The default path is c:\Program files (x86)\Microsoft Forefront for Exchange\Archive\Undeliverable\

There should be a file stuck in that folder or under a subfolder.

Removing this message will stop the error.

Missed a week.

This is for the following error

Event Type:        Error

Event Source:    GetEngineFiles

Event Category:                Engine Error

Event ID:              6012

Date:                     #/##/####

Time:                     #:##:## ##

User:                     N/A

Computer:          Testlab01

Description:

Microsoft Forefront Server Security encountered an error while performing a scan engine update.

   Scan Engine: Microsoft

   Error Code: 0x80070102

   Description: Unable to acquire the scan engine update mutex within the    designated timeout period.

This is a timeout and there is a KB (http://support.microsoft.com/kb/939411)  that discusses increasing the download scan timeout but it does not take into account the other issues you will see with longer download times. Our mutex timeout is hardcoded at 3 minutes.

If you have increased your InternetDownloadtimeout to match the longest download times you see in your programlog you need to take into consideration that you can run into a situation where you have scan engine updates timing out because we timeout waiting for the current download.

For example

if the following engines are set to download at these times

Ahlab at 07 min after the hour Repeat every 1 hours

Kaspersky at 09 min after the hour Repeat every 1 hours

Norman at 34 min after the hour Repeat every 1 hours

Microsoft at 39 min after the hour Repeat every 1 hours

Vbuster at 48 min after the hour Repeat every 1 hours

Sophos at 44 min after the hour Repeat every 1 hours

CAVet at 49 min after the hour Repeat every 1 hours

Command at 54 min after the hour Repeat every 1 hours

And the engines take 15-25 minutes to download

This is never going to work correctly.

If it takes 15-30 minutes for you to download an engine you need to make sure that no engine downloads in that timeframe.

Here is a suggestion (1800 minutes for the download setting)

8:00 AM Ahnlab update Repeat every 4 hours

8:32 AM Kaspersky update Repeat every 4 hours

9:04 AM Norman Update Repeat every 4 hours

9:36 AM Microsoft Update Repeat every 4 hours

10:08 AM VBuster Update Repeat every 4 hours

10:40 AM Sophos Update Repeat every 4 hours

11:12 AM CaVet Update Repeat every 4 hours

11:44 AM Command update Repeat every 4 hours

This would ensure that you never have two engines fighting for the download at the same time. If your downloads are faster you can repeat the update faster.

Let me know if this helps you out.