Jump to content


  • Content Count

  • Joined

  • Last visited

About ICG

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, the topic can be marked as solved.
  2. The new key was added with the method shown and once the previous key expired the new one was automatically set as the active key. Our endpoints have reflected the change when we sampled a few of them directly and checked their status from KSC. Thanks again for the assistance.
  3. Thanks for the information. We'll make that change and that will solve our issue.
  4. We have renewed our license and added the new key files to our KSC server. Our current keys are active for a week and a half before their listed end date. Is there any best practice on how to deploy the new key while some time is left on the current one? We searched the support articles and the forum and didn't find anything unless we overlooked it. We weren't sure if the new keys would be automatically used once the end date of the current keys passed or if we needed to initiate the task to Deploy key to managed devices before the expiration time to prevent downtime.
  5. Thanks! That was the information we needed and we will pass it along to the vendor.
  6. We have a vendor that they believe their program is encountering issues with KES and specifically the anti-crypto settings. In going over the exclusions with the we started to check for any information to give them from Kaspersky Lab regarding best practices or whitelisting and found the Whitelist Partner Program. Is that the correct information to pass along to them so that they can submit their software to have it whitelisted at the KL level or is there another location or documents we could direct them to? We have worked with support previously on adding the program to Trusted Applications and inventory scans for use with Application Privilege Control and it appears to be setup correctly from our side with KSC/KES so we wanted to see if there is a way for the vendor to submit it if that would help. KSC SP3 10.5.1781.0 KES 10 SP2 MR2
  7. Uninstalled the MR4 beta and network traffic starting working again including Network Agent. Installed MR3 from KSC and computer behaved normally without loss of network traffic. Ran GSI tool with MR3 installed and results are here Uninstalled MR3 and installed MR4 beta via standalone installer. Verified that network connectivity was functioning prior to the installation while Network Agent was still installed. Once MR4 installation had finished the computer lost network connectivity again. Stopping individual components didn't allow network connectivity. Shutting down KES MR4 didn't allow connectivity either. GSI results with MR4 installed are here Once MR4 was uninstalled leaving just the Network Agent installed connectivity resumed. Can reinstall KES MR3 and/or MR4 if needed to run traces from within KES too or for other testing. The Network Agent version during all of these tests was 10.4.343
  8. Reporting a successful installation on a Microsoft Surface Pro 4 running Windows 10 version 1703. Installed via the distribution package after uninstalled MR3 from the system to prep. Was able to create/start tasks from KSC on this endpoint. Tested with Network Agent 10.3.407 (a; and 10.4.343. Used both versions to troubleshoot apparent issues with either KES MR4 or Network Agent compatibility with Netmotion Mobility 11.02 Have adjusted beta policy to allow endpoint control and will test with disabled components and settings to see if something is being blocked inadvertently since we have MR3 running alongside that same version of Netmotion and there aren't any issues. All network traffic is blocked once the Endpoint is installed and running. It was functioning normally prior to the installation of KES MR4. The Network Agent gives an error of #1259 Transport level error: connection terminated.. Will test with sections of the endpoint disabled to see if that is the cause and also check against MR3 to see if it is specific to MR4 beta.
  9. Updated KSC to 10.4.343 and beta workstation Network Agent to 10.4.343. Previously had NA 10.3.407a installed. MR4 Beta still running normally and able to complete all tasks with new Network Agent when manually started via KSC.
  10. You have to match the text exactly to the way Microsoft has it listed. For example if it has a comma after April as in the attached screenshot then you have to put that comma there or the search won't return any results. If you can pull them up in the Microsoft download catalogue then you can use that as a reference for the names and if you get any blank results just go back a character until you get results and can find what the search doesn't like. That's how I did it to check for them last week. Edit: Whoops forgot that you asked about how to set them up. After you find them in the list you will need to select the specific patch and then you have an option to either install update (create task) or install update (modify existing task) and from there it will be like setting up other tasks in KSC. You can reference the target computer list too if needed for specific computers.
  11. Reporting a successful installation and usage of the beta software via the distribution package. PC is Windows 10 Version 1703. Previously had MR3 installed on it and that was uninstalled and then MR4 was successfully installed. Able to manage it successfully from KSC for tasks and policies. Early testing has been fine but only had time for an hour worth today. Was able to access Windows Store which previously required pf1794.
  12. Strangely enough the issue did still occur when it was tested with APC disabled but I question if it was a valid test after what I found out below. Went back through all of the executable files for the application and checked what was in the list that had been added to the Trusted group and found that the application had two entries. After checking other applications with multiple entries and verifying that they were each a different version and showed up multiple times in the Advanced>Application management>Executable files area we checked the two entries for the problem application and realized that something must be wrong with them. One of the entries had the correct information that matched the executable files entry such as first run date while the other one just had blank spots for all of the areas. Upon deleting the "bad" entry and allowing the policy to update they were able to export a report to a .xls file successfully. Had them test multiple times to be sure (45 minutes and 10 hours apart) and it is still working. Issue can be marked as resolved. Seems that we did have the correct process after all and that there was a "bad" entry in the trusted list that must've been leftover from when we added them for application installation.
  13. Tested with each of those changes individually. Disabled Application Privilege Control module on that PC via KSC and the error still occurred. Added the application process to the trusted group under scan exclusions along with the option to "not monitor child application processes" but the error still occurred. We also had the application folder already in that group with the %foldername setting and the child application option was added to it too.
  14. We have the cryptovirus protection enabled as outlined here and have encountered an application that we want to allow to access protected file types but we can't find which process to add to the trusted group. We have added the main executable as launched by the application and this is also the one that shows up in Process Explorer when it is run and selected with the target tool. Yet when we go to export a report from the application via Crystal Reports (not a stand-alone installation but seems to be embedded inside of it) it gives an access denied error when attempting to write/create an .xls file which is one of our selected file types to protect. We have attempted to add all of the executables in the application folder to the trusted group as a "blanket test" but KSC seems to only allow some specific applications. We have disabled KES and the .xls file can be created so it appears that the policy is blocking it. We didn't see any other processes show up via Task Manager or Process Explorer when running the export and that was tried with KES active and disabled. Here is the link to the process from Kaspersky Application Advisor Are there any other ways to determine which executable is attempting to work with a protected file type so that it can be placed in the correct group? We noticed that there is an option to log events which is enabled on the Protected Resources section for the 3 other categories besides the Trusted category but we can't find where these logs would be located. Looking in the main KSC logs we only see where we enabled/disabled KES on the PC. KSC 10.3.407 SP 2 patch a Endpoint version is: KES 10 SP1 MR2
  15. Apologies but we're not sure what your response means. Is this directing us to a known issue with that number or that the issue has been assigned that number? We did some searching and couldn't find any reference to that in the list of known issues (if that is what it was meant to be). Not meant to sound dumb but just checking in case we needed to follow up on anything.
  • 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.