Jump to content


  • Content Count

  • Joined

  • Last visited

About tom@reeleezee.nl

  • Rank

Recent Profile Visitors

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

  1. on our servers the registrykey also appeared overnight, so all computers are now ready for the microsoft updates
  2. all our PC's are running windows 10 (build 1703 or 1709) and KES and databases version 01/04/2018 13:06 servers are running Kaspersky Security 10 for windows server
  3. At this moment I see in our environment al windows 10 client PC's using KES 10 have both, the (invalid)key cadca5fe-87d3-4b96-b7fb-a231484277cc AND the (right) value cadca5fe-87d3-4b96-b7fb-a231484277cc these PC's get Microsoft 2018-01 cumulative update but, all our servers (Windows 2012 R2 with Security 10 for windows server) have the (invalid key cadca5fe-87d3-4b96-b7fb-a231484277cc BUT NOT the value cadca5fe-87d3-4b96-b7fb-a231484277cc and do not get the updates
  4. Hi Konstatin, adding an application to the trusted application helps for the particular build of the applications, but because our developers a creating new versions of these executables every day it is not workable to add all those versions. that's why we tries to solve this issue by signing these executables with out own signing certificate Kind Regards, Tom
  5. please download the traces here : https://we.tl/q0Ualahlwt Kin regards, Tom
  6. in the computer certificate store, in the folder Trusted Publishers
  7. Hi Ivan, I do not understand what you mean, can you be more specific? I have imported our code signing certificate in the trusted publishers folder in de certificate store of the computer certificate store (using she certificates MMC), but this does not seem to help. Thanks
  8. Hi, We are a software company and we sometimes create are own tools (and because we make them ourselves we trust these tools) on our endpoints we use KES 10 ( including the application privilege control feature. this application privilege control feature always seems to rate our self-mede executable to te low-restricted Group. Event type: Application placed in restricted group Application\Name: SigningService Application\Path: C:\Program Files (x86)\SBR Assurance\ Application\Process ID: 28264 User: REELEEZEE\tregeer (Active user) Component: Application Privilege Control Result\Threat level: Low Result\Precision: Exactly Action: Application placed in group Object: Low Restricted Object\Type: Application group Object\Name: Low Restricted Reason: Heuristically calculated threat level as we also block programs in the low-restricted group access to essential files (as advised for protection against ransome-ware by Kaspersky) this often leads to unwanted issues To prevent this we have bought a code signing certificate (at Comodo) and sign our executables with this certificate. As the setting "Trust application that have a digital signature" is used in out policy I would expect the executables to be trusted, but this stil is not the case. can you please advice how to trust out own executables? Kind regards, Tom
  9. After a reboot of the server the issue still does not show up again, so i think patch 19 solves the issue. We will now deploy this patch to all our other servers
  10. I have installed the patch this morning on 2 servers showing the problem. Until now both servers stopped showing this issue, but i'm really convinced when the issue does not return after a reboot. I have scheduled a reboot for 1 of the servers tomorrow morning, so I will let you know the final verdict tomorrow Kind regards, Tom
  11. Hi Sean, The servers showing the problem do not have hyperV or hyperV switches installed all servers showing are physical server, with just Windows 2012 Server R2 and SQl server installed Regards
  12. Hi Sean, Thanks for the update i'm also still working on my incident (INC000008281547 ) with Kaspersky support. I hope they will have an solution soon. Kind regards, Tom
  13. Hi Sean,All our servers are server 2012 R2 We also use teams on al our network interface (microsoft teaming) the 720xD (not showing the problem) al use Broadcomm Netextreme 5720 the 730XD's we have in 2 different NIC configurations (switched from broadcom to intel last year for new servers), both versions show the issue Broadcomm Netextreme 5720 Intel Gigabit X520/i350 Look at this, i would conclude the NIC is not the issue I'm stil able to reproduce switching on trace logging will stop the issue, also after stopping tracelog a reboot will enable the problem again
  14. Hi, I noticed 1 remarkable fact, maybe it’s not important, but I want to shared it. We have 16 database server in production, configured exactly the same way (installed from an image). Half of the server are Dell PowerEdge 720xd hardware, the other half of the servers are Dell PowerEdge 730xd hardware (newer generation). All 730xd servers seem to have this issue but I haven’t seen de issue on any of the 720xd servers. @uk-heliman : Are you seeing this issue on a particular type of hardware?
  • 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.