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

[Rob_Wilcox1]

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 MSMQ as the Exchange Mailbox Archiving process does.  Items are collected for processing by a number of folder walker threads, this queue of files is operated on by a number of other threads.  Periodically the 'progress' is written out to the checkpoint XML file in case the scheduled window ends, or the task is stopped.  It means that when the task resumes it can quickly get to where it left off and carry on.  It also means that when the scheduled window ends the processing actually ends, that again is a little different to the Exchange Mailbox Archiving side of Enterprise Vault.

To answer the question about FSAUTIL needs some reproduction work.  The situation is reproducible I think by generating 15000 sample files, archiving them, and then trying the bulk recall from the command line.  

The command line I'm going to use is as follows:

FSAUTILITY -t -s \\fs01\data\hector -f -l 0

The interesting parts of the command line are:

-f … to overwrite the files which are currently on disk.  This can lead to somewhat unexpected results, but for my test where all the items on the source are placeholders, it'll be fine.  The unexpected results can be observed by overwriting an archived file which was previously recalled and edited, those edits will be lost.

-l 0 … by default FSAUtility only reports failures in the XML file.  Switching this to -l 0 will report successes and failures.

To generate the files I used my sample bulk creator script which is available on this link.  Quite surprisingly that didn't take too long to do.  The script ran for 12 minutes.  The next step was archiving them all.  And finally we can now get on with the bulk recall, and figuring out when the data is written to the XML file.

In looking at the XML file (which you kind of have to open in Notepad) it can be seen that the file is being written to whilst FSAUTILITY is building the list of files to restore. So whilst FSAUTILITY is showing 'Number of files queued for restore:' and the number next to that starts to rise.. those file entries are being written to the XML file.  They are showing information like this:

<?xml version="1.0"?>

<?xml-stylesheet type='text/xsl' href='C:\Program Files (x86)\Enterprise Vault\FSAUtilityLog.xsl'?>

<FSAUtilityLog>

  <Header>

    <Operation>Restore files</Operation>

    <DateTime>10/02/2013 14:19:06</DateTime>

    <SourcePath>\\fs01.ev.local\data\hector</SourcePath>

  </Header>

  <ItemList>

    <Item>

      <Item>.\test_1.out</Item>

      <ErrorCode>Restore operation started</ErrorCode>

    </Item>

    <Item>

      <Item>.\test_10.out</Item>

      <ErrorCode>Restore operation started</ErrorCode>

    </Item>

    <Item>

      <Item>.\test_100.out</Item>

      <ErrorCode>Restore operation started</ErrorCode>

    </Item>

The entry in the file indicates that the restore operation has started for each of the items, and the file is gradually growing.

After a few minutes I am seeing on the file system that some of the files are now being replaced from the version in the archive.  However, the XML file is not being updated (yet) to reflect that, and the number of items queued is slowly rising still.  Even after a few hours though the status of the items in the XML file is still simply 'Restore operation started'.

Summary

• The XML does get written to as the items are queued for processing.
• There is _no_ easy way to determine whether the files have been recalled or not, other than simply doing a DIR command.

It is a shame that this hasn't been thought of 'more' and had any development work done around it.  Moving placeholders or restoring items is something that people have to do from time to time, and to be honest right now you're left a little bit in the dark when it comes to tracking progress.