did you check the logs of your virus scanner?
We've had the situation that a new (buggy) signature blocks some apps or killed the (exe) files... :-|
Additionally did you check if your virus scanner can be configured not to check the running vulscan.exe. We did it with inventory scanner and vulscan, because otherwise the performance of our clients slow down...
False positives are a definitive option, Ahe - good one. Though traditionally AV vendors tend to pick on SOFTMON.EXE (for some reason) more often, I'm not aware of a vulscan-mistake yet, but definately something worth checking out.
As for the process-level scanning, that's VERY important to turn off - LDISCN32 (inventory scanner) and VULSCAN (the vulnerability scanner) both have a LOT of I/O in their own right already. If the AV wants to scan every single thing that those two touch, then you're causing yourself a massive overhead. Some things are just better not to have scanned on a process level .
- Paul Hoffmann
LANDesk EMEA Technical Lead
Are you all using LANDesk AV as well? Is LDAV smart enough to exclude ldiscn32 and vulscan from it's scanning process or should it be manually configured for exclusion? I/O and cpu util is a touchy subject in my world so anything I can do to limit that is helpful.
Please note that when I was talking about excluding LDISCN32 and VULSCAN from process-level scanning I was talking about a feature that McAffee and a few others have.
"Traditional" approach to AV is this (essentially) -- Scan the binary that's being run ... and any other binary it acceesses.
Process level scanning == "Scan the binary that's being run and any file / whatever this file touches".
This is the "increased paranoia level" - which is good if you've got viruses that may try to sneak into non-executables or so, but is a very big problem for stuff such as LDISCN32 / VULSCAN which essentially trawl through your entire hard drive (or the Inventory Service on the Core, for instance). This would turn a single scan into essentially 2-3 HD-wide scans, costing a LOT of I/O .
I didn't mean to insinuate that vulscan.exe / ldiscn32.exe should themselves be not scanned - after all, they - like any file - can get infected. I hope that this clarifies things a bit?
- Paul Hoffmann
LANDesk EMEA Technical Lead.
I think I may know what is going on here. I have seen where Vulscan determines that it needs an update from the core, it downloads the updated vulscan libraries, but the process doesn't finish for whatever reason... Now you are left with your vulscan.exe renamed to vulscan.old... and no exe to complete the update process.
If I remember correctly, I brought this up with development and some safeguards preventing this issue have been implemented going forward.
My recommendations for your current situation (if you haven't taken care of it already)
Create a software distribution job to either rename the vulscan.old to vulscan.exe or to just copy down the vulscan.exe from ldlogon to the ldclient directory. Using an inventory query for vulscan version or similar shouls allow you to target needed machines.
Looks like I got a good subject...
Thanks for the input everyone. I do have McAfee AV installed on 90% of the clients and on the the other is eTrust. Both apps are excluding the following...
While on the subject of excluding... Even though Vulscan.exe is excluded, part of my open ticket as mentioned in the first post is a mention that McAfee is still hammering Vulscan.exe or a related process when Vulscan is running. Something I was able to duplicate. Are there any other applications in which I should exclude that are LANDesk specific? A running list would be great.
I like where Tracy is heading, except some of the machine, according to the vulscan.log file haven't scanned since early May, which is before I installed SP3, or any other update. There are no Vulscan.old or Vulscan.exe in the sdmcache folder either.
I assume I will have to create that software distribution job, or use a login script to update the Vulscan.exe.
Any one else want to toss in their two copper coins?
Are any of you currently using agent watcher? i compared the agent watcher report called "Monitored files not found on clients" against an inventory query for vulscan.exe and the results are quite different. Agent Watcher produced a much smaller list of machines without vulscan.exe than the inventory query, which would lead me to believe that
1) We have alot of stale records out there in our DB or
2) We have a much bigger problem than just vulscan.exe being missing. Maybe the agent is either corrupt? Not installed completely/properly?
I guess I'm not sold that copying vulscan.exe back down to the problem machine will fix the issue, especially if (like you said Chris) there is not a current or old vulscan.exe file on the machine at all.
Jeremiah, we've had problems with CPU util as of late after flipping the switch on malware scanning. We've since had to disable it again so a full malware sweep does not occur with vulscan until we can figure out how to keep the clients from spiking and basically becoming useless for an extended period of time while that scan runs.