Event ID 40966 - FSA Archiving

[be-nugget]

Hey, we have been getting the following alerts for some time:

A program fault has raised an exception.

Exception: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)

Diagnostic:

Type: System.IO.FileNotFoundException

These seem to only occur when FSA archiving is running during the evening.  From what I have gather its happening because folder paths that previous existed when FSA was setup as targets now no longer exist.  This to me sounds a little weird as you are always going to have folder movement on a file server that you potentially might be using as archive targets.

Anyway, I have read about using DTRACE to find the location it is complaining about and add these back in, two things, there are hundreds of these and not really feasible secondly, this is going to keep happening when users move\delete folders that are within targetted FSA volumes.

The last thing I read was to change the SynchroniseFSASharePermissions key from 0 to 1 but I wasnt honestly sure about what this actually does and how it would fix the problem of not moaning about folders it cant see anymore? could someone offer any help?

Using EV 9.0.3

[TonySterling]

So SynchroniseFSASharePermissions changes how EV synchronizes permissions from the file server.

By default, FSA will synchronize the permissions at the share level. If the folder structure being archived contains permissions which differ to the share, then it is recommend to synchronize the NTFS permissions.  If this key is set to 0 it synchronizes the NTFS permissions.  Setting to 1 it synchonizes the Share permissions.

Do you have this key set?

[be-nugget]

Hi Tony,  currently the key is set to 0.  My confusion though is that the event being generated is to do with paths that previous existed under one of the targetted volumes is no longer there (well quite a few now actually). Hence the alert. So not sure how a permission key from NTFS to share is going to help me if you get what I mean?

[TonySterling]

When the key is set to 0 EV looks for the folder to synch the permission, hence the error as it can't find it.  With the key set to 1 EV will synch the share permissions and not worry about the folders.  Does that explain it?

[be-nugget]

Hi Tony, yes it does make more sense. So, for the purpose of switching this to '1', how does this actually affect FSA archiving, what is the purpose of the two different options, for example in what scenario would you need to use one over the other?

[TonySterling]

So if the folders being archived different permissions than the share you would use the registry key to synchronize the NTFS permissions.

If your folders all have the same permissions as the share you can set it back to 1 and not have any issues with users accessing the file archives.

[be-nugget]

Hi Tony, what options do I have to resolve this then if permissions do differ and I need to keep NTFS synchronisation permissions in place?

[TonySterling]

So as you saw there are three workarounds.

1. Using dtrace during the synchronization will provide the details of which path is causing this issue - once identified the path can be re-added to the target file system.

You have already stated there are many of these so adding them back would be problematic.

2. The volume target in the Vault Administration Console can be deleted and then re-created.

Seems like this would be the work around for you. 

3. Switch the SynchroniseFSASharePermissions registry key back to 1 (see Related Articles section).

If your Folder permissions are different then your share you really can't use this option and are going to have to go with option 2.

[be-nugget]

Tony, what does option 2 actually do when you remove the target volume and re-add it, does it destroy any relationships and archived data it previous knew about in the vault when you remove it?  Just need to understand the implications of making that sort of change.

[TonySterling · Accepted solution]

This technote details it for you

Deleting a target volume from FSA

Article: HOWTO49512

|

Created: 2011-04-08

|

Updated: 2011-12-19

|

Article URL http://www.symantec.com/docs/HOWTO49512

Import for you to note:

Note that if you delete a target volume in the Administration Console, Enterprise Vault does not delete any associated archive points automatically.

If you do not delete the archive points and then you re-add the volume for archiving, Enterprise Vault uses the existing archive points, which remain associated with the original vault store.