In this forum patch 188.8.131.52 was announced a couple of days ago. I wnt ahead and installed the patch; accordingly my VSA is now at patch level 184.108.40.206.
Today, I see that all mention of this patch has been removed - from this forum, patch release notes and the VSA's patch notifications screen.
I see at http://community.kaseya.com/b/cloudops/archive/2015/09/28/service-desk-e-mail-reader-not-creating-e-mails-on-saas-servers-upgraded-to-9-1-0-11.aspx that there seems to be a bug in 220.127.116.11.
OK, so withdrawing a buggy patch - no problem. Keeping the fact secret by deleting all references to the patch - BAD FORM Kaseya. It is WRONG to suddenly pretend this patch never existed. Instead of trying to cover up a problem patch, why not be honest and just state that the patch has been withdrawn?
Also, how about making the fixes available to on-prem users that have patched?
I installed version 11 two days ago. I had to Reapply Scheme this evening (had a problem with a script failing) and saw the NEW release is version 10. Try upgrading to that is you can.
The kinstall.exe won't permit the selection of an older patch version than the one currently installed. There's also nothing in programs/features to uninstall.
If the only bug is service-desk related I won't worry as we don't use SD. Otherwise it's time to raise a ticket methinks.
Still also think that Kaseya hiding all references to 18.104.22.168 is unethical.
and what were all those "announced" server improvements ?!! Should we see any difference ?!
The patch was pulled due to missing files in the dev branch. SaaS is up and working. We are repairing the installer for OnP now and will post updates as we have them.
And we thought it was just us - it's a bit disappointing to find we're not.
I agree a normal notification would be the way to go.
The roadmap webcast will start soon, it would be something to talk about....
I totally agree. Now I'm not sure if my system has been compromised because of this.
Nothing but crickets from Kaseya...
Honestly - I keep hearing how they've "changed" - but the only thing I see changing is who's saying they've changed... We only apply updates every couple of months after they have been out for a while because of issues like these.
As a standard practice we never install any vendor's updates immediately in production environments. For Kaseya they release updates at the beginning of each month and mid month... so we install them on the last Friday of each month.
At the end of last week, Kaseya released Patch 22.214.171.124 as part of our bi-weekly patch updates. Over the last several days, we became aware of an issue where customers running R9.1 with the 126.96.36.199 patch installed had issues Service Desk (saving tickets, inbound emails and SD API). The patch was removed from the download site as we investigated and we confirmed it was related to a specific build process.
We are building and testing an updated patch 188.8.131.52 which includes all of the fixes from the original patch and is planned for release this week.
We have already resolved any issues in our SaaS environment. If you are an on-premises customer and have installed patch 184.108.40.206, please contact support and they can work with you.
We apologize for any issues or impact this has had in your environment and we are taking steps to improve our patch processes moving forward.
I don't understand why you are doing bi-weekly updates. Does this mean you have found so much wrong with Kaseya that you have to release as you fix bugs?
The bi-weekly cycle (one patch release every 2 weeks) is really about allowing admins to plan their VSA patching cycle. If I know to expect patches twice a month I can plan my VSA patch window/downtime accordingly. This is far better than ad-hoc a patch could show up any time approach, or even worse, having to wait for the next release (up to 4 months) for a bug to be fixed.
So, it's about delivering on a reliable cadence, and not an indication of the bug quantity. In other words, you should not try to interpret the release cadence as a measure of the buggyness of the software.
Obviously, if there are no patches ready, then nothing is issued. Also, sometimes A patch is really a feature request - e.g. one of the recent patches added win10 compatibility to one of the modules; another added the agent procedure signing enable/disable option - once again IMHO this sort of thing is best delivered as a patch, instead of making us wait anything up to several months for the feature to become available in the next release version, or resorting to making new releases on a week to week basis.
the withdrawel of the patch should have been accompanied by a general communication instead of quickly removing the release notes and do as if it never existed !!
But to this point - it was stated that they would stop using patches to push/remove features and now we are back to that again... This is a slipperly slope! The entire purpose of a patch is something is broken (it is outside process and thereby the risk is greater because a full regression/cycle test is not done). I don't take patches lightly, unless our software is flat broken - it needs to go in the next release. They had tons of time to get this "agent procedure signing" stuff out of the 9.1 release - why did it wait until a patch?