File System Archive retrieval and Shadow Copy

The item is definitely in the Archive still right?
I mean do you have anything like Delete on Delete where you delete the placeholder, it deletes the archived tiem? so if you went to AE  or Search, can you see the item and open it?
 

The errors seems to coming due to shadow copy on but pass throw recall is enabled (http://www.symantec.com/docs/TECH170289) Now as you said, pass-through recall is gred out, This particul problem comes due to DCOM, EV licenses,...etc issues.

Can you please take dtrace on MMC and go to file server's properties from VAC?

This issue seems to be the same TN that EV-Conselor pointed out. A dtrace of the EvPlaceholderService in the Windows file server should be sufficient to confirm that issue and to determine if you need Pass-Through Recall enabled, Also, you can try to use FSAUtility to restore the placeholders as a workaround.

I've overlooked something rather basic here (I'm a little embarrsed to admit)

In answer to question 1, I haven't actually looked for whether it still exists

Let me confirm this and move to the other suggestions thereafter - I'll report back shortly

Many thanks for your help

Dtracing on EvPlaceholderService is definately useful to know exact error (most probably it would be 'Error 0x800710FE')

Before going to file server, I would say to fix "Pass through recall" option greyed out perspective as this is requirement for file server where Shadow copy is enable.

Dtracing simply on 'MMC' on EV would be sufficient to know exact issue, In order to reproduce it, start dtrace on MMC and open VAC (Vault admin console) on EV server, right click on file server's properites and close VAC.

I had two issue recently due to same problem, one was resolve by applying correct license and secnod was resolve after fixing DCOM errors. Following lines in dtrace can be seen if pass-through is grey out.

CAUIFileServerGeneralPage::EnablePassThroughIfSupported - IsPassThroughSupported() unable to determine if Pass-through recall supported on this file server

You can upload dtrace if further assistance require.

Hi folks, I have done some more work on this case and can report the following:

DTrace of MMC and EVPlaceHolderService attached

Ran Dtrace through Jiggle, which didn't throw any errors EV~ errors - I've attached a copy anyway

BUT there are references to - Failed to get .exe name for pid [4] using IPlaceholderSvcHelper, error: 0x80070005

I checked Pass through recall - Site/Target/File Server/Specific Server/Right Click/General and contrary to the Admin who rasied it with me, this config is NOT greyed out. That being said though, it's not configured either, so I tried adding a few paths, but this didn't resolve the issue

Also, I suggested to the customer they restore the file using FSA Utility, but we received the following:

I'm assured the item should still be available, as policy is to allow Placeholder deletions but not files, so I'm thinking the next thing I should do is take the saveset ID's registered in the DTrace and use that to try and find the file in SQL using the following query:

USE EVVSYourVaultStore_01
SELECT IdTransaction, ArchivedDate, idDateTime FROM Saveset WHERE idTransaction = ' valid transaction ID, it needs to be 36 characters, and is formatted like 8-4-4-4-12'

Worth mentioning as well there are no Errros/Warnings in the event log either

That should demonstrate if the file even exists right? If it does, can anyone suggest some next steps to try, before I log a Symantec case?

I do see expected lines in EVPlaceholder dtrace, However I would also suggest you to take dtrace on W3WP, StorageOnlineOpns from EV server & EVPlaceholder component on FS then reproduce this issue.

Logging case with support with above information would be worth.

The best way to confirm if file exist or not is via Archive explorer.

Update to this as follows:

Ran the following in DumpSaveSet

DumpSaveset 1B0D4A94F6DC33D4F987CCCB2DA5DA54D1210000EVSERVER2 201202088660790~201102020952090000~Z~006A1B89B9A700FF7F7C3189C9939F01 -o C:\test

I got a positive result and can therefore prove the file exists - so the error is not down to the file being deleted

Symantec recommended the following as next step

Then if the file IS still there then I would suggest recreating the placeholder with FSAUtility, sometimes FSAUtility needs to use the FQDN of the file server, plus it also has to match the entry in the SQL tables, to find out what that is run the below query:-

use enterprisevaultdirectory

select DnsName, UncName, PassThroughDiskCacheLocation

from fileserverentry

this gets me the FQDN of fraser.lesoco.local

So the next step once this has been reviewed by Symantec is to recreate the placeholder [using FSAUtility] using the now established FQDN

When I have further information, I'll post here until solution 

Thanks for update Casini, you can get information on recreating placeholders from TN http://www.symantec.com/docs/HOWTO37834

Run it against few test folders to see if placeholder can be recall, Example syntax

FSAUtility -c -s \\myserver\users -l 0 -r

I hope the similar suggestion would come from support as well.

Regards

EV-C

The above is correct.

Usually FSAUtility references the FileServerEntry table to convert the Servername to FQDN name so if we are tripping up there then we will need to look into the entries in that particular table.

Similarly, if you are still having issues in recalling the file with FSAUtility, if it is ONLY that single file that you need, now that we have recalled the file via Dumpsaveset, simply restore that file over the placeholder.