Rate-limited heartbeat trigger? (Deploy on heartbeat once per hour/day/week/month)

Nomen,

What are you trying to deploy, exactly? I'm struggling to see why option #2 or option #3 are unacceptable, assuming that you can easily scan for the results of the deployment and use that to build a filter for a dynamic collection.

I was originally thinking about auto-approved packages from PDQ's library, such as Google Chrome, since it seems kind of pointless having them auto-approved if they then have to be manually deployed.

However, I've just realised that PDQ Inventory provides a bunch of system variables for the current versions of those packages, so I can actually create a dynamic collection which just contains the out-of-date machines and then heartbeat deploy to them based on that group membership. No manual filtering required!

Still, for argument's sake, let's say I wanted to do something else like running a script once per week, every week, or deploying an automatically updated non-PDQ package.

For static PCs in the office there's no problem because interval-based deployments work just fine.

But when you have laptops outside the office that might only get connected once or twice a week, or conversely might get connected and disconnected multiple times a day, for what could be a few minutes or a few hours, you can't schedule deployments around that.

A heartbeat deployment with a configurable rate-limit would be perfect. It would deploy whenever the laptop came online and then wait for a specified interval before attempting another heartbeat deployment. No manual intervention required.

The only other solution I can think of is setting a registry value during deployment which is then used to filter a dynamic collection, but that seems like a bit of a hack to me...

In your hypothetical I suppose you'd have to just use a heartbeat trigger and filter them using a dynamic collection in some way. You could do that with a reg value, a WMI value, a text file, etc.

You could also set it to stop deploying if successful and then clear out the list of successful deployments whenever you want to start re-pushing.

Hi Nomen, 

There are quite a few options that are available to you. You could combine some of the options and have it both on a scheduled interval and use the heartbeat for those devices that aren't often connected. That in combination with the "Stop deploying to targets once they succeed" option checked would make sure that it doesn't go the same machines too many times. 

There are many options with Schedules so I'm sure there is a way via automatic schedules and collections that we can get something figured out that does the automation the way you need. 

Hi Bobby,

As per my previous post, I have solved my specific use case by using dynamic collections which filter machines based on PDQ Inventory's built-in system variables, e.g. Application Version Lower Than $(AppVerGoogleChromeEnterprise). That's working great!

I'm now just talking hypothetically about how to achieve regular automated deployments to sporadically connected remote devices, where PDQ's built-in variables are not applicable, and where no version information is available for filtering.

Vague examples off the top of my head:

• Periodically running something on the command line (e.g. a robocopy)
• Periodically running a PowerShell script of some kind
• Periodically copying an amended config file to the device (xml, cfg, ini, json, whatever)
• Periodically displaying a popup message as a reminder (unlikely, but you never know!)

So let's imagine I want to do any of the above once per week, and I don't know when my remote devices will be connected, and I don't want to have to manually reset/edit/update my target lists or collection filters on a weekly basis to make it work.

I can't actually think of any way to fully automate that, without requiring some kind of weekly adjustment to make a dynamic collection include the correct targets.

Even writing a "Next Deployment Date" value to the registry during deployment doesn't help, because how do you evaluate that in a dynamic collection? It's just a string, so you can't do a "less than" comparison against the $(Date) variable.

Another solution would be if deployments could update custom fields in PDQ Inventory, but that's not currently possible either.

It would all be so simple if the heartbeat trigger just had a configurable rate-limiting option! :-)

Nomen,

I haven't had a chance to play with it yet, but the PowerShell Scanner in PDQ Inventory might solve this issue for you. You would just have a dynamic collection that looks at criteria from a PowerShell Scanner. You could use PowerShell to touch a file to change its modify date and use a PowerShell scanner to look at that file's date, for example. You could also just write a date to a text file. Then you could have the collection only include machines where that date is not within the past week and point a heartbeat schedule at it. That would cause the machines to have a minimum of one week in between pushes but do a full heartbeat schedule after that one week.

Hehe, yes, I just received an email about the new PowerShell scanner today.

That pretty much solves this entire thread because you can return just about any information you like from a PowerShell scan, and more importantly, you can return the correct data type for filtering.

For example, by returning a on object containing a [DateTime] value, a dynamic collection is actually able to evaluate that value as a date rather than a string.

Alternatively, the PowerShell scan itself could carry out the evaluation and simply return a boolean for the dynamic collection to filter by.

I still think a rate-limit option for the heartbeat trigger would be cleaner in some cases, but PowerShell scanning certainly does the trick!