Jump to content

george.h

Members
  • Content Count

    225
  • Joined

  • Last visited

Everything posted by george.h

  1. Hi Ivan, Could you just clarify, when say KSC10SP2MR1 do you mean KSC 10.3.407 (with patches A and ? If it is, then that is what we are running and all the clients are running KLNA 10.3.407 (with patches A and . I've attached a version report for you. If not, then please state which VERSION you mean. I can’t see anything in the software version repot which allows me to find out anything other than the version number, so have no way (that I can find) to identify what SP and MR it is. Also, while I think it is probably related to the earlier WOL issue, it is not quite the same. The earlier issue affected virtually all endpoints and related to them either not being shutdown at all after a task has run (when configured to wake them up via WOL). Or it would shut ALL of them down even those already on. This one is subtler. It only affects some machines and not in a consistent manner. For instance, today of the 13 machines in the main management group all but 3 had worked (reasonably) correctly. Two of the three indicated that the last update was 2 days ago (it runs every 24 hours), and the third said 3 days. When I checked their event logs, there was indication of them being woken up for that task. Yet all 13 machines (some off and woken with WOL, others already on) did run the virus scan task scheduled for about an hour later. It is the peculiarity of most machines happily being woken (if needed) for both tasks, and yet others will only be woken (if needed) for the second. And not always the same machines or every time. I ran out of time to update the latest release last weekend but will tomorrow and see what happens. Kaspersky_Lab_software_version_report__12_05_2017_10_49_39_.zip
  2. Hi Ivan, I'm planning to do that this weekend (6th/7th May). Do you have any firm information that this issue (or at least WOL issues) have been addressed by the latest version? Or will it be, as before when I updated to 10.2.5.3201/10.3.407, updating in "blind hope" that it will fix "something", possibly to find out it doesn't fix it at all? Regards George
  3. Hi, Some while ago, after much frustration and trace logs (via Company account) we finally seemed to get a version of KES/KLNA in which WOL was working again, these being 10.2.5.3201 for KES and 10.3.407 for KSC/KLNA. Unfortunately over the past 3-4 weeks I've noticed it is broken - again. I have two tasks using WOL, an update task which runs at 23:15 every night and a virus scan which runs at 00:15. Some machines now are NOT being woken up for the 23:15 update task. It is NOT always the same machines and NOT all the time. It had been working OK (I won't say well, as it used to be working beautifully before you broke it last time and the "fixed" version has only been "so-so"). So what has broken on it now? I've checked the event logs on a couple of these machines today. The users shut them down before going home yesterday, and they were woken up to do the virus scan at 00:15 this morning. However, there is not a trace of them being woken up for the preceding update at 23:15. All the other endpoint in the same group worked OK (some where left on by their users, others were woken up by both tasks). If I can't depend upon WOL working then I'm back to running updates and virus scans (which STILL cripples endpoints) during the working day, which is not acceptable. I've also noticed that on these machines which appear to have "missed" their update task, if I run it manually they shutdown immediately afterwards, even though they are already on and a user logged on! Any suggestions? Also, why after I rolled out 10.2.5.3201 do some endpoints report as being "MR3" in the KSC version report and other as "MR2, MR3". All had MR3 rolled out to them in the same manner - uninstall, reinstall. All endpoints are running 10.2.5.3201, KSC is 10.3.407 and KLNA on all is 10.3.407 with patches a and b.
  4. Hi Kirill, I appreciate your reply, but it might help if you had read some of the thread. I DID raise a Company Account incident at the point (somewhere on page 1 I think) were I was asked to provide trace logs for this issue (the forum attachment restrictions make almost impossible to send these logs via the forum). That incident has now been closed as "fixed" by a patch which had not been release (at that point). The DLLs I referred do were sent to me VIA the (now closed by Kaspersky) Company Account incident. My comments about the release of patch B relate to the fact that in the last message I received via the Company Account incident, I was told it would be kept open until the patch was released. I was not told it had been released, and the only reference I could find to it was the beta testing post which said the "release date would be announced". I don't think burying the fact it has been released under the long "version information" topic counts as an "announcement". All it needed was a single line in the beta testing post to say "Now released dd/mm/yyyy" and giving a link to it. Is that SO much to ask? Meanwhile I have an issue which appears to be ongoing, you've closed the Company Account incident relating to it and I am one very, very unhappy customer.
  5. In a word NO. It is an improvement, but it still appears to shut down machines which were already on, but no user logged on - but not all of them. I need to roll out the patch to some more machines and do some more testing to determine why some were shut down and some not. Not being able to predict the circumstances under which it will or will not shut a machine down is really shoddy. It is also becoming somewhat tedious being repeatedly asked for trace logs for this issue, supplying them, sent DLLs to test which are allegedly different only in logged level but in reality are very different, getting no answers, being told it has been fixed when clearly it has not, and insufficiently tested for this issue before being released. I also notice that the "sticky" post about the beta testing of this patch still says: "Please be kindly informed that we have finished testing of patch 'b" for KSC10 SP2. We will announce the official release soon." i.e. NO statement that it HAS been released. Or does this actually refer to a completely different patch "b". Your convention for naming patches and releases has become, shall we say, rather convoluted and hard to follow.
  6. Thanks for the link Artem. It might be useful if someone updated the beta testing post Patch B Beta Testing saying that the patch has been released. Shame it is not an auto-patch. Too much manual faffing about with patches while effort seems to be devoted to non-core functionality. Stick to anti-virus/anti-malware and stop trying to do everything...
  7. Ok, so when is patch B going to be released? KLNA on all of my endpoints are still on patch A and the post about beta testing of patch B: https://forum.kaspersky.com/index.php?showtopic=364395 said the release date would be announced soon, but I've not spotted anything. Regards George
  8. Erm.... I did! The assumption from the Kaspersky side seemed to be that the second DLL (the one which wasn't supposed to fix the problem, just provide more information on why the DLL which WAS supposed to didn't) would be used, after investigation as to why it DID seem to fix the problem but the supposed fix didn't, in patch B. It was left as the incident would be left open pending the release of patch B and my verifying it: "Jan 12, 2017, 12:28:08 PM Hi Akil, Attached are the results from the first tests using the klcsnagt.dll file you supplied. One ZIP is the standard GSI report, the other contains ALL the log files produced by the agent will trace turned on. This test was with the machine already powered on but nobody logged on. There is definitely something different going on with this DLL. Right up to the point at which I swapped the DLL over (stopped main Kaspersky, the klnagent.exe service, renamed the old DLL, dropped in the new one and started klnagent.exe and main Kaspersky again) it was being shut down after the update task if already powered up but nobody logged on. With the new DLL it STAYED ON even with no use logged in! So not sure what the traces will reveal as it seems to be working how I would expect it to - so far - if working properly." The OLD DLL in the quote above is the ORIGINAL DLL supplied as a workaround. The NEW DLL is the second DLL supplied which was supposed to be IDENTICAL to the first, just with increased logging capability to help determine why the supposed workaround didn't work. "Jan 17, 2017, 12:57:10 PM Hi George, Thanks fro your reply, I will let you know when it is released and keep this case open until you have tried the patch and it has resolved your issue. Kind regards Akil" Above is the last communication I had via Company Account My concern is WHICH of those two DLLs is the one incorporated into patch B? The first which is supposed to be the fix but doesn't work, or the second which is supposed to be the first just with increased logging but actually seems to work (for reasons which have not been explained)?
  9. Erm... Not quite correct. The "workaround" did NOT work. The DLL I was subsequently sent, which was supposed to be identical to the first, only with increased logging capability, behaved very differently. That one was NOT supplied as a workaround, merely to try and obtain more data. Clearly there is difference between the two that affected the problem, when the two DLLs were supposed to be otherwise IDENTCIAL. No explanation has been given for the difference in behaviour, which means it merely HAPPENS to have MADE THE PROBLEM GO AWAY. There is a HUGE difference between fixing a problem and just making it go away. That difference is understanding what was causing the problem. Fixing the problem requires understanding. Making it go away involves "fiddling about" until it seems to work WITHOUT ANY UNDERSTANDING of why. Without an explanation you've just happen to have made the problem go away, with a DLL which was supposed to be identical to the "workaround", which didn't work, but clearly wasn't. Let me be very clear - the DLL supplied as a workaround DID NOT WORK.
  10. Well this is interesting... The last update I had via Company Account under incident INC000007110573 was that they would keep the incident open until KSC10 patch "b" (which I see has just finished beta testing) was released and I'd tried it. Well as far as I'm aware it hasn't been released, yet, but the incident has been marked as "resolved" - no it hasn't - and "closed". Why?
  11. Is it me or does the latest version of Kavremvr NOT support removal of the Kaspersky Network Agent? I downloaded the current version this morning (the 13.3MB version) and after removing KES SP1 MR3, it left the network agent. When I ran it again it FAILED to identify the network agent and it doesn't appear on the drop down list of Kaspersky apps.
  12. Well the latest is that I was informed via the Company Account incident that this was a "known issue" and to try the "fixed" version of "klcsnagt.dll" attached to the incident. Didn't make the slightest difference. If you have "Activate compute before task" enabled, then it doesn't matter what you have "Shutdown computer after task" set to, or whether the PC was on or off before hand, Kaspersky WILL ALWAYS shut it down. Can you confirm that Kaspersky have actually verified, in their own labs using this version of KSC, KLNA and KES, that it actually WORKS and DOES NOT shut down PCs it is not supposed to? If not then before asking for traces you actually need to test it yourselves. We're customers, not guinea pigs!
  13. Hi Konstantin, I've opened the ticket via "Company Account": INC000007110573 I've put the salient details into the ticket, plus a link to this thread. I've also mentioned that due to the Christmas holiday period it may be up to two weeks before I can actually generate and post trace logs. MINOR UPDATE: My test PC in my Test Group ran it's Test Virus Scan Task today, with only the "Activate computer before the task..." option enabled (i.e. wake up endpoint using WOL), and the "Shutdown computer after task is complete" option DISABLED, and right on queue at the end of the scan it SHUTDOWN!
  14. I'm seeing what seems to be EXACTLY the same problem - with KSC/KLNA 10.3.407 and KES 10.2.5.3201. My report endpoints being turned off if WOL enabled I only upgraded to these version at Kaspersky's recommendation in case it fixed another WOL related issue. That was where WOL worked fine, but if you enabled the "Turn off after task is complete" - supposed to turn endpoints off ONLY if they had to be woken up, which would be very useful as we schedule full scans in the middle of the night - it instead ALWAYS turned endpoints off. This produced a barrage of complaints from users when the late morning virus update shut all the PCs down. So far the only response I've had is "send traces"....
  15. Ok - In preparation for full testing and trace file generation, I've set up a Test Group. I've configured two test tasks, one Update task and one Virus Scan task. Both are configured (initially) with "Activate Computer" enabled, "Turn off computer after task is complete" disabled. I also have a Windows 7 Pro (32 bit) test bed machine which I've added to the group. This is on the local LAN so I can reliably turn it on/off and manage it using either KSC, standard WOL utilities and remote desktop. This will allow me to do testing without getting bombarded with complaints from users about their machines shutting down on them. I can also vary the schedule as much as I like and with each task running as little or often as I need. Testing and production of trace files may take a while. I'm on holiday for most of the next two weeks over Christmas, from Monday 19th December 2016 until Tuesday 3rd January 2017. I have a "Company Account" setup under the email on my profile so will need a ticket generating on there for me to send the trace files in.
  16. For completeness (in the absence of traces) here is a screen shot from the event log of one of the 4 machines at the far end of the VPN which were ALREADY ON. Again - shutdown by Kaspersky when no shutdown was set - ONLY WOL.
  17. And final two. For the moment I have no option but to COMPLETELY disable WOL in ALL tasks.
  18. Well so far upgrading has actually made this WORSE! Two groups of machines are configured so far JUST to use WOL, NO SHUTDOWN. Last night Kaspersky SHUT THE WHOLE LOT DOWN! Every single machine in a group with tasks configured to use WOL were shutdown. One group (12 machines) were all off. The other group (4 machines at the far end of a VPN) were all ON. The problem behaviour so far has been that while WOL will power on machines they stay on - which is as expected. If you set the "Shutdown after task complete" option, it shuts them down irrespective of whether they were already on or not. NOT ANY MORE! Now even just being configured to wake up via WOL, they ALL get shut down. This makes the WOL facility UTTERLY USELESS! At the moment I have no traces because at this stage I wasn't expecting problems - NONE of the tasks has the "shutdown after task completes" set! You are also going to have to open a ticket for me as that is the only route to upload traces - my experiences with trying to get anything meaningful in the way of support via Wick Hill in the past have shown them to be a complete waste of time. In the mean time here are some screen shots - that at least will give you something to go on. Congratulations! Far from potentially fixing the original problem, your recommendation of upgrading to the latest version has not only FAILED to fix the problem, it has actually introduced a WORSE PROBLEM! At the moment I've a hairsbreadth away from saying "instead of sending you traces, how about you send me a refund for the remaining 8 months of our licenses and I'll go and buy someone else's product that WORKS!"
  19. Hi Ivan, After an initial several hours of infuriating frustration and pulling out of hair (not that I had much!) things appear to have stabilised considerably. All the endpoints have now had KLNA 10.3.407 and KES 10.2.5.3201 deployed to them. From my experience I would make the following observations: 1. Many of the initial problems seem to be due to the way the upgrade to KSC dealt with the existing policies and tasks. It basically screwed them and applied them to the wrong machines wreaking no end of havoc. That really should be looked at. However, so long as the current apparent stability of my PC estate continues, there is no way I'm volunteering to re-install KSC to find out what happened or why. 2. Anyone else finding the same issues - policies and tasks for older KES versions being "converted" then applied to the wrong machines, the correct ones being disabled or no working properly - might find deleting ALL policies and tasks, then restarting the Kaspersky Labs Administration Server service, followed by the endpoints, may help. Only then create new tasks and policies and apply them. 3. Don't try and do ANYTHING on the admin server during a virus scan task on the server itself. 4. When deploying over lower-speed connections, particularly WiFi to laptops or remote VPNs, do them one endpoint at a time. KSC has a tendency to become unresponsive if the communication isn't very very reliable. It also tends to hang if you try to run other tasks at the same time as an install to a lower-speed connection endpoint. 5. If/(when) KSC becomes unresponsive for more than 30-60 seconds ("Not Responding" in the title bar), restart the Kaspersky Labs Administration Server service. That seems to be the quickest way to get it back. For the moment I'm just going to see if the overnight updates and virus scans work ok, including waking up 12 local endpoints. There also seem to be some issues with version reporting - a number of endpoints report MR2,MR3? I also still need that explanation on exactly HOW the "wake up/shutdown" mechanism is supposed to work as regards machines already powered on.
  20. I think your product has already screwed up more than enough today for me to give it a second chance to screw up even more by re-installing it. It did screw up and you (Kaspersky Labs) need to go back to the installer and it's scripts to figure out WHY. Under what circumstances could it happen and NOT report a SINGLE error during installation and migration. Besides the initial big problem - KSC crashing frequently - appears to have stabilised since restarting the Administration Server service (which you didn't even suggest). Since I deleted all of the screwed up tasks and policies BEFORE I restarted the service, my best option is to see if it has now CORRECTLY applied the new policies and tasks. It will give some indication of how many of the problems have been caused by the screwed up policies/tasks. I wonder how much of KSC's instability was also caused by the same screw up, and if restarting it after they were deleted has helped "clear out the garbage"? All of this is still just to get to a position where I can re-test the original issue - endpoints which are already on being shutdown when using using the "Shutdown after task completes" option. I still would appreciate a proper answer on how that mechanism is supposed to work as I very much doubt it is a simple as "send WOL, send shutdown command". After all I was told (on here by Kaspersky Labs) that is should only shut down an endpoint if that was already powered up when the WOL for the task was sent. Or have I been given completely incorrect information - which would make it a pretty useless feature?
  21. I'd appreciate some answers first. If I HAVE to go down the route of re-installing KSC, it WILL be 10.2.434 and I'll not be touching 10.3.407 ever again. YOU know the internals of your software - YOU work out why it could have made a complete pigs ear of the tasks and policies and provide some answers. Also, the endpoints which HAVE been upgraded to KES 10.2.5.3201 (mr3 - for some reason a couple show mr2.mr3 why?) they still use way too much CPU resources.
  22. How about providing some answers to my questions, followed by instructions on ripping out 10.3.407 and reverting back to the previous version 10.2.434? That was at least stable. This one is anything but. I can't seem to be able to do the simplest thing, like stop an installation tasks that has hung, or delete an old task, without it crashing. UPDATE: Stopping and starting the Kaspersky Lab Administration Server service APPEARS to have improved it stability. At least it seems to be able to do more than one task at once without crashing! So far I am NOT impressed - and I still require answers to my questions BEFORE I'm wasting time gathering umpteen traces. YOU should know why your software would convert non-MR2 tasks and policies and apply them WRONGLY to MR2 machines.
  23. Well first of all why did it convert non-MR2 policies in the first place and apply them to MR2 machines? This is in addition to DISABLING the existing MR2 specific policy! It should NOT have done that. It also should NOT have applied BOTH non-MR2 AND MR2 specific tasks to MR2 machines - but it DID. And they still don't seem to work! All the desktop machines started a virus scan at 10:30am'ish when the only scheduled scan is not until 00:15 TOMORROW! Worst of all, KSC keep crashing - OFTEN! I go to start an installation task, modify the list of computers and "(Not Responding)", followed a little while later by "Lost connection to Administration Server". So far - utter garbage!# Sorry but I need MUCH more information on precisely HOW Kaspersky does the wake-up/shutdown? How does it determine if a machine SHOULD be shutdown (i.e. if it was ALREADY ON!). Why did it used to work with machines at the far end of a VPN if ONE KSC managed PC is on, even though standard WOL utilities can't? Except now that either doesn't work or only works sometimes.
×
×
  • 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.