I saw that 18.104.22.168 release notes were posted https://helpdesk.kaseya.com/hc/en-gb/articles/360009441498-9-5-0-28-Patch-Release-10-June-2020 but I haven't seen Oscar Romero's usual post about it yet. Any feedback on it yet?
Installation packages are still severely broken in in .28. Only windows specific packages can be edited and while the editor does preserve the strings with spaces the installer itself does not so it also ignores all of the other configuration parameters.
The organization pulldown in the create or edit users panel has not been fixed.
internally getfile() will fail if using variables and quotes ("#global:path##global:file#") so will writefile().
ExecuteCommandshell, exceutepowershell, where you're expecting #global:cmdresult# or #global:psresult# will return as not existing if there was a failure to execute the command (security products blocking the execution of PowerShell for example) so the documented methods of using the variables must now be wrapped inside of a if getvar() exists structure.
The jury is still out on the suspend alerts procedure working on the first call. The work-around to call it twice is not feasible for us to use with all of the code we maintain.
Bottom line: None of the major bugs in .27 have been fixed with .28 except the early timeout of user sessions.
Wondering if this update has been pulled. Our VSAs were showing .28 as the latest available but have now gone back to showing .27 as latest available.
Even our development server that we updated to .28 is now showing .27 as latest available.
I don't know if it has been pulled, but looking at the comments from PedroPolakoff3 I can't imagine going to this patch.
PedroPolakoff3 do you know if those agent procedure bugs are documented or even confirmed by Kaseya officially? Do you know if they are working to fix them? We do a lot of exceutepowershell, where we are expecting #global:psresult#
I've documented all of them and I do have tickets open with support.
Some have been acknowledged as bugs and the problem with #global:psresult# and #global:cmsresult# is being pushed back on a "by design".
I, personally, do not consider something that is documented as always having a value (even an empty value) starting to come up as "uninitialized" as "by design" unless that design is a very poor one. If it's not supposed to have a value then it should be documented as needing to be wrapped with a "If getvar() exists" structure, which it is not. (unless someone scrambles to change all of the documentation quickly).
The same with the inconsistency and the use of quotes on paths when variables are used within them. If "#path##file#" is valid in 90% of the if tests and thenelse commands it should be accepted 100% across the board, not generate a failure if used in a getfile() or writefile() command.
It may be of note to some that failures in these variables may not be immediately picked up unless you're actively looking. We have a stored procedure on our SQL server that pulls the audit trail from every procedure executed on every endpoint (for compliance purposes) that we can then select only those commands that show as "FAILED". I check these daily to make sure that we haven't introduced any problems with changes that have been made to our base code (~200k lines). When I see errors I dig into the code to see what lines failed and that's where I caught the #global:psresult# being uninitialized when PowerShell execution is blocked by a security product or policy. Further checking showed the same to be true when executeshellcommand() is blocked or fails in execution.
I asked about the problem with the use of quotes changing in .27 here: community.kaseya.com/.../24928.aspx