Kaseya Community


This question is not answered

Hey guys,

Feeling a little frustrated here dealing with my customers and their patches. Seems people don't understand that they won't receive patches if their computer is off or logged in. So let's get to my point

I'm looking for a way to create a report on customers who are missing approved patches but I also want to include a way to see if they were logged in during this time. I was thinking about modifying the procedure that requests permission to reboot if user is logged in and does nothing if no response. I want the procedure to basically say the customer was logged in and refused the reboot, save that to a variable, and some how plug that into a report. That way I can see right away that a patch failed because of the user. Also I want to be able to show my customers this so that they can comprehend their impact on patches a little better. Any ideas?

BTW, I won't reboot if a user is logged in just incase they have important, unsaved documents open etc. etc..

All Replies
  • We recently solved this dilemma - but have not yet deployed it to customers.

    We have a GUI on every workstation that reports status - next scheduled reboot, last/next scheduled maintenance, etc. It also reports the last 50 maintenance tasks that were performed (The "what have we done for you lately!" display.) The interface is coupled with our maintenance tools, which displays an MSP-branded dialog box telling them that patches are scheduled for that night, log off, don't shut down, blah blah... The dialog box has an OK button, and will remain on the screen for 24 hours or until the OK is clicked. We record the user ID and time the notice was acknowledged.

    They STILL act surprised by the need for the reboot the next day, after ignoring the request to log off. Then they managed to ignore the Nag messages that pop up every hour, sometimes for more than a week.

    <queue evil laughter sound-bite>

    I now have an application that is System Modal - it prevents access to any other application, forcing it to remain on top of the other applications after it launches. The only way to terminate it is via taskkill in a remote session.  This app covers an area of 16384x16384 pixels - effectively covering ALL displays with a black window. The upper left corner displays our logo, a message stating that updates have completed and a reboot is required TODAY. They MUST select a reboot time from a drop-down list that offers times every 15 minutes starting at least 8 minutes from the current time until 23:45. It defaults to 17:30. They MUST click the Accept button to return to their desktop. The app schedules the reboot AND an at-login task to insure that the system wasn't put to sleep/hibernated - it reboots immediately if scheduled task hasn't run. The message is configurable by the MSP, and the patch configuration can be set to run this post updating. The application reboots immediately when launched if no user is logged in.

    To take it a step further, I have procedures that can remove the Shutdown option from the Start Menu during the day prior to patch night and restore it the next morning, and we disable sleep/hibernate on any AC-powered configuration.

    The inability to get workstations updated in a timely manner is reaching epidemic proportions. When I worked in the financial industry, they patched and rebooted during the day to enforce the updates - you had 10 minutes to save your work.

    This will become part of our standard patching solution in our Core Automation suite once it goes through some additional field testing.


  • Interesting stuff Glenn. I really get a kick out of your forced acknowledgement of the reboot. There are some special computers that I would love to apply it to. Would save me some time fixing problems caused by computers failing to reboot for months.

  • @RShaw - Interested in Beta-testing this?

    I'm a week or so from finalizing this. The Beta would have the MSP Builder logo hard-coded but you could still prominently display your MSP logo and contact info, just as in the commercial product. Call it via A-P as a post-patch procedure. I'm finalizing the A-P as well.

    I'd be interested in what objects might be open to customization or enhancement.

    P-M me here or contact via the MSP Builder web site if you're interested.


  • i want this