After recent rounds of patching to our kaseya server, it appears that there is an issue where the virus definitions on the VSA no longer record the correct definition date and are reporting that certain endpoints are no longer up to date with their definitions.
I have a ticket open with Kaseya at the moment and they have acknowledged that this is a known issue and they are hoping to have it resolved by the end of their "development sprint" that will go from September 28th to October 11th. Unfortunately I cannot wait that long and need to be able to report on if people are compliant and up to date accurately. Kaseya isn't aware of a workaround for this, but I was wondering if anyone has a way to export the current definition date on the Kaspersky Endpoint Security 10. What I am hoping to do is get the definition date exported to a custom variable. Unfortunately my google fu is not strong enough to find how to do this.
I am wondering if anyone here knows how to extract that information from the AV.
Typically, you can restart the Kaseya Agent service on the machine(s) in question, and it will update the definition in the KAV module. I have created an agent procedure to restart the service daily, and the issue has went away completely across the board. Not a fix, but a workaround until one is released. You should only need to perform the repair on machines which do not update with this method (only had to actually repair 1 device since installing KAV).
I have just noticed this as well on 9.1
I tried manually run the "get status" against the endpoint. If this didn't work, deleting the kworking\kav folder and running a repair will sometimes work.
It would be nice if Kaseya would publish "known issues" that arise so we can check to see if we are affected, so we can at least advise our clients that the KAV reporting is not accurate till Kaseya fixes the issue.
I have the same issue with three-fourths of my computers on hosted Kaseya. Deleting kworking\kav, scripts\kav and kalua.dll and then running a repair works once, in that the console shows defs updated to that date, but they don't continue to update in the console the next day. After about a week of having me try different repair variants, Kaseya support finally acknowledged that this was a bug and that they're working on a resolution. Why this suddenly happened out of the blue seems to be a mystery (and an extremely frustrating one).
Ahhh, that does seem to work. However, I'm a relative novice at Kaseya. Would you mind sharing your procedure to restart the service? Mine stops the service, then I lose connection to the machine and can't restart it.
I use a batch file with net stop && net start, and call it in a procedure, and set kaseya to not wait for completion. Its the only way around the loop.
Thank you everyone for your replies. I went with twistedtechmike's solution and it worked great so far.
JMargulies: I created a script in the past that did this. The trick to making this a procedure is to understand how the agent procedures operate. When it is scheduled it initiates the service restart the first action of a restart stops the service and the second starts it. Now while that is happening the procedure can still be running from the kserver. When the agent checks back in after the restart the kserver says, "Hey i have this job you should be running, please re-run it since i don't have a record of success or failure" the agent will run it and get stuck in a loop.
The way I work around it is to write a batch file that looks like this:
IF EXIST C:\kworking\Results.txt GOTO :EndTask
net stop (Kaseya service) > C:\kworking\Results.txt
net start (Kaseya Service) >> C:\kworking\Results.txt
I then write a procedure with four steps:
1. Download batch file
2. execute batch file
3. Pause the Procedure for 30 seconds just to give it the needed time to restart services.
4.delete the results.txt
The logic here is this: Even if the procedure loops 1 time, it can't continually restart the service if the batch file says to skip the restart since results.txt is not deleted until it passes that portion of the procedure.
Thank you so much for this! I, too (R9.1), am having the issue with KAV not displaying the definition date correctly, among other KAV issues. This procedure works like a charm!
I have been dealing with this issue since 188.8.131.52 was rolled out to fix this issue (which I did not have). 184.108.40.206 broke the update status for me. After restarting the agents, I found that going to Protection and doing a fresh Get Status will also update the database so the clients are now in sync. I created a view called "KAV Only" and display all the KAV that are on-line, and select All groups and in the filter tab select clients that are out of date. Highlight top to bottom of list and do a Get Status. Wait a few minutes and refresh my view and almost all are gone. Hopefully I won't need to do this once the real fix is rolled out!
P.S. I do have a ticket entered that is over a month old and I have been told that this issue will be fixed with the upgrade of the new KAV panel. Hope it comes sooner rather than later as this has added more to my already overloaded daily work flow.
This is still an issue a few months later. I am on 220.127.116.11. Has anyone heard any update on when this will be fixed?
TwistedTechMike's and MarcB's fixes have resolved the issue for now, so thank you for that!
We're on the pulled 18.104.22.168 patch and I see only a few instances off the KAV version not updating.However we do have some private fixes/patches in place to test behaviour at this time for KAV issues.
I know for a fact they are seriously working on known KAV bugs and have allocated extra resources to fix known issues.The KAV communication stack is being rewritten because lack of scalibility causes issues.Having thousands of KAV agents can flood a VSA to the point of communication stopping altogether.
22.214.171.124 was released today and from what I can track down a fix was released for this issue in this specific patch.
I know marcb and matts had tickets associated to the problem ticket which references the same fix in the release notes:
If the patch does not correct this problem - please let us know.
I'm on 9.2 and the problem still exists...Waiting very patiently for over three months for this to be fixed, finally and permanently!!!
I'm still waiting on the same outstanding ticket.....
Thank you very much for your patience on this.
I just checked and it is not released for v9.2 yet, however, we will be releasing a patch for it on v9.2.
Just wanted to throw this out here as an FYI.. I had issues with the service restarting from a batch file as stated above. The service would sometimes time out on shutdown and would never restart, resulting in me having to connect to another machine on the network to start the service. I put together a little PowerShell script to stop the service and wait (I used 10 mins, but can change to what ever) till it was in a Stopped state and then restart the service. This just kicked off from a batch file executed from a procedure.
$svc = Get-Service "Kaseya Service Name"
$Service = "Kaseya Service Name"
start-sleep -s 5
Nicolas, It's now 2016 and I and others have been waiting for the 9.2 patch to fix this issue. Several days ago I posted to my open ticket when is this going to be fixed. Today, Antonio wants me to jump through more hoops gathering verification that it is still a problem because in his words, "Engineering says this was fixed!", Really, you admitted on 12/10 that this has not been patched in 9.2 yet!
PLEASE EXPLAIN AND ADVISE WHEN THE DARN THING WILL BE FIXED!!!!