Kaseya Community

"Suspend Alarm" and "Unsuspend Alarm" Agent Procedure Steps: It's time for an "Official Response" from Kaseya...

This question is answered

Happy Friday, everybody!  Smile

I've just submitted the ticket below to Kaseya (CS098207).  I will pass along any response I receive.  I'm determined that this will not be "Feature Requested" into oblivion... 

Good afternoon,

I'm sure this isn't the first time you've been asked this question, and it certainly won't be the last:

(there are more, I'm just lazy)

I understand that many of these folks have put in Feature Requests as early as 2010 for this same request... but here goes again:

Can Kaseya please add Agent Procedure Steps to "Suspend Alarms" and "Unsuspend Alarms?"

This would help everybody by:

1) Allowing us to suspend alarms prior to Automatic Updates, and unsuspend alarms after Automatic Updates are complete:

2) Making it easy to temporarily stop alarms if an Agent Procedure is cycling a key service

I certainly understand, if the machine is not online, that the "Suspend Alarms" and "Unsuspend Alarms" Agent Procedure Steps would have no impact (the machine needs to be online in order to run an Agent Procedure), so a site-wide alarm suspension (for an internet outage/flood/earthquake/tornado) would still have to be done manually, and that's not a problem... you could certainly mention this in the "notes" field of the Agent Procedure Step.

What I'm looking for here is an "Official Response" from Kaseya... this "Feature Request" has been in the works since 2010, and is something that many of your best customers are asking for.  Given that this request has, in the past (per forum posts above), been relegated to a sort of "Feature Request Purgatory," I'm kindly requesting a direct response (Yes/No, When) from Engineering on this issue.

And yes, this ticket (and any responses I receive) will be added to the Community Forums... fair warning :-)  We've all waited long enough...


Brian Dagan

All Replies
  • Ok Guys .. Here's the workaround. It seems to need an If statement as the 1st step ..so edit the XML export of your script
    I basically wrapped the entire script in a If Always True test .. and now I can import the script that previous failed


    <?xml version="1.0" encoding="utf-8"?>
    <ScriptExport xmlns:xsi="www.w3.org/.../XMLSchema-instance" xmlns:xsd="www.w3.org/.../XMLSchema" xmlns="">www.kaseya.com/.../Scripting">
     <Procedure name="TEST SQLCMD Import" treePres="3" id="399230907" folderId="78131635181623514582711911">
       <Body description="TEST SQLCMD Import">
    <If description="">
        <Condition name="True" />
    .....bla bla bla .. all the rest of the existing script with your +++SQLCMD steps etc



  • Hi all,

    I've tested the scripts on our test environment...  Works fine.....

    One question,  would it be possible to provide extra arguments in the script Alarm - Suspend

     plan in the future : date and hour of suspend

     recurring our not recurring

    Then we could include this in Policy Manager...  since  Alarm - Suspend All - deletes all other suspends too.  We have set suspend alarms to trigger when the scheduled maintenance is done...  So deleting those is not an option.

    Thx !!

  • @Sloeber70

    The main SQLCMD command that does the Alarm suspending has the option to set the start and end values which is set using the "CURRENT_TIMESTAMP" value for the start and the end value that is calculated by taking the current time and adding the suspend time in minutes to it. So yes it would be possible to specify future date and time. You would need to supply the future date in the following format;

    yyyy-mm-dd hh:mm:ss.ffff

    What I'm not sure of is in what scenario you would use it in? The Policy Manager won't schedule once off agent procedures with a start date in the past, or it couldn't the last I checked. Any automated interaction with the agent requires an agent procedure and if you tested the procedure you would know how long the process would take to set the suspend alarm for which you could also execute from your procedure. Just saying would be interesting to know how you would use it...

    msg+++SQLCMD: INSERT INTO monitorsuspend (agentGuid,startSuspend,endSuspend,recurInterval,recurMonth) VALUES (#cAgentGUID#,CURRENT_TIMESTAMP,dateadd(minute, #cTimeInMin#, CURRENT_TIMESTAMP),0,0)

  • Kaseya's response on the importing issue is:

    "On August 29 our development team disabled the ability to import procedures that have the +++sqlcmd due to security risk to the Kaseya ksubscribers database. This was hotfix 2548-2549."

    Lovely. Frustrating. I hope they reverse it, I really do. I've asked them to, at least.

    [edited by: ghettomaster at 5:51 PM (GMT -7) on 23 Sep 2012] m
  • it's no biggie like paul said just wrap everything in a IF statement

  • As per my previous post .. just wrap your scripted steps in an IF "Always True" step and you'll be able to import them again


  • FYI for anyone still following this (and/or using Ben's "Alarms - Suspend" and "Alarms - Unsuspend All" Agent Procedure Steps through the modified subScripts.xml)... there was another update to subScripts.xml on October 12th that will break any of your scripts that call these unsupported (in 6.2) custom steps:

    The fix remains the same... either:

    A) Reapply Ben's subScripts.xml and run a Reapply Schema -or-
    B) Use HardKnoX's scripts that accomplish the same thing without an unsupported Agent Procedure Step

    Again, the Suspend & Unsuspend Agent Procedure Steps are officially supported in 6.3, just not in 6.2.

  • Gah... how hard would it be for Kaseya to just include this in a hotfix for 6.2? I'm sick of re-applying it myself and clearly we will be waiting longer for 6.3.

    Ben? Brenden? Somebody?

  • I agree, would be fantastic if this could be committed to a hotfix.