Jump to content


  • Content Count

  • Joined

  • Last visited

About fdt93

  • Rank

Recent Profile Visitors

157 profile views
  1. I have a strange issue with one of my KAV clients. This is a Windows 7 Pro(x86) client that had some other issues before I started working on it. A system restore was done and KAV 6 was uninstalled (using control panel). I fixed the issues Windows had and verified it was up to date, then I pushed KAV and the agent from KSC 9.2.69. It installed successfully and rebooted. I then ran the update task. I rebooted after the update completed. Now, however the client reports that the databases are dated 9/22/12. You see this when you mouse over the KAV system tray Icon. When you open the KAV console on the client and click Support, the System info section shows: Application version: Databases release date: 9/22/2012 5:46:00 AM Kaspersky Administration Server: <shows correct host name of KSC server> Last synchronization date: 3/21/2013 9:45:29 AM Operating system: Microsoft Windows 7 Service Pack 1 (build 7601) If I perform an update, it will connect to the admin server, check the file list, then say no update is necessary. In KSC, I open the properties for the client and the General tab shows today's date for Last update. On the applications tab, I go into the properties for KAV 6.0 and the General tab shows today's date for Last software update. The Application database, however shows a database date of 9/22/2012. Yet, Last update is today's date with the number of anti-virus records at 7863148. How do I get the client to reflect the correct database release date?
  2. And here are the other two smaller log files. klserver_logs.zip
  3. I attached the log file. The file was still over the 300k attachment limit using standard zip. (The original log file is ~7MB) So, I had to use 7zip to get better compression. I also opened a support case and I have provided the requested GSI link in the support case. I tried attaching the log file to the original support case, but the browser timed out when I hit submit. So, I created the case without the log file attachment. Support case is: INC000000260059 _klserver_install_2012_01_31_08_31_12.7z
  4. One thing that might help troubleshooting this is changing the event properties in the protection policy. Edit the policy and go to Events. For each of the Critical Events that have to do with protective actions taken by KES (Blocked, Network Attack detected, etc.) put a check in the box for "In the event log on client computer" under Event Registration. That way, any actions taken by the KES client on the affected computer is logged in that computer's event log.
  5. I'm trying to upgrade KSC 9.0.2786 to KSC 9.0.2825 (CF1) When the installation process gets to "Updating Administration Server service" I get the following error popup: "Error while installing: Parameter with name "87" not exist." The Application event log has a corresponding entry with Event ID: 10005 and the description is: "Application: Kaspersky Security Center Administration Server - Error 25002. Error while installing: Parameter with name "87" not exist." This is on a Windows Server 2003 R2 Standard with Service Pack 2. Has anyone else seen this error?
  6. I have a strange issue with all of my Outlook clients. We have an Exchange 2003 Enterprise server with about 400 mailboxes. All of our users are in the USA and on a variety of systems using XP, 7 Pro 32 and 64 with a variety of Outlook clients (2003, 2007 and 2010). All of our end users are using KAV workstation 6.0.1424 and we have the Outlook addin activated. All of our users have only en-US language installed. None of our emails contain Russian fonts or characters. However, our Outlook clients are sending emails with "charset=koi8-r" Is it possible that the Kaspersky Outlook addin is causing Outlook to use the Russian charset instead of the default iso-8851? This is becoming a problem because more and more of our customers are using email filters that block emails with Russian character sets.
  7. Aha. Of course. It was right there in front of me. Thanks!
  8. For some reason, the entries I make in the trusted zone settings of a policy do not get propagated to the client. After autopatch 'F' was released I re-enabled Proactive Defense on my policy (P.D. was previously disabled due to autopatch 'D' causing our .vbs network logon script to get identified as a threat) Even though I have added the unc path to the logon script to the Exclusion rules, and added the script itself (with full path) to the Trusted Applications in the policy, the client still blocked the script from running. P.D. still identified it as input/output redirection. I unchecked Input/Output Redirection in the P.D. settings on the policy, and the logon script is able to run. Which shows that the policy successfully applied to the client. (The admin kit also reports that the policy was successfully applied) But, none of the Trusted Zone settings from the policy show up in the client settings. I shouldn't have to disable that part of P.D. if the Trusted Zone is set up properly. But, for that to work, the Trusted Zone settings in the policy need to actually make it to the client. Has anyone else encountered this before? The client is running KAV (d.f) on Windows 7 SP1 x64 with the 8.0.2134 network agent. Thanks, Jason
  9. Ok, I think I found the official response: Auto Patch D issues
  10. We have been having similar problems with Proactive Defense on KAV Workstation MP4. Our problems center primarily around the login script on our Active Directory domain. We use a .vbs based script to map network drives for our users. Starting early last week, Proactive Defense began terminating the login script for the following reason "Process is trying to redirect data input/output. Probably it is attempt of remote access to your computer (RootShell)" "No problem" I thought, at first. I just added the path to the script (with trailing backslash) to the Exclusion list and expected it to work. But it continued to happen. So, I figured that maybe the people still experiencing the issue just had not received the updated policy by the time they logged in (because this was not happening for everyone). So I verified the policy applied to their machines and waited another day for their next login attempt. But, the problem continued. So, I have the following in the Trusted Zone of my policies (after adding the script to the Trusted Applications): Exclusion Rule: Object: \\domain.com\netlogon\ Threat Type: * Component: ANY Trusted Applications: Application: \\domain.com\netlogon\mapdrive.vbs Actions: All actions checked I verified that the policy has applied to the workstations in question, and I can open the Trusted Zone settings on that workstation and see these entries are present. However Proactive Defense still blocks the login script due to "input/output redirection." I even went into the settings for Proactive Defense and unchecked the "Input/Output Redirection" option and applied the resulting policy. Proactive Defense STILL blocked the login script. The only thing that works is disabling Proactive Defense. What is strange about this is that this does not happen for every user. It appears to only happen for users who have extra drives mapped based on group membership. The standard drives that are mapped for everyone get mapped, but when the script checks group membership and attempts to map one of those drives, Proactive Defense terminates the process and throws the Input/output Redirection event. It really shouldn't matter, at this point, what the script is doing if it has been added to the Trusted Zone. -JasonL
  11. This has been fixed with the help of Kaspersky tech support. We had to deselect Http SSL 443 from the monitored port list in Settings->Network->Port Settings. That was it. Once I did that, the Anyconnect client worked. Thanks Kaspersky tech support.
  12. I have not had any luck with adding the AnyConnect app to the Trusted zone list. I eventually added every exe, dll, and sys file in the AnyConnect program directory to the Trusted list with the options of do not scan open files, do not restrict application activity, and do not scan encrypted traffic. I used the full path for each item. And I verified that the policy containing the trusted items was applied to my client. I have also verified that the Scan Encrypted Connections option on the Network Settings page is not selected.
  13. I found an older related topic: SSL VPN Connection Topic I am currently experimenting with adding the AnyConnect binaries to the Trusted Zone. I'll post a reply if I find something that works. JasonL
  14. Actually, my guess was wrong. I just duplicated the problem on an XP machine with KAV I guess I need to go over our protection policy to see what may be enabled that is blocking the vpn connection attempts. I can't find anything in the Kaspersky log files suggesting it was blocking anything. JasonL
  • 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.