File system volume has no Archive points associated. Eventid 40976

If the checkpoint file is missing the task should try loading a backup (.bk) of the file (which may be in the same folder), or start from the volume root and trawl, so I guess this should continue as normal, and at the end of the run it should create a .xml file.

Might be an idea, if it's not too big, to upload the trace (zip it first)

Hello GPkGuy,

The checkpoint file .bak it's missing too. I have been looking in the path C:\Program Files (x86)\Enterprise Vault\FSATaskCheckPoint and no check point file it's created.

I attach the tracelog.log file.

Tthanks for your reply

I think there's something wrong because if I execute archivepoints read \\3otw-lab-04\datos I get:

C:\Program Files (x86)\Enterprise Vault>archivepoints read \\3otw-lab-04\datos

ArchivePoint for folder \\3otw-lab-04\datos:

        Combined Name: datos
        Prefix:
        Name:
        Owner:
        Description:
        ArchiveVEID: 11064CEE889B80D45B7BA1AF7358DB03F11100003OTW-FSA-01
        Root Folder Created Date: 01/12/2011 16:12:13
        Delete Expired Items: 0
        Indexing Level: FULL
        Index Disabled: False
        Index Snippet Length: 128
        Index Attachment Snippet: False

But If I try recreating the AP's using the FSAUtility I get:

C:\Program Files (x86)\Enterprise Vault>fsautility -a -s \\3otw-lab-04\datos -r

FSA Data Mover Utility.
Symantec Enterprise Vault.
Copyright (c) 2010. Symantec Corporation.

Recreating ArchivePoints for \\3otw-lab-04.wds.local\datos
Error: Invalid fileServer \\3otw-lab-04.wds.local

Thank you.

Hello Percy Vere, I think the problem must be in anyway creating AP's with the console.

In command prompt I have delete the archive point: archivepoints delete \\3otw-lab-04.wds.local\datos and I have created it again: archivepoints create \\3otw-lab-04.wds.local\datos nosubfolder

And now when I execute a run now I can see the files that can be archived.

Than you very much for your help.

Best regards.
 
 

I presumed they had gone down this path when they said about using the TN above.

Hi Bluefish

 I think I might be stepping a bit late into this thread.

However, I wanted to alert you to some side effects resulting from your actions.

First let me explain that the initial recommendation made by GPKGuy was valid because in many circumstances this alert has been reported as a result of inconsistencies with the checkpointing feature.

In such cases, sometimes is helpful to delete the existing checkpoint files so that the Archiving run starts processing from scratch.

Another reason why this alert can be reported is for Archiving Tasks which have several targets to process and the full run cannot be completed in one execution. For situations where the Archiving Task will have to continue the processing on the next schedule run, the volume targets that have already been processed in the previous run will usually report this alert in the report log.

Now, the situation seems to have become more complicated as you seem to have used ArchivePoints.exe to recreate the ArchivePoint for the same path.

This is a method which should not be used as ArchivePoints.exe will always create a new ArchivePoint therefore resulting in a new ArchiveID (ArchiveVEID) and a duplicate Archive will exist.

 I would suggest you to check the ID of the new Archive and compare against the ID of the old Archive as you reported earlier in the thread.

 Old ArchiveVEID: 11064CEE889B80D45B7BA1AF7358DB03F11100003OTW-FSA-01

Please note that Percy Vere has suggested you to re-create the ArchivePoint with FSAUtility. This is the correct way of 're-creating' ArchivePoints where necessary.

FSAUtility will check the database for existing records for that ArchivePoint and will recreate the EVArchivePoint.xml with the same ID value for the existing ArchivePoint.