Jump to content

DavidW

Members
  • Content Count

    12
  • Joined

  • Last visited

About DavidW

  • Rank
    Candidate
  1. I tried the MS SQL script on my server, which got me further into the upgrade process. However, it didn't fix the root cause which, as with NoSurf, was that the compatibility mode was set to SQL Server 2000. I changed this to SQL Server 2008 manually, then restarted the Administration Server, which allowed the upgrade process to complete successfully.
  2. As has been said: KES 10 SP1 MR3 appears to be bug fixes and Windows 10 Anniversary Update compatibility changes only, with no intentional user visible changes in the user interface or product name. The version number gives an unambiguous indication of whether SP1 MR3 is installed. The good news is that the unchanged product name means that KES 10 SP1 MR2 policies and tasks continue to work.
  3. I feel for both sides in this issue. You are always going to have potential compatibility issues when you have two applications hooking into the network stack, such as VPN client and an endpoint security product like KES. Serious suggestion: is there any reason you cannot move, in the longer term, to using IKEv2/MOBIKE with the client built in to Windows? MOBIKE addresses the major problem with IPsec identified in NetMotion's own white paper - without MOBIKE, a disconnect occurs when an endpoint changes IP address. Compression is possible using IPsec. I have no problems using Windows 10's own VPN client against the IKEv2 endpoint in the open-source pfSense firewall. The total cost of deployment in production was my time plus the hardware that runs pfSense. MOBIKE works well. The only problem I have, which is common to pretty much all non-Windows IKEv2 servers, is that IPv6 routes are not established by the client. This is easily sorted by adding a static route to the connection in Windows using the Add-VpnConnectionRoute PowerShell cmdlet. If you wish to experiment, you can always fire up pfSense in a VM. Obviously, if you need FIPS certification or similar, your options for the server end are restricted and you may not be able to use an open source product. Even so, there has to be an alternative to proprietary VPN technologies.
  4. You've posted in a thread about a very old version. Endpoint Security 10 Service Pack 1 Maintenance Release 3 (10.2.5.3201) has been released in the last couple of days. If you are still on 10.2.1.23 (Endpoint Security 10 Maintenance Release 1 - the first maintenance release of the 'Service Pack 0' version), I suggest you upgrade before doing anything else.
  5. There's nothing unfortunate about it. Microsoft have been clear about the release date for some time, the final build has been available for several weeks via Windows Insider, and Kaspersky has likely had access to near final builds for some time before that. At best, Kaspersky planned to have something available for the release date (2 August 2016) but found they were unable to ship anything on that date. It is possible that there was never sufficient resources available at Kaspersky to have a release available on 2 August 2016. There was a beta that finished testing on 29 July 2016 that had Anniversary Update support - I have the binary that I might try in a virtual machine for testing purposes, but I wouldn't be surprised if it only works with now-expired beta keys. In my opinion, there really should be a clear banner statement across the support site that says "Kaspersky Endpoint Security does not currently support Windows 10 Anniversary Update. Estimated date for a new version, 15 August 2016". This is likely to be a FAQ very soon, and it's really not good enough that this information is hidden away in a somewhat cryptically titled forum thread. Renaming this thread "Windows 10 Anniversary Update (Windows 10 Version 1607): No support until KES 10 SP1 MR3 (not yet released)" and pinning the thread would be a start. I've been on the 'other side' as a software engineer. I know that proper QA and release procedures take time, and that it is ultimately better to ship something that works rather than something that has issues. However, Kaspersky has repeatedly failed to keep up with support for the released version of Windows in its premium priced business anti-virus line. There was a huge delay before Endpoint Security 10 supported the original version of Windows 10. There was another delay in November when Windows 10 Version 1511 was shipped. Now there's another delay for support for Windows 10 Version 1607 support. In the days of Windows releases with huge changes, businesses often opted for a conservative approach, especially as acceptable reliability and performance often required a total reinstall, also there were numerous software compatibility issues with each upgrade. Many businesses stuck with XP and never deployed Vista. Many businesses stuck with 7 and ignored 8 and 8.1 - some of these are still deploying 7. Things changed with the release of Windows 10 - smaller incremental releases are the norm, and each release has a life measured in months. Kaspersky catching up weeks after the release date might be 5-10% of the release lifetime! I don't think I'm alone in wanting Kaspersky to review their repeated failures to support Windows releases on release day in their business products, then make a clear statement about their support policy. If this doesn't happen, I will join those looking elsewhere when my current licence expires.
  6. What you say rings true for me. MP4 paralyses machines that ran perfectly adequately with MP3 - especially older machines that are inevitably much slower than the latest hardware. MP4 is much more bearable on newer hardware. I have pulled back MP4 from my network today. On one workstation, it was taking 20 seconds plus to open a new tab in Internet Explorer 8 with MP4 installed. This returned to under a second once MP3 was reinstalled. As you say, the slow down isn't in avp.exe and it doesn't depend which options you have selected. Stopping all AV functions doesn't restore performance as you would expect. Whilst I haven't had an opportunity to test unhooking klif.sys from the registry, it would make sense for the problem to be in a low level driver such as this - I recall how problems in klif.sys have caused mayhem in the past (with one faulty MP3 update interacting with Diskeeper). Overall, MP4 looks very good, but this issue makes it unusable for me and I'm a little sad that it wasn't picked up during testing. I'll leave it in Administration Kit ready to deploy again later on, after Kaspersky have had chance to fix this problem. As I'm intending to replace my current machines with new hardware running Windows 7, I'm going to need MP4 eventually. Ironically, all this comes a few days after I renewed my licences for two years. Though it's OT here, that went horribly wrong, with Digital River sending me an activation code that had already been used by someone else then, when I complained, they did the same thing again! I had to call tech support to secure an emergency 30 day licence until they had had time to investigate, after which they emailed me permanent key files.
  7. This contains a klif.sys for Kaspersky AntiVirus for Windows Workstations 6 that is hardly different to the version causing problems - this is 6.12.10.328 as opposed to 6.12.10.327 from the 'regular' update servers. There are so few bytes differing that I wonder if there's any meaningful code differences. Somewhat in desperation, I switched my Administration Kit over to this update source - and I didn't finish up with a klif.sys update on a Windows XP Professional SP2 machine running WKS 6.0.3.837. With no benefit in sight, I've switched my Administration Kit back to the main update servers in the mean time. At most, this seems to be one build further on. Any more ideas?
  8. See this thread (click) where I've posted a summary of my conversation with a Kaspersky UK rep about the same issues. Indeed, there seem to be several threads on this forum now talking about these issues.
  9. I spoke to Kaspersky UK support this morning. As well as the issue sleepytom posted about here, there is a second known issue relating to last week's modules update. This one affects users with "certain defragmentation products" - which definitely means certain versions of Diskeeper, especially more recent ones. In my environment, Diskeeper versions 9, 12 (2008) and 13 (2009) were causing problems, whilst version 8 didn't seem to be. I don't believe there's other interacting defragmentation products - in my case it was definitely Diskeeper. If you have any of this interacting software, you have probably been having serious trouble since the middle of last week - I had one Windows XP Professional SP2 system that wouldn't start reliably even in Safe Mode, which, unfortunately, was my personal workstation. This work-round is worth trying - not least as it is so simple. The work round is to add the Diskeeper service to the Trusted Zone in Kaspersky - "Program Files\Diskeeper Corporation\Diskeeper\DkService.exe" (without the quotes) should work for recent versions of Diskeeper, though check your particular environment. In a push - or if you are trying to fix a machine as quickly as possible after boot before it freezes or crashes, I'd use "DkService.exe" to start with - though, from a precautionary point of view, I try to keep things in the Trusted Zone as tight as possible. If, like most people, you only ever install Diskeeper on C:, you could try "C:\Program Files\Diskeeper Corporation\Diskeeper\DkService.exe" (without the quotes). Whichever option you choose, you want no verdict mask set - so uncheck the Verdict box. You can deploy this as a policy from Administration Kit - though for that to be effective, you have to deploy this in such a way as to overwrite the existing Trusted Zone settings. Clearly you do not want to do this if users require customised Trusted Zone settings that are not reflected in your policy. I had a chat with the guy about Quality Assurance and reversion mechanisms. I suggested that thought should be given to an easy way to revert the last two or three application module updates from Administration Kit and from the application user interface on workstations. Looking in the Updates section of Administration Kit, older builds of klif.sys are in the repository - there's just no way to push them out to the machines on the network. Another suggestion I made is consideration being given to making available the previous build of the application modules with a higher version number. This could be done either when an incident like this occurs as a temporary work-round, or on a separate reversion update server as routine policy. If a reversion update server is made available, Kaspersky could monitor its usage to see if there's a potential issue - though I recognise that large affected sites may only register a handful of downloads because they distribute updates around their network from their own Administration Kit machines, also that cautious admins may routinely run on the reversion server, degrading their protection and reducing the field exposure of the latest code. He believes that Kaspersky's developers are listening to such requests - like others, this isn't the first problem I've had of this sort leading to lost work days where computers are unusable. Having such reversion capabilities, as well as greater depth in Quality Assurance testing, will leave me more favourably disposed to Kaspersky come renewal time. Some sort of discount for those who have been affected by these issues wouldn't go amiss, either. Finally, I suggested that the Kaspersky web site should clearly indicate when there's an ongoing issue such as this - it shouldn't need you to trawl through the forums to find the necessary information on the second page of a thread that started about something else entirely. The "Diskeeper" work round has been effective enough for me to post this message from the machine that wouldn't start reliably even in Safe Mode.
  10. Absolute disaster - all my Windows workstations are effectively dead. I have intermittent network connectivity on this one in between Kaspersky restarting. I've wasted time trying to upgrade from .830 to .837, I totally ripped Kaspersky out of one machine, put it back in - and as soon as it tried to grab the 'differential' update, it was dead again. I had urgent work to do this evening, and Kaspersky has wiped me out. For the cost of the licence, this is not impressive, and like others have said, it will be borne in mind come renewal time. Some gesture of goodwill from Kaspersky over licence duration / renewal costs would be greatly appreciated - though the most important thing is to fix it quickly. It's really poor QA and disaster recovery that we've been in this mess now for something like three hours. It's even worse that when this happens, you can't roll back. David
  11. I'm on the verge of giving up with Kaspersky Anti-Virus for Windows Workstations 6 - or at least reinstalling without the Anti-Hacker component, which I think is to blame for this. I will contact technical support as this is a released product, but I won't get round to that for a few days. The machine that's playing up is a Windows XP Professional SP2 box, so far the only one of my machines that I've deployed to (the rest are still on 5.0.712). The only odd thing with the network setup is that the machine is connected to three different VLANs using Intel PROSet 12.0.36.0, which is the latest version of the driver bundle from Intel (the driver for the 1000MT Server adapter is version 8.8.1.0). Kaspersky Anti-Virus NDIS Filter is attached to the three VLAN adapters and not the parent (which is what I'd expect). Following other forum posts, I not only ensured that Windows Firewall was switched off (it was), but disabled the Windows Firewall/Internet Connect Sharing (ICS) service. The tendency to explode is less if the firewall is turned off and just the Intrusion Detection Service is left enabled - but the machine crashed overnight (STOP 0xD1 in tcpip.sys yet again) in that configuration whilst backing up. Fortunately the network is behind a hardware firewall, so this is no disaster. I gather that WKS 6.0.2.678 tends not to like machines with Intel PROSet Wireless - does it also not like machines with the wired version of PROSet? Are there any changes in configuration that forum members would recommend, and is there anything I can do to help Kaspersky debug this problem? I did have the machine set to capture mini-dumps on STOP errors, but have now configured it to capture complete dumps as Kaspersky ask for in http://support.kaspersky.com/faq/?qid=193238549 and will endeavour to send in a ZIPped dump the next time it happens. This may be tricky, as my swap file configuration isn't conducive to this necessarily working <sigh>. David
×
×
  • 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.