Jump to content

george.h

Members
  • Content Count

    225
  • Joined

  • Last visited

Everything posted by george.h

  1. I haven't even begun to rollout KES 10.2.5.3201 to the user endpoints. So far my impression - wish I hadn't bothered. Nothing but problems. 1. Non-MR2 policies (for machines PRIOR to MR2) were converted and applied to all machines, INCLUDING MR2 (should not have been) 2. MR2 specific policies, which I'd created BECAUSE I had to for MR2, were NOT converted and disabled 3. Non-MR2 tasks, which only applied to any machines with KES PRIOR to MR2, were converted and applied to ALL machines, INCLUDING MR2 (should not have been) 4. MR specific tasks, which I'd created BECAUSE the other tasks DIDN'T WORK with MR2, were not converted BUT STILL APPLIED! Sort of! 5. All the tasks are now not working properly 6. Kaspersky has now initiated a shut down of the domain controller TWICE! It could only have got that from the older (non-MR2) tasks which SHOULD NEVER HAVE BEEN APPLIED. Even then, after I'd deleted all of the non-MR2 tasks and re-applied the MR2 ones - which DID NOT INCLUDE A SHUTDOWN after completing a task - it STILL SHUTDOWN!!!! What a mess! I'd much rather you'd just fixed the damned problems in the older versions of KES, KSC and KLNA. I've now deleted ALL of the tasks and am having to waste an awful lot of time creating NEW tasks, which you specifically said I would not have to. Also you have still not provided ANY information on how the Power ON/Shutdown mechanism is supposed to work, which I specifically requested.
  2. Hi Artem, Just a quick update. Ive downloaded the full (1.2GB) install package for KSC 10.3.407 and upgraded the admin server (which is the same Hyper-V VM as our primary 2012r2 file server). I've also installed KES 10.2.5.3201 (with KLNA 10.3.407) on both it and the Hyper-V VM runnig our DC. Over the next day or so I'll roll-out KES 10.2.5.3201 (with KLNA 10.3.407) across the endpoints, verify they all working correctly, and that the policies and tasks have been converted correctly and are also ok. I'll then be able to retest "Shutdown after task completes" with machines already OFF (to check if they power on, run the tasks and shut down again), and some machines already ON (to check if they run the tasks and then STAY ON).
  3. Thanks for the info Artem about policies and tasks for latest versions. I appreciate that it is "best" to keep up to date. However, long experience has also shown that upgrading from existing stable versions, for the sake of "keep up with version numbers", all to often breaks things. Sometimes catastrophically so. I will be upgrading but, with the Christmas holiday period approaching I'm going to be cautious to ensure I'm not introducing a truck of problems just before I start my holidays.
  4. Hi Artem, I've checked UDP 15000 and all endpoints are listening on that. No surprise there, since they all show up in KSC and can (generally speaking) be managed from it. As I said in my previous reply, an explanation of how the Wake Up/Shutdown mechanism is supposed to work would be appreciated. Also, do KSC/NA 10.3.407 and KES 10.2.5.3201 address the issue (on some machines) of WebAV spontaneously and randomly malfunctioning and blocking all web browsing until KES is stopped, then restarted.
  5. Thanks for the suggestion Artem, I'll check UDP15000. I'll also look at moving up to KSC/NA 10.3.407 and KES 10.2.5.3201. Any downsides to upgrading the version of KES? Such as having to recreate all the tasks (again) as I had to for 674 MR2? I'd rather know about that beforehand rather than suddenly find none of the tasks work as I did the first time around. Some explanation of how this mechanism is supposed to work would help in figuring out why it may not be working, rather than just "try this", "try that", "try the other". After all it WAS working. Regards George
  6. At some point during the many patches and updates for KES/KSC/KLNA that get deployed automatically, I found that one VERY useful feature seemed to start working properly as follows: I could schedule Update and Virus scan tasks for any time I wished and enable both "Activate computer by WOL" and "Turn off computer after task is completed". For a while it worked perfectly. At night (I have an Update task scheduled at 23:00 and a full Virus Scan for 00:05) any machine switched OFF (most) would power on, run the task, then shut down again. Machines already ON when the scheduled time came around, would STAY ON after completion, which is how it should work according to the explanation I received from Kaspersky (on here) some while ago. This is very very useful, as I also have an Update scheduled for 11:00, during the day. I used to also have a virus scan but that suddenly started to take HOURS and cripple performance, so I disabled it. Again any machine switched OFF (few) would power up, do the task then shut down again. Machines already ON, which is ALMOST ALL, would run the task and then STAY ON! One additional useful behaviour I noticed (not sure if it is by design), is that machines at the far end of a VPN tunnel, which ordinarily don't respond to WOL, DO when issued by Kaspersky providing at least ONE KSC managed PC at the far of end of the tunnel IS switched on. It is almost as if it proxies the WOL through it. I'm not sure when, but a couple of months ago I noticed a lot of machines were staying on over night which hadn't before - in fact ALL of them. When I eventually got round to investigating I found the "Turn off computer after task is completed" had been disabled. So I re-enabled it, and all hell broke loose. For some reason it has reverted to the old behaviour from quite a while ago - it turns off EVRYTHING, not matter what it's initial power state. So when then 11:00am virus update task competed during the working day, EVERYONES PC just shutdown on them! It is also a major pain for the machines at the far end of the VPN tunnel. I would normally ensure at least ONE is powered up so that the rest can be powered up via WOL (how that worked I don't know but it did and was bloody useful!). Now they ALL get shut down and, with nothing to proxy through, can't be powered back up via WOL. KSC is 10.2.434 with patches b, c, d and e KLNA is 10.2.434 on all machines with a minimum of patches b and e (some also have c or d or both, not sure why). Endpoints are KES 10.2.4.674 MR2. Not all machines show as MR2 in KSC but they are. Generally any that have had it installed from a package with MR2 built in don't show it - not a very bright idea that one! Enpoints are Windows 7 Pro SP1 (all but 2 are 64-bit) plus all outstanding updates. So what has happened to stop this very useful feature from working? It is very useful as some of our machines power USB equipment which users would rather not have left powered on over weekends and holidays (such as USB spectrometers)., but which should still get updates. Those same users can keep irregular hours (including holidays) and the machines need to be up to date, protection wise. Any suggestions?
  7. Hi Kirill, Thanks for the suggestion, it proved very useful. When I checked the results of events on the test machine 9ZFCCC2 (show in Scan Times Screen Shot A) you can see the initial installation of 10.2.2.10535 and the initial virus scan I started at 9:39am which completed at 10:30am (50 minutes). Later though you can see it did actually do the scheduled update at 11:00am followed by the scheduled virus scan at 12:00pm - that took only 22 mins. Once it had completed the upgrade to 10.2.4.674 MR2 the next two scans (one manual and one scheduled) took 48 mins. Since then it has been taking around the same time. Unfortunately the modify task events make the picture a little confusing. In addition that machine will no longer be available for testing for a while. For the moment I have implemented a work around which depends upon the fact that the Network Agent patch "D" fixes the issue of waking up a machine using WOL and having it shut down again if it was powered off, but NOT if it was already powered on - at least I'm assuming the agent patch "D" fixes that. I have now set all the desktop machines two do a single daily full scan at 00:15, being woken up via WOL and then shut down again afterwards. However this is just a workaround. I'll have gather more data as a test machine becomes available. Aplogies for the low resolution of the screen shots. I had to resize them to make them fit under the 300K upload limit.
  8. Hi - didn't work. It STILL auto-upgraded to MR2. I used kavremvr to uninstall KES and KLNA, created a Test Group under Managed Computers and added it as an exclusion on ALL tasks. I then created two new update tasks and two new virus scan tasks just for the test group - one of each for MR2 and one of each for NON MR2. I ensured BOTH update tasks (MR2 and non-MR2) had the tick in Update Application Modules removed. I then used KSC to install 10.2.2.10535 to the machine and place it into the test group at the end of installation. That worked ok. Two hours later the PC was showing the yellow triangle on the Kasperky icon in the notification area saying the PC needed to be restarted and it was now showing the version as 10.2.4.674 MR2. How do I stop it???
  9. Hi Nikolay, I was about to say I'd tried that and it didn't work, but when I double checked I found I'd unticked it in the wrong update task. Just removing KES (again!) using the removal tool. I'll update you once it has 10.2.2.10535 installed again. If it stays on 10.2.2.10535 I'll do some scans for comparison.
  10. Both task settings are the same - essentially the default apart from File Type which I've tried on all three settings, All, Files Scanned by Format and Files Scanned by Extension. I've also tried (with MR2) setting Scan only new and changed files - no difference. I NEVER approved the upgrade to MR2, it just got pushed out. Where do I approve it as I've never seen any approval request? Now I cannot find any way to STOP a endpoint being upgraded. How on earth to I block endpoints being auto-upgraded to MR2. This is now becomming a serious issue. When MR2 was first pushed out without any authorisation I lost control the endpoints which stopped doing regular updates and scans. Only when investigating that did I find that MR2 actually required a new admin plugin AND new policies and tasks to be created. Now I have control of them and the scan time on most of them has drastically increased and the performance of them drops unacceptably during the scan. Reminds me of the fiasco a year or two ago with the auto-update that crippled thousands of endpoints - wich I also got hit by.
  11. I can't compare the older scan task to the newer as I no longer have any endpoints running the older version of KES and the older scan tasks do not work with MR2. I cannot "rollback" any of the endpoints to the older version to compare unless I can disable the auto-upgrade to 10.2.4.674, otherwise on the first update they upgrade back to .674. So what is the easiest way of disabling the auto-upgrade to .674?
  12. Well I've tried uninstalling KES using Kavremvr and re-installing 10.2.4.674 MR2 using a installation package rather than starting with the original KES 10.2.2.10535 and letting it auto-upgrade. No difference. The scheduled on-demand scan still took 1 hour 4 mins on a new build machine. What is the simplest way, if I uninstall KES1.2.674 MR2 from this machine and re-install 10.2.2.10535, of preventing it auto-upgrading to MR so that I can do a comparative scan? That is the only way I can provide concrete comparative data since ALL endpoints were auto-upgraded to MR2, The first I knew was when they all needed rebooting after the upgrade. It was shortly after that when I realised KSC could no longer be used to manage them: https://forum.kaspersky.com/index.php?showtopic=347757 without a lot of, what seems, pointless installing of additional management plugins and creating new policies etc.
  13. There is one relatively simple thing I could try. I've yet to download the full installation package for KES 10.2.4.674 MR2 and create a remote install package from it. It might be worth doing that then using KavRemover to uninstall KES and KLNA from the newest machine (9ZFCCC2) and then re-install it using the remote install package rather than from the original .424 and upadate to 674 MR2. This might eliminate the possibility that the process of upgrading through 434 to 674 MR2 might itself have caused the protrated scan times. That will be relatively quick to try.
  14. That is going to be rather difficult, not mention very time consuming for me, as all my endpoints have auto-upgraded to MR2. To get useful comparison results I would have to: 1. Find a way of disabling upgrading to MR2. How do I do this as I did NOTHING to enable it? 2. Rebuild the newest machine, before it goes into regular use, back to it's factory image then build it up to it's base build. 3. Install KES using the standard install package. 4. Let it auto-upgrade to MR1 (yes that was also done via auto-upgrade with me doing anything). 5. Let it perform several scheduled scans using the same settings as currently used for MR2. 6. Re-enable MR2 auto-upgrade and let it upgrade to MR2. 7. Let it do several more scheduled scans This I think is something Kaspersky are in a far better position to do in their lab. It is that or I go through the hassle of disabling the MR2 auto-upgrade permanently, ripping out MR2 from all the endpoints and re-installing up to MR1 and ignoring MR2, forever. MR2 so far has been nothing but hassle. Why on earth did it require completely new policies and tasks? It should NEVER have been an auto-upgrade for that alone as it caused all my endpoint to become unmanageable until I found that MR2 dumped all the existing tasks and policies, AND needed a new management plug-in.
  15. Hi, Well that made no difference. They are all essentially taking the same length of time as when set to scan by file format. What is really puzzling is the significant differences I am seeing - screen shot attached. All bar 5 PCs (and the servers) are 3.3/3.4GHz i3/i5 machines (Dell Optiplex 3020 or higher) running Windows 7 64-bit with minimum of 8GB of RAM all with a standard base build. The three quickest are at a remote location at the far end of a VPN tunnel. One of the slowest (9ZFCCC2) is a brand new machine (i5 gen 6) with nothing but the base build on and it is on the same gigabit network, on the same site, as the admin server. A slightly older machine, 6TBLPZ1, is an i3 machine with the same build and yet that is three times quicker. Even an old XP machine with a lot more installed on it, D12BZ1J, is over twice as fast yet is a far lower specification machine. When they were running MR1 the scan times showed far less variation and were typically 15-20 mins.
  16. Thanks I'll have a read through. As an experiment I've changed the scan settings of the type of objectsd/files to scan from "Format" to "Extension". On the default setting of "All" scans took even longer. I doubt that significant changes occurred to almost all of our endpoints at the same time as MR2 was installed (by automatic update) to make such a dramatic increase in scan time. I'll let you know how the test goes.
  17. Hi, When all of our endpoints where on the MR1 release of KES 10 the scheduled on-demand virus scan (normally at 12pm and 12:00am) would typically take 15 mins using the default scan settings. Since they auto-upgraded to MR2 most take considerably longer. Two or three still do it in 15 or so minutes, most of the rest are anywhere from 40 mins to well over an hour, and that is AFTER changing the default scan settings to "By format". I did also install patch D into KSC (1.0.2.434) and also on all the endpoints network agents, installed the MR2 plug-in for KSC and created new policies and tasks. Has something changed with MR2 which could produce these considerably extended scan times?
  18. Hi Artem, If this is the expected behaviour then I actually like it! It makes more sense to me for PCs to shutdown again if WOL has caused them to power up. I just could not get that to work before without it also shutting down PCs which were already on. We have some PCs which run spectrometers and prefer to be able to shut those down at the end of the day but still have them wake up for overnight updates and scans. I'll do some more testing as I shut down four machines as a test last night and three woke up for the 11pm updates then shut down, then woke up again for the 12:00am (midnight) virus scan then shut back down again. The fourth remained powered up for some reason Best regards George
  19. Forgot to mention, at the moment I am seeing this on the KES 10 SP1 MR2 Update task. I noticed it because two machines were shut down when I checked about 7pm last night. This morning they were still shut down but were both showing as having run the 11pm scheduled update task but DID NOT run the 12am Virus Scan task one hour later. The only way that could happen is if they had woken up, ran the update, then shut down again. They wouldn't have run the Virus Scan as that was not, at the time, configured to activate computers using WOL since in the past it hadn't been necessary. I'm still very concerned about the very much extended virus scan times using the default settings with MR2. Machines which would typically complete a scan in 5-10 minutes (prior to MR2 and Patch D, again using the default settings) are taking anything from 40+ minutes to over an hour. One machine is still running after 2 hours!
  20. Hi, Not quite. The behaviour I am seeing with KES MR2 and KLNA Patch D is as follows: If a machine is already ON and a scheduled task runs which has "Activate computer before task is started via WOL" selected, but NOT "Turn off computer after task is complete", the task runs and the PC stays ON. If a machine is OFF and a scheduled task runs which has the above WOL options selected, the PC switches on, runs the task then appears to shut down again. Prior to MR2 and Patch D the behaviour was as follows: If a machine is already on and a scheduled task runs which has "Activate computer before task is started via WOL" selected, but NOT "Turn off computer after task is complete", the task runs and the PC stays ON. If a machine is OFF and a scheduled task runs which has the above WOL options selected, the PC switches on, runs the task and STAYS ON. Having said that the "Turn off computer after task is completed" was not a great deal of use. The behaviour with this option selected IN ADDITION to WOL prior to MR2 and Patch 2, was that after the task is completed the PC would be shut down irrespective of whether it was on or off prior to being sent WOL. This would cause it to shut down while in use by the user. Regards George
  21. Hi Nikolay, Well I installed the MR2 plugin into KSC then installed the Administration Server Security Centre patch D. I then deployed the endpoint network agent patch D to all of the endpoints via KSC. I then created new policies and tasks for the endpoints using the MR2 specific tasks that the plugin provides. I took the opportunity of the UK Bank Holiday on Monday to do this. So far everything seems to be working again in that endpoint Update and Virus Scan scheduled tasks now run at the correct times (every 12 hours at 11:00 and 12:00 respectively) using their correct settings, although the virus scan on the endpoints seems to take rather longer under MR2 than it did under MR1 using the same settings. I can also now browse to a computer under Managed Computers in KSC, open it's properties and manually trigger the Update and Virus Scan tasks again - presumably because MR2 compatible tasks now exist. One other thing I've noticed is a difference in the behaviour of WOL. The scheduled update task for our desktop machines is set to wake them up using WOL, but NOT shut them down again afterwards. In the past they have always remained on after the update was complete irrespective of whether they were on or off when WOL was sent and so have happily performed the midnight virus scan 1 hour after their 11pm update. Now if a machine is OFF when WOL is sent it appears to be shut down again afterwards even though I DO NOT have "shutdown after task is complete" ticked. Is this a change in behaviour? I've had to add WOL to the virus scan task as well to ensure the midnight scan is done (awaiting verification of this). This new behaviour I quite like, if you can verify it has been changed, as I always had a problem with the "shutdown after task is complete" option. If I had that ticked as well as WOL then ALL machines would be be shutdown after the task is finished even if they were already powered on when WOL was sent. When I tested this in the past it resulted in users' PCs suddenly being shut down after their 11:00am update in the middle of users working! Not very useful. I've also checked both the Administration Server Download Updates to Repository and the endpoint Update tasks and they are both set to the default Auto Detect Update List. I'm not sure then how my endpoints did an auto-upgrade to KES SP1 MR2 when others have not had this work - although I should say they also did an auto upgrade to KES SP1 MR1 when that came out. In fact if I do a standard install of KES via KSC "Install Application" to a new PC it gets KES, then a short while later is upgraded to MR1 (now MR2). Regards George
  22. I'll have to check that. I did a complete re-install of KSC and all the endpoints back in December when I migrated all of the PCs across from our old internal domain and servers (SBS2003 and 2003 standard) across to our brand new Server 2012 virtual servers. As far as I can remember I left all the settings at default for everything bar the main endpoint policies and tasks. Regards George
  23. Ok. So what you are saying is that now that the endpoints have auto-upgraded to KES 10.2.4.674 (mr2) I have to scrap the existing policies and tasks, create new ones, AND install the appropriate plug-in? Is that correct? Presumably this is in addition to installing the patch D version of KSC 10.2..434 (or installing the patch itself)?
  24. I guess this is patch "D" which KSC and the network agents are missing? If so where can I find the information on installation of patch D please?
×
×
  • 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.