Searching a computer for file can take a long time and it will use a fair amount of CPU and lots of disk IO. The more files, the longer it will take. This can potentially bother the end-user of the computer or cause performance concerns.
Rather than create relevance that searches for a file (which will run when the BES Client starts and when a ForceRefresh is sent), it is a much better idea to create an action that searches the computer and then writes the results to a file, which can be read with a property. The action will give you much more control about when the search runs (using the action scheduling parameters).
Attached is a .bes file that can be imported into BES 6.0+ deployments. The file includes a Task with two actions and a property to bring back the results:
- One action will search for specific files and return the counts. For instance, if you search for "avi" and "mp3", it might return
avi - 16
- The other action will search for files with specific extensions and return the pathname and size. For instance, if you search for ".pst", it might return:
C:\Archive Data\archive.pst (134310 KB)
As always, when searching for files across a system: BE CAREFUL! Searching a file system takes a lot of resources. We continue to run across situations where users are saying that the BES Client is taking too much CPU and we find that they are constantly running searches across their systems.
Please test the attached Task/Property. It didn't go through any particular QA other than me testing it on a system or two. Let me know if it has any issues.