Forum Discussion

KeirL's avatar
KeirL
Level 6
12 years ago
Solved

FSA - something is recalling placeholders!

Hi

I've just implemented a new EV 10.0.2 solution for email and file archiving and am experiencing difficulty with the placeholder service. The FSA configuration is 2 x windows file servers (one is running 2008 R2 and is VMware vm and the other is a physical Windows 2003 SP2 - 32bit). I have a single share on each server and single folder on each share. The archiving strategy is to move 'project' work into this folder once the projects are complete and EV to archive these  projects after overnight. So I've created a folder policy to archive all files older than 0 days and set the shortcuts to create placeholders immediately - the vault store is set to remove safety copies after backup.

Everything seems ok and to test this I took a sample project moved it into the archive folder and kicked off the archiving task - the files were archived as expected. I then ran a manual backup to ensure the safety copies could be removed and re-ran the FSA task. The files were immediately replaced by placeholders as anticipated - however within seconds they all started to come back again.

AV is the most likely suspect but the 2008 server has no AV installed and the 2003 server had all the AV services stopped. I also stopped all the backup agent services (there were no backups running anyway) and also checked the beremote.exe was in the 'exclude .exes' registry key. I've run dtrace on both servers to try to find which process is recalling the placeholders but all I get is the below:

1949   18:18:56.983  [2452]       (EvPlaceholderService)     <780>  EV:M       WorkItem::GetExeNameUsingPHHelper: Failed to get .exe name for pid [4] using IPlaceholderSvcHelper, error: 0x80070005

I can't think of anything to try next - both servers a very different (eg diffent versions of OS, one physical and one virtual etc) so I'm thinking it must be something on the EV server?? I'm using the EV agent for backup exec to backup the system (hence why 10,0,2 and not 10,0,3) and there are no vault stores stuck in backup mode.

The email archiving is working fine and archived mail stays archived - 

All thoughts greatfully receieved.

many thanks K

  • Thanks Rob

    I did get this sorted in the end - turns out it was something on the client system I was testing from! I'd mapped a share to watch the placeholders appearing and to make sure I could recall files etc, but that particular client was causing the issue (I suspect antivirus) as it wasn't part of the AV policy settings. I tested many other machines and all ok, so I guess it was just a bad choice of machine to test from :o)

    Thanks all 

  • Hi Tony

    no  (but I'll check) :o)

    These shares were only created today and there aren't any mappings created yet as it's still under test. But I'm intrigued as to why Mac's may have this effect.... maybe it will spark a few more ideas\tests I could try.

    thanks

  • no replication software involved, but I'm thinking that I could make the folder a hidden share (just for help with fault finding) which I (hope) would prove that any 'browsing' client (eg Macs) would should not have any undesirable affects.

    would it be fair to say that if it were a hidden share then this would narrow down the serch to something local to the file server ? eg locally installed applicatios?

    I also tried to put *.exe in the 'exclude .exe' registry key as a test..... are wildcards allowed? the issue still occured all the same.

     

    thanks

  • Thanks Rob

    I did get this sorted in the end - turns out it was something on the client system I was testing from! I'd mapped a share to watch the placeholders appearing and to make sure I could recall files etc, but that particular client was causing the issue (I suspect antivirus) as it wasn't part of the AV policy settings. I tested many other machines and all ok, so I guess it was just a bad choice of machine to test from :o)

    Thanks all