Jump to content

wjfox

Members
  • Content Count

    17
  • Joined

  • Last visited

About wjfox

  • Rank
    Candidate
  1. Some additional info... I've noticed on a clean install it is installing the local tasks as scheduled tasks, not manual, per one of my above screenshots. Possibly an upgrade install sets them as manual tasks as I am seeing both situations on my network. Also, the local update task is visible in SC in the individual client machine properties upon install, once you reboot the machine after the client install it then disappears from the properties in SC.
  2. Had some time to dig some more. I can't find an example of the scan task 80099001 but it is probably not needed if they figure this out. Settings shown with policy enabled and then disabled. Those tasks are running according to those schedules.
  3. I also have not yet been able to confirm what is actually throwing the error(s). I am seeing this for scan tasks as well not just updates. As best I can tell these are the "rogue" local tasks. I can confirm with the scans that is not reporting the exact task correctly, it will say one scan when it actually ran some other scan. I rename my tasks so they show up differently in the logs, but I still can't confirm anything with update. When I test the update task it works and nothing is logged at the SC. My non test machines however are rolling in the errors one after another. They had something previously during the setup wizard that asked if you wanted to create policy for local tasks during install, there is nothing for that now. I have wondered if the issue might be due to "remnants" of those policies when upgrading rather than doing a clean install?
  4. Can't seem to be able to find the Edit button... Update does not appear in the computer properties tasks at the SC.
  5. None of that works. Once I have a machine go red thanks to an unprocessed object, which never shows up in unprocessed objects at the SC btw, it stays that way.
  6. At the SC the only way to view and manage the local tasks is by selecting an individual computer, going to properties and then tasks. There is no group task setting to control these. How is an admin supposed to manage these tasks for a multitude of machines? By default these tasks are all run manually. However, I have local tasks that didn't take those settings and they are running whenever they feel like it according to whatever weird schedule they set for themselves. In my case both update and custom scan are trying to run and throwing this error. I am not going to access Tasks in individual computer properties to control these settings one machine at a time. That is ludicrous. There used to be server side management policy for local tasks, what happened to that? I can remove local access to the task, just figured that out this morning right before checking the forum, but those tasks remain in the SC individual computer properties and really clutter things up but moreover, they are still running according to whatever bizarre schedule they set for themselves. The other setting "Allow management of group tasks" doesn't actually appear to do anything. If you add tasks to perform the functions of these local tasks, it just adds more tasks on top of the slew of other tasks already in there. There should be a way to control those existing settings from SC, either in policy or in tasks. What was the purpose of the local tasks besides to give admins a headache? Something was overlooked in development. :dash1:
  7. I'm actually getting this for other tasks as well, just noticed it yesterday. I don't recall which others but it does to seem to be task related and not necessarily update task alone. I am getting a 'dirty task' error in event viewer on the server as well, I don't think it is related but you guys might look for that also.
  8. Having the same problem here. I've seen a lot about this error in the non-English forums which doesn't help much. If they found a solution I don't know what it is.
  9. Put those machines in their own group and create an update task (or just modify your overall (parent) update task). You can assign the update source in the properties heading of the task. You can use just web or server or both. If one source isn't available it will move on to the other. You can move them up or down for order of precedence.
  10. That was it for my case exactly mate, thanks a million. This is a virtual server which was renamed after being built but something is apparently retaining that initial name, or KAK was installed prior to the rename, I can't remember which. :cb_punk:
  11. Mine is there and accessible, both locally and on the network.
  12. Same problem here. Except this is a 2008 R2 x64 box so my paths are different.
  13. I'm having the same problem, same versions. Anytime I use Add/Remove Columns in Events it crashes out and does the same thing as yours. I rearrange the columns so they are actually showing me useful information without having to scroll back and forth across the screen all the time. I have noticed that if I do this only on the physical Admin machine I have no problem. However, I usually remote desktop into the machine and when I rearrange the columns from a remote session is when the problems start. Now, even reinstalling the Admin Kit doesn't fix it. I cannot access any Events at all. Attempting to do so results in the same thing, dump file and crash, though lately now all it does is crash.
  14. So shall we also assume that Kaspersky will no longer support XP, Office 03, Server 03, etc etc etc as of 4/14/09 because they also reach MS mainstream EoL next month?
  15. I found a little more info: With the new Trojan.Flush.M variant discovered on December 3, 2008, the core thinking to DNS altering seems to have shifted again. The trojan now makes use of a legit file, ndisprot.sys, the ArcNet NDIS Protocol Driver, in order to set up a fake DHCP server on the compromised system. This is registered as a service on the machine, and intercepts DHCPDISCOVER packets from the computers on the network. The rogue DHCP server responds to legit requests with packets containing malicious DNS servers from the 85.255.112.0/20 block. This is an IP range known for being used in various online illegal activities. The anti-spam organization Spamhaus added it to its block list since last year and Bojan Zdrnja from the SANS Internet Storm Center notes that “it's probably wise to at least monitor traffic to 85.255.112.0 – 85.255.127.255, if not block it.” There are several significant implications to the new technique. First of all, it also affects non-infected systems on the network. Then, it doesn't always compromise a system. Sometimes it succeeds and sometimes it doesn't, depending on how fast the network's legit DHCP server replies. This certainly makes it harder for administrators to track compromised machines on larger networks. The uncontrolled nature of public wireless networks is another factor of great concern in regard to this attack.
×
×
  • 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.