A question which appeared on the forums the other day was worthy, I think, of further investigation.  It's one of those questions that you think should be 'obvious' or 'easy' but of course it's not that straight forward.

The question is:

When using FSAUTILITY to bulk recall files how can progress be tracked?

We know that when the FSA Archiving Task is running the report file that it generates usually reports 0 Kb for quite some time, but when you open it, it does contain data… so you can see 'progress' that way.

People who have used Enterprise Vault for some time know that there are lots of differences between the way that FSA and Exchange Mailbox archiving operate.  Fundamentally FSA does not use...

Adding an additional Client Access Server (CAS) in your Exchange 2007 or Exchange 2010 environment is something that you probably need to do.  The question is what impact does this have on the Enterprise Vault environment?  Sometimes it is quite some time after the initial setup of the environment and how the EV + OWA side of things is long forgotten.  The steps to add an additional CAS are quite simple:

1. Edit the IP restrictions on the EVAnon virtual directory

- Add in the IP address of your new CAS server.

2. Edit the ExchangeServers.txt file

- Add in the IP address of your new CAS server.

3. Install the EV OWA Extensions.

- To add the EV functionality.

And that is it!  It's really that...

In order to see if an issue I currently have is still present with Enterprise Vault 10.0.3 I decided to take the plunge and upgrade a copy of one of my virtual environments to Enterprise Vault 10.0.3.  This is what happend:

First of all I got a nice new pop-up after running the setup program to update my server:

I think that's quite a handy reminder for people doing this on a production environment.

The next thing was a little bit unexpected..  in the 'mini deployment scanner' run I saw a warning against my version of Outlook.

I had a quick review of the Compatibility Charts as it recommended, and the issue is around Outlook...

Have you ever wondered what the LastPSTSearch registry entry was on a client / Outlook workstation with Enterprise Vault in the environment? Well, for quite some time when I was working with PST migrations I would stumble across issues where test PST files that I had put in place on a client machine weren't being picked up for migration.  It seemed sometimes that they were, and sometimes that they weren't.

In the end much of this was down to the LastPSTSearch registry key....

The registry key is related to Client Driven PST Migration, and indicates the date when the last scan for PSTs was performed.  If the date is recent, then no new scan will take place.  That's why when I was first looking at these sorts of migration issues it would appear to work sometimes, but not others.

The registry key is located here:

HKEY_CURRENT_USER...