Patch 184.108.40.206 was just released. The following link contains the patch release information:
We're sure hoping this will solve a lot of our KAV issues, we'll give it a try this weekend....
I just ran the patch in my sandbox environment, and it didn't do a reapply schema, had to do one manually. Running the patch in our production environment in an hour and a half.
I believe this depends on the option you pick when you run k-install now.
Which option did you select?
neuvoja provided some information on this in the following post also:
Huh, I did in fact choose the first option. For some reason, I've always been doing it that way if I can remember, but I haven't noticed the issue until recently. I'm willing to attribute it to operator error, however. I'll go with the hotfix and reapply schema option in the start menu instead.
Thanks for the heads up Mr. Ponce!
I'll be installing tonight and testing/monitoring over the weekend. fingers crossed this fixes the AV issues.
We also updated over the weekend and have now been bitten by an old enemy.Message Queues for kes.service (kaspersky endpoint protection) has gone throught the roof.This should be in the hundreds, but is now around 30.000 and climbing.
This was escalated and I should get a call soon to check on our issue.I'll update if we know more.
So, just had a few minutes on the phone with support and it seems the patch deletes a temp table that was created to deal with the issue of the kes.services queue growing out of control.
The queue has now been created again and a stored procedure on our VSA should run every 15 minutes to keep this under control. Still wondering what was done back in November\December when this exact same issue was solved and it didn't come back with patch 220.127.116.11...
In an hour or so results should be visible and I'll report this then.
Any updates to this? I'm planning to do the updating on wednesday.
I reached out to support to see what I would have to do "Post Patch" for this Wednesday evening and this is what was sent: (You may still want to reach out to validate that this will work for your environment)
After reviewing notes from a customer who had this workaround in place and has already patched they noted that the temp table we use in the workaround gets removed. At this time it is safe for you to patch and then immediately afterwards you will need to run the following SQL query:
CREATE TABLE [kav].[Protect550-unprocessedclienteventbkup](
[Id] [bigint] NOT NULL,
[eventtype] [int] NOT NULL,
[agentGuid] [numeric](26, 0) NULL,
[eventTime] [datetime] NULL,
[Message1] [nvarchar](1000) NULL,
[Message2] [nvarchar](1000) NULL,
[Message3] [nvarchar](1000) NULL,
[Message4] [nvarchar](1000) NULL,
[PublishedDate] [datetime] NULL
) ON [PRIMARY]
We may have been the one they're talking about here. Our Kasperksy message queue troubles have been gone for a long time, but came back after installing 18.104.22.168. This exact workaround has been established for us today. I'm not at all sure now if this was in place earlier. This fix goes together with a scheduled agent procedure to empty the kav.UnprocessedClientEvent table of dead events. This combo works, and it's the only thing we've seen so far.