We released patch 184.108.40.206 yesterday:
Critical Issues For Customers To Patch Immediately
Virtual System Administrator™
Software Deployment and Update
Non-Critical Issues For Customers To Patch When Convenient
Nicolas Ponce With so many of the last releases requiring the agent to be updated again, surely this should be included near the top under critical issues?
If some of the fixes in the patch are on the VSA side and some on the agent side, then surely to successfully complete the patch installation all of the agents need to be updated, and as such should not be listed as "Non-Critical Issues For Customers To Patch When Convenient".
For example, wehen we installed patch 27, we found that we could not do much with any agent in KAV without upgrading the client. This was listed as a blocking condition when trying to install or upgrade KAV or when migrating agents from classic.
The agent upgrades seem relentless at the moment, so please give them the status they deserve and list under critical.
From my perspective I love the fact including agent update was suggested on this forum (perhaps from yourself) to be included in the release notes. It's even better, Kaseya listened and incorporated it.
While the agent update is important from my business perspective, I would not label it under critical as agents and the overall system will technically function without updating to the latest agent version; Remember the days when automatic agent update didn't exist? I sure do!
With agent automatic update, the agent update process is seamless and quite, and a big technical relief for my team.
I agree, obvioiusly it is not as critical as the VSA patch itself, but we do have issues here.
We have had a quite a few issues with automatic update. Whilst it does work well in the main, it has caused us some issues with some random machines and also with down-level clients, low resource machines and Windows embedded clients, whereby the install does complete in as timely a fashion as it expects, and it keeps spawning the agent update helper over and over until all resources are exhausted and the machine crashes. For these reasons we tend to enable it for a couple of days following an update, then disable it and manually update problem machines. It would be nice if certain machines could be excluded from automatic update.
We are going through a fairly painful KAV migration from classic at the moment and a lot of scheduled upgrades and migrations failed or were blocked because the agent needed to be upgraded for any of these tasks to work in KAV which caused us a few set backs. Sure, critical stuff like monitoring and alerting continues as is, but when juggling migrations and upgrades with 8000 agents it was lost time we could have done without.
@JB1975 - I'm with you on the automatic updates.. We also run on a lot of windows Embedded systems. I'd be curious to know what you are currently doing to get those updated when agent updates are required as that seems to be something we struggle with quite often.
Great feedback. Thank you for sharing that - we are in the process of the KAV migration as well. We are testing it with our internal endpoints right now and so far so good. We are documenting the process so we can inform our client facing teams accordingly and set expectations.
At that amount of agents, I understand the challenge all too well =)
Jonathan Use application blocker to block the agent installer and update helper on problematic machines whilst automatic updates are enabled. After a few days when most of the machines have been updated, disable application blocker and then manually upgrade the agent using the /r switch.
It is a nuisance if you have a lot of machine that need to be manually upgraded this way, hence why a little additional logic in the automatic update feature would be a winner for us when there are so many agent updates being released.
Thank you, everybody, for the great feedback.
Continuing the point JB1975 brought up, should Agent Updates be considered a Critical Patch Release note?
I will discuss this internally to see if this has been discussed previously, as this is noted in our latest patch as a critical for 9.4:
All prior to this 220.127.116.11 patch release on Monday, were not flagged as Critical.
Excellent update thanks Nicolas Ponce
I have been meaning to follow up but have been busy.
So, after discussing internally, the reasoning behind the Agent Update being in Critical in 18.104.22.168 and all previous classifications of the Agent Update in the release notes is the following;
The classification is dictated by the Priority of the JIRA (Our internal problem tracking system), which is determined by the bug report/submission created by the user/support engineer/developer who reported the issue.
A Priority 0-1 means the release note is critical, 2 or later is non-critical.
I hope this explains the current logic behind the classification in the release notes.