"Triggering" a heartbeat

PDQ Inventory pings all devices depending on your settings under options -> prefeference -> network. It's not a constant ping, it's a ping all xx min (5 by default). If Inventory gets a answer the device is online, if not it's offine. If you only reboot a device it's highly possible that Inventory dosen't take notice of the reboot because there is no switch from offline to online

You can force a scheduled deployment easily, select the package, go to the "schedule" tab, right click the schedule and select "start schedule" -> current package. This kicks off the deployment to all selected devices inside the schedule.

But if you know that constantly online devices are missing the heartbeat, why you don't put in another trigger like "every day at 06:00 am"?

Many of our devices are included in multiple schedules. For example, a computer in a computer science lab is a "member" of a schedule that deploys and updates our "core autodeployments", a schedule that deploys and updates "core applications" (apps and settings that go to every machine that aren't autodeployments), and a schedule that deploys applications specific to that lab. Those schedules all use heartbeat (to catch those that get shut off at night) and a daily timed trigger (to catch those machines that don't get shut down at night).

Occasionally I want to force a workstation to run all schedules that are associated with that workstation (or group of workstations, as case may be). Sure, I could go shut down each machine, wait 5 minutes for it to be seen offline, then go back and restart it and hope the heartbeat sees it back online. However, this isn't practical: I manage labs across multiple sites. It's not realistic to have to shut down machines to hope the heartbeat is seen. It also shouldn't be necessary to have to know (or calculate) which schedules are assigned to every machine so they could all be "triggered."

My hope (and, frankly, the motivation for purchasing Inventory), was to be able to "stimulate" or manually trigger heartbeat schedules from inventory, so I don't have to go running around to machines.

Correlative to this, it would be nice for there to be a method from the workstation to stimulate the heartbeat-- a command to run, or an option within perhaps a taskbar icon for the inventory agent...

I would like say that I think that is a great idea. For a Office 365 upgrade, management wanted the user's to be able to trigger, or receive, the deployment themselves. I thought we would be able to achieve this simply with the heartbeat trigger, wherein the user would just reboot their system in order to trigger the deployment. However the most aggressive you can make the auto-heartbeat is 2 minutes, which means that there is a good possibility that during a reboot Inventory won't see that the system went offline. What SDOB-SW is proposing would be a great solution.

Occasionally I want to force a workstation to run all schedules that are associated with that workstation (or group of workstations, as case may be)

In therory good, but it could be a very very bad idea.

I have daily scheduled deployments with shutdowns (check for updates, install updates and shut down all devices), image what happen if i run "all schedules that are associated with that workstation".

management wanted the user's to be able to trigger, or receive, the deployment themselves.

Not 100% what you are looking for, but maybe a little solution:

Schedule the deployments, point to a (old) or (not installed) collection, and use this PS line first and add sucess code 6:

exit (new-object -ComObject wscript.shell).Popup("Install Office 365 now? (The device restarts after the installation, save your work - needed time about 10min)",120,"Package Install?",36)

If the user clicks yes the return code is 6 (don't forget to add this in the package) and the installation begins, if not he have to wait until the schedule for this package kicks in again with the question.

In my collection of apps, this is not a bad idea: "big" apps that are already installed are skipped by collection membership or other conditions. If I'm wanting to force a machine to be sure that it has everything assigned to it right now, that should be within my capability! It should also be within my capability to not have to do so, certainly, but--

PDQ, could you please chime in? How do I trigger a Heartbeat Trigger without having to actually turn machines off?

Thank you, Mike

Thanks Christian! That is an awesome tip that I will definitely use.

It would still be nice for PDQ to chime in on this thread.

It seems like it would be pretty trivial to create a way to have the Agent "trigger" deployments, say when run remotely with a certain switch... I'm imagining this as something that could be called locally (from the machine) or remotely (as a command-line tool). Basically, add "agent check-in" as a trigger condition similar to Heartbeat.

Mike

I agree, I think this would be super useful to have this. I asked this on the Webcast but they didn't really understand what I was getting at. Please hopefully if we keep this thread alive we can get someone from PDQ to chime in.

Shaun, thank you for bringing this up on the webcast! (I only was able to see a smidge of the end of it...)

I'm submitting a ticket referring back to this thread... Perhaps if several of us do that same it will get attention?

Mike

Here's what my ticket says:

"There are many situations in which I need to be able to trigger, from a workstation or otherwise on demand, all deployments that apply to that workstation (from all schedules in which it is included.)

Most of my schedules include a heartbeat trigger, but it's not possible to go turn off a remote computer, hit Heartbeat in Inventory so it's seen as offline, then boot up the machine again and hit Heartbeat again to see it online and trigger the heartbeat.

An ideal solution would be for Inventory's Agent to have the capability to trigger the heartbeat (or another, new, kind of trigger that could be added to schedules): for example, if I could run "agent --triggernow" either locally or remotely, would be a step in the right direction.

There has been an active discussion about this in the community (https://community.pdq.com/posts/10193-triggering-a-heartbeat) and I understand that this question was raised during the most recent webcast, but it seems that we're not explaining ourselves clearly. Please ask clarifying questions so that we can help you understand what we need!"

That's a great idea Mike. Please post any relevant responses you get from Support here in this thread. I'll surely do the same. Shaun

This is something we are also looking for. 

Mike, have you heard back from PDQ support?

I created a Tool for Inventory as a workaround, but I will also open a feature request ticket to see if we can build a feature to do this better.

https://gist.github.com/Colby-PDQ/6ddcf5680e5ca3f22aaf1b6f98e97cb9

Thanks Colby,

I added this tool this morning and it does provide a work around for the time being.

Keep us updated with the feature request. 

Cheers!

Is this still in the works?  My organization wants to use PDQ for our field offices but we want to ensure that when a machine boots up it gets any critical updates it needs immediately. Is there anyway for a machine to tell PDQ to start installing needed packages as soon as it boots up?

Zach

I believe the Heartbeat Trigger will do what you are asking for. Have you tried creating a Schedule with one?

https://documentation.pdq.com/PDQDeploy/19.0.40.0/heartbeat.htm

Hey Colby thanks for getting back to me.  Yes we use the heartbeat trigger on our deployments and it works great.  My management would like a way for the machines to call PDQ at startup to immediately install packages to ensure that if we have an essential package that needs to be deployed we know all machines are getting it before the user starts working.  I'm working on an API to allow machines to call the PDQ server at startup to install certain packages but I thought I would see if you guys had anything before I went any further.

No, we don't have anything like that.

Ok thanks man