Setup trigger timers.

Another approach could be to keep a log of triggers and decide not to fire if so many recent triggers have fired. I would be happy to have a trigger 5 times in 30 minutes for a particular guest connecting, but any more gets to be a real chore.

We have customers who need to know if their computer (Remote) is off line for more than 15/30 minutes.

We'd like to be able to know when a endpoint is offline for more than 15 minutes.

initial extension revision here: http://forum.screenconnect.com/yaf_postst9819_Extension--Offline-Machine-Notifications.aspx#post34665

due to potential concerns with scaling, the timer is currently limited to 2 minutes. this can potentially be increased depending upon feedback.

Hey Kurt,

Have you tried out the Offline Machine Notifications Extension? It would allow you to add a time delay to your trigger.

From what I've read it will always add the delay, we do like having the message ASAP but the triggers on reboot are completely benign and useless. It's especially annoying as we're over 100 machines that trigger

I want to use trigger definitions about the guest to send email notifications about a Guest when a Guest connections.  More specifically, definitions such as Session.GuestLoggedOnUserName and Session.GuestMachineName.

Because triggers fire immediately, these definitions do not have time to update and they come through blank in an email.  I brought this up here: http://product.screenconnect.com/topics/1154-sessionguestloggedonusername-and-sessionguestmachinename-blank-on-first-trigger-email/#comment-3155

If I could set a short delay before the trigger fires, giving time for these Guest-specific definitions to update, it should solve the issue.  I am only looking to have seconds in my instance.

This would be helpful.  We have a trigger that we need to send a session name after a new session is created but the session name is not created before the trigger is activated thus sending us a null subject basically.

Please add the ability to have a delay option in your triggers! I use the Offline Machine Notifications extension which is great but doesn't allow for HTML notifications. If that could be adjusted that would be a great start however there is so much power in your guys triggers. If there was a delay on something being triggered not only could you use this for offline machines but also you could delay cmds and have auto fixes through control. Hmm maybe even give Automate a run for it's money.

Glad this has been picked up! For us the best result would be just a simple text box where you can put in seconds before a trigger actually triggers (allow a different time for each created trigger).

So if I had 2 triggers one for "servers" and one for "clients" I could set a ~60 second timer for "servers" just to remove any internet blips and reboots and a ~300 second for "clients". 

Im not sure if it's changed yet but the reason we don't use the extension was that it didn't include when a machine comes back online. 

As a side note, my ticket was merged here and another large problem we have is if the Control server reboots it floods us with every machine coming online. Would it be possible to delay triggers on the Control Server all together for like 60 seconds while it settles from a reboot? 

I've got you on that one, create a new trigger servers online

Event Filter:

Event.EventType = 'Connected' AND Connection.ProcessType = 'Guest' AND Session.GuestOperatingSystemName LIKE '*server*' AND Session.HostConnectedCount = 0

Add as SMTP Mail

Subject:

Server Online

Body

{Session.Name} started responding at {Event.Time}

I have a nice HTML online alert for this as well. Set HTML as True and drop this code in body ;-) 

Server Online.htm

Er maybe I should have worded that better, we have it limited to servers only already. But we have a LOT of servers as well as few clients that trigger too...

I see, makes sense now. The biggest thing here is just having the ability to delay triggers. Then you could really do a lot with this.

I completely agree, just figured I'd mention the Control server reboot spam as it's in the same ballpark.