Jump to content

mountschool1

Members
  • Content Count

    19
  • Joined

  • Last visited

About mountschool1

  • Rank
    Candidate
  1. I don't want to be funny but, bearing in mind that this thread has been running for nearly a year, just how much time do you need? I have checked every server I have. The number of processes running is ALWAYS equal to the number of processors present in the system + 1. This NEVER varies! The amount of memory used by each process does vary - between 25 and 50+ Mb. DFS = Distributed File System. FRS = File Replication Service. Staging area is a fixed amount of disc space (controlled by a registry key setting) allocated to DFS to hold changes made to files prior to writing to replication partners. As the replication between DFS partners is a background process this area can, if there is a problem, become full. When this happens the service stops. This in turn leads to a mismatch of data between the DFS partners. Mike
  2. Well, that was an idea that worked really well didn't it!?!? (Yes, I am being sarcastic). We seem to be going round in circles here. Support_Mike (KL Partner US) says that the multiple processes are to give a bit of umph to the on-demand scans and do NOT have any effect on the on-access part. Now we're told that they are really there to give more welly to the on-access scans. To be honest I don't care which is true and which is fantasy because IT DON'T WORK EITHER WAY!!! Amongst others, I have 2 servers with multiple processors running DFS. I have had to disable the on-access scans on them because the performance hit is so hard that the staging areas max out and the FRS dies.
  3. As far I know there is no way to limit the CPU usage during an on-demand scan, but you have a couple of options. You could either reduce the files scanned during an on-demand scan or even not bother. This may seem like madness but I'm not so sure. If you have on-access scanning running all the time I have never really been convinced that an on-demand scan, using the SAME engine and database, is going to find anything new??? That said, I still do it once a week!!! If this is not acceptable, try scheduling the task to run at a time when the machine is less busy. We do this and it seems to work. The machines can always be shutdown after the scan using something like Sysinternals PSSHUTDOWN. Mike
  4. The server I quoted in my previous quote is running version 5.0.74. I still fail to see why it needs to start multiple instances at all! If multiple instances must be started then they should start as required and stop when no longer needed. Mike
  5. The problem is not that the product has multiple instances of the monitor running per CPU but that it has multiple instances period. My servers have 8 CPUs each (that's 9 KAV monitor processes per server using anything up to 50Mb of RAM each). As an example, I have a server that right now is show 612Mb of physical RAM committed of which KAV is using 428Mb! If I'm reading your post correctly you are saying that KAV creates a monitor process per CPU, JUST IN CASE I want to run an on-demand scan?! This can't be right. Surely it's not beyond the Kaspersky programmers to have the additional monitors fire up as needed if they really are needed. At the risk of upsetting everyone and being branded a heretic, I have to say that Sophos doesn't seem to be blighted with this or any of the other problems that seem to beset KAV, AND the Enterprise Management Console's pretty good too! Mike
  6. I'm not going to give up on this. Someone must know the answer. Mike
  7. I have collected information and passed to Kaspersky - on going problem. The very fact that this thread exists and that we all have similar experiences tells me that they are well aware of the problem and that it's not restricted to just a few users. A reseller asked me recently what I thought of Kaspersky as a whole. I said that the AV was rock solid and probably as good as it gets but that the adminkit was not so hot. Apparently his own experience is no better than mine and he too is not impressed! I, like you, hope that they fix it soon but must confess that I am not overly optimistic. I have been using the administration kit for many years now and can safely say that it has NEVER quite performed as expected. It looks better now than it did when I first used it in an NT4 network but it's still very slow and buggy.
  8. Still waiting for an answer to this one! Mike
  9. Made absolutely no difference. Still all over the place, still misreporting workstation status. However, I've read another thread on the forum that says that version 5.0.523 of the workstation AV is due on Monday. Maybe it can talk to this version of the agent better. I'll wait till then. Mike
  10. Things seem to be going from bad to worse at Kaspersky. I have downloaded and installed the latest adminkit (5.0.1149). I have pushed the new agent to my workstations and all hell has broken out! Workstations are shown as not having protection running, I cannot start or stop KAV application. When I check locally on the workstation it IS running. I get error messages when I try to synchronize saying that the machine is unavailable on the network, yet I can remote desktop to it, I can ping it and I can manage it remotely. The misinformation is worse than it not working at all. I waste time that I haven't got trying to fix something that's NOT broken. The whole thing is POOR, POOR POOR!!!! Can I suggest that Kaspersky stop messing about with how it looks AND start concentrating on making it work!!! I'm told Sophos is very good. Maybe it's time to defect. Mike
  11. All of my workstation are new installs of OS. No previous version of any sort of AV on any of them. Network agent and Kaspersky 225/228 pushed from adminkit. Like I said, this is new to version 5 (maybe and undocumented feature of software ). This is too random to be explained away as a conflict between versions. Mike
  12. Thanks to everyone - problem has gone for now. No idea what was wrong, but 1 reinstall and 2 restarts later all is well!
×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.