IMF Archive Manager for Exchange 2003

Using blacklists for spam protection in Exchange 2003 cuts down a lot of spam for my company. However, we decided to enable IMF to do even better. However, it is imperative these caught messages get monitored for false positives. We’re small enough that monitoring the IMF archive is reasonable, but it wasn’t immediately apparent how to do this.
Luckily I found this tool: http://imfam.codeplex.com/  (IMF Archive Manager)

Setup

To begin, you want to make sure the your IMF settings are set to Archive:

IMF archive settings

By default this archive location is:

%ExchangeInstallPath%\Exchsrvr\Mailroot\vsi 1\UceArchive

However, you can change that location by modifying this registry value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\ContentFilter\ArchiveDir

Once you’ve found or set your archive location, open IMF Manager on your client computer, and click Settings > Archive Folder:

IMF Settings folder

Set this to your archive location, and you should see it populated with the IMF messages. This gives you a safe way to view the spam and identify false positives.

Dealing with False Positives

Identifying false positives isn’t very helpful if you can’t do anything with them. What I’ve done to solve this problem is created a Windows share of the IMF Archive folder, and then using IMF Archive Manager, delete all the spam leaving only false positives. I then open the shared folder, and copy the .eml files out:

IMF False Positives

Once you have an .eml file, you may need to re-configure Outlook 2003 or Outlook 2007 to natively open them.

Office 2003:

http://support.microsoft.com/kb/967346

Office 2007

http://support.microsoft.com/kb/956693

Office 2010 appears to open these files properly.

Recover Hard Deleted Items in Exchange 2003

This information applies to at least Exchange 2003; I can’t verify any newer versions.

Sometimes an item in Exchange has been perminently deleted, and doesn’t show up in “recover deleted items”.

You can find these items through the OWA interface, if you have it enabled.

Paste this into IE, filling in the server name and user alias.

https://server_name/exchange/user_name/inbox/?cmd=showdeleted

Recover Deleted Items

This will show different results than what you would typically see using “Recover Deleted Items” from within Outlook.

Windows 7 Jumplist empty or slow to respond

Windows 7 JumplistAnother post that is slightly related to our Symantec Endpoint Protection (SEP) testing; on our Windows 7 machines, we’ve found that with SEP installed and enabled, the jumplists for all programs are drastically slower to appear.

As soon as the antivirus auto-protect is disabled, performance returns to immediate. This slowdown was most notable on Windows Explorer jumplists, however it also affected Microsoft Office and other programs.

I eventually found a solution, related to an obscure location for the jump list cache.

Sign in as the user having the problem, and paste this into an address bar:

%AppData%\Microsoft\Windows\Recent\AutomaticDestinations

This folder contains a cache of the Jumplist entries. To fix the issue for Windows Explorer, find the entry that begins with:

1b4dd67f29cb1962

And delete it.

Then navigate here:

%AppData%\Microsoft\Windows\Recent\CustomDestinations

And do the same thing; delete the file that starts with:

1b4dd67f29cb1962

After this you will need to re-pin any items you previously had pinned for that application.

This will only resolve the problem for Windows Explorer; you may have to do some trial and error to find the appropriate cache to delete for any other programs.

Symantec Endpoint Protection & IE9

We’re currently testing the latest release of Symantec Endpoint Protection (SEP) 11 MR6a, to replace the Symantec Corporate Antivirus 10.1 that we’re currently using. During this testing, we’ve found a bug that is only mentioned a few other places online.Symantec Endpoint Protection 11

If you have SEP11 installed on a computer with the Internet Explorer 9 beta, it will not receive definition updates from the management server. I haven’t heard of a solution to this problem yet.

The work-around that we’ve done is to create a new Location within the management server whose membership filter the computer name or IP of the IE9 beta participants. Then we assign a new LiveUpdate policy to that location, which forces those computers to use LiveUpdate for definitions, instead of the management server.

Hopefully this issue is fixed before IE9 hits release.