• Facebook
  • RSS Feed
  • Instagram
  • LinkedIn
  • Twitter
Sep 232013

OLYMPUS DIGITAL CAMERASometimes in order to figure out what is happening in Enterprise Vault FSA it might be necessary to determine which process is recalling items. What I mean is that you might see some sort of mass recall issue, where lots and lots of items are constantly being turned back from placeholders to full-fat items, and, you want to know why!

The way to determine what is recalling the placeholders is to perform a DTrace of the EVPlaceholderService, perform a recall (or leave things running for a while if something is mass-recalling items) and then review the DTrace. In detail then we would:

1. Login to the file server that is hosting the Enterprise Vault placeholder service.
2. Open an elevated command prompt
3. Go to the EV Program Files folder
4. Launch DTrace (by typing dtrace, and then return)
5. Do: set EVPlaceholderService V
6. Do: log c:\temp\who-is-it.log
7. Maybe, depending on how busy your file server is, do the command MON, just for a little while so you can see things working.
8. On a desktop/laptop machine, open Windows Explorer, and browse to the share (or one of the shares) that is on the file server that was just configured for tracing.
9. Open 1-2 placeholders of different file types
10. Check that MON is showing something.
11. Review the trace.

In the trace you should see things like this:

210 10:58:50.568 [3,844] (EvPlaceholderService) <2848> EV:M Filter message event signaled [WAIT_OBJECT_0 + 1]
211 10:58:50.568 [3,844] (EvPlaceholderService) <2848> EV:M [EvRequestArchivedFile] Queueing placeholder request for file: C:\source\EV 2007 ReadMeFirst_EN.htm
212 10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:L {RequestArchivedFile::RequestArchivedFile} (Entry)
213 10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:L RequestArchivedFile::RequestArchivedFile Caller SID is S-1-5-21-2561182712-3591106754-569776174-500
214 10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeName: Trying to get the .exe name for pid: 3888
215 10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeNameUsingPHHelper: entry - PID:3888
216 10:58:50.600 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeNameUsingPHHelper: exit - PID:3888, exe name:iexplore.exe
217 10:58:50.615 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeName: The .exe name for for pid: 3888 is iexplore.exe
218 10:58:50.615 [3,844] (EvPlaceholderService) <2848> EV:L {RequestArchivedFile::RequestArchivedFile} (Exit) Status: [Success]
219 10:58:50.615 [3,844] (EvPlaceholderService) <2848> EV:L {CQueue::EnQueue} (Entry)

That can be helpful to see what is recalling files, though of course you might have to leave the trace running for some time in order to see the mass-recall effects. You might also see that the PID can’t be resolved to a process. In my testing this was always the case when the recall was happening from a different machine, rather than the local file server… your testing results may differ!

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>