Kaseya Community

9.3.0.29 Patch Release - 23 February 2017

  • Hi All,

    We released patch 9.3.0.29 yesterday:

    http://help.kaseya.com/webhelp/EN/RN/index.asp#38186.htm

    9.3.0.29 Patch Release - 23 February 2017

    Critical Issues For Customers To Patch Immediately

    Virtual System Administrator™

    • Processes running under LocalSystem on Windows hosts can now be terminated in Live Connect. (PT-275/ESR-514)
    • Fixed an issue that prevented a ticket auto-created in Ticketing by an alert or email from being assigned the correct user specified by Assignee Policy--without having to edit the ticket first. (PT-86/LI-271,LI-258)
    • Fixed validation for the presence of the $top parameter in REST API requests (PT-91/API-397)

    Anti-Malware

    • Updated the Anti-Malware executable used to run CLI commands, eliminating the creation of multiple processes on the agent machine. (PT-356/PROTECT-11)

    Cloud Backup

    • You can now filter the 'Last Backup Column' on the Cloud Backup > Machines page using a drop-down list showing the following options: Not Scheduled, Successful, Failed, Delayed, Running,Canceled. (PT-455/ATTWO-2621)

    Software Deployment and Update

    • Changes were made to prevent Software Deployment and Update deadlocks when running baseline audits and applying profiles via policy management. (PT-438/SDP-1862)

    Non-Critical Issues For Customers To Patch When Convenient

    Virtual System Administrator™

    • Added support for Windows Server 2016 on the Agent > Automatic Agent Update page. (PT-451/SDP-2104)
    • The agent version was updated to 9.3.0.16 for Windows and Mac agents. (PT-458/ESR-514)

  • 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.

    My .02

  • 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 =)

  • 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  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:

    http://help.kaseya.com/webhelp/EN/RN/#38187.htm

    All prior to this 9.4.0.13 patch release on Monday, were not flagged as Critical.

  • Excellent update thanks

  •  

    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 9.4.0.14 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.