Kaseya Community

Feature Request Vs. Bug Fix

  • I suspect Management at Kaseya needs to define the difference between a software bug and a missing feature/feature request for their support staff because they don't seem to know the difference or maybe they do and have been instructed by Management to delay bug fixes by relabeling them as feature requests which in my opinion is wrong.


    I recently submitted a ticket for an issue that involved the Patch Reboot rebooting a company directors computer while he was logged on even though it was configured not to reboot if somebody was logged on.

    In short this is a known issue that is caused by the "KaUsrTsk.exe" tool not running. The "KaUsrTsk.exe" tool is used by the agent to detect if somebody is logged in (console sessions only) and if it is not running then the agent will execute tasks as if nobody is logged on.

    After the Kaseya Support person tested and confirmed the issue they wanted to close the ticket and open a feature request for it.

    My argument is that this is not a feature request as the feature of detecting a logged in user already exists and just does it not work as advertised so it should be handled as a bug fix.

    This is not the first time an issue was moved the the feature request queue and if the new management at Kaseya really wants to fix things they should add this to the list.

    Discussion commence!

  • Can you post or PM the ticket number so I can check?


  • Hi Amado

    Ticket CS186873

    Thanks, I got a response that it has been reassigned to a specialist.

  • Hi

    The specialist replied to the ticket but I'll include here his response for the benefit of the community at large:

    kausrtsk should always be running it starts along with agentmon when the agent first loads. It is relied upon as you have found for detecting logged in users and it is also used in the execution of scripts for impersonating users among other things. It is a core part of the agent the same as agentmon.

    I believe the first tech suggested sending it as a feature request as you had actually suggested checking if WMI Win32_ComputerSystem.UserName value is not empty or null might be a more robust option, so it looks like he took this as a request for a new feature or enhancement. 

    We are currently investigating options to improve the Feature Request process and have more involvement from our Customers. More on this soon.

    Thanks for your suggestions and comments; keep them coming!


  • I haven't had a chance to respond to that ticket yet.

    I actually never suggested a feature request, I suggested/shared a possible solution to the problem of the existing feature of detecting if a user is logged on or not.

    Here is my full ticket description for all to see and nowhere in it have I used the words feature request;

    ------Subject: User detection during Patch Reboot not 100% accurate

    I have noticed this happening in Agent Procedures where if the "KaUsrTsk.exe" is not running Kaseya is unable to detect if somebody is logged on and if the action involves rebooting the machine it can have very a high impact on the end user.

    I suspect the same function is used by Kaseya Patch Management during some of the reboot options that checks if a user is logged in or not and today I got the first credible case that I can prove that the agent was the cause of the reboot while somebody was logged on.

    I have put my own workaround in place for the Agent procedures by checking the following WMI Win32_ComputerSystem.UserName value is not empty or null.

    Relying on the KaUsrTsk.exe process to always be running is obviously flawed and should be looked into to fixed to make the "isUserLoggedin" feature in Kaseya more robust.


    All my previous tickets that I have logged for feature requests have the words feature request either in the subject/title and/or in the body of the description.

    Regarding the solution I provided;

    I do not know if my solution will always work as I have only had a month or so to test it but so far it has worked better then Kaseya existing method of detecting if a user is logged on or not.

    I shared this solution with your company at the company I work for's expense and you do not have to use it all I'm expecting is for Kaseya to start fixing issues like this rather then chuck it into the abyss that you refer to as feature request.

    My response to the specialist (on Monday) will be as follows;


    It is my observation that "KaUsrTsk.exe" normally only runs if a user is logged in as a console session and it definitely does not always run when the "agentmon.exe" starts up as its configured as one of the Startup applications (See “Kaseya Agent Service Helper” under “MSconfig > Startup” or “Taskmgr > Start-up”).

    Our expectation as a customer is as follows;

    If I configured the Patch Reboot or a Reboot Agent Procedure to check if a user is logged in and to skip the reboot action then it should do so.

    The reality is that this is not always what is happening as I have had several reports this year of machines rebooting without the user getting an option to skip the reboot and in many of these cases I had people complain that they lost work because of these unexpected maintenance reboots.



    updated responce
    [edited by: HardKnoX at 5:24 PM (GMT -8) on Nov 17, 2013]