Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

PDQ Deploy WOL Step?


I was wondering if there were any plans to add a "WOL" step to PDQ deploy similar to the "sleep" / "reboot" step?  

I tried using a shutdown command and then a WOL package I have which does WOL if they are offline, but since it was deploying in prior steps it doesn't try to wake them up, just sits at reconnecting. 

Currently my auto-deployments will not deploy to freshly imaged machines without shutting the machine down and then waking them up (reboot doesn't successfully do this) as they auto deploy off heartbeat.  The fastest way I've found to have inventory see the new machine for heartbeat to send the auto deploys is to shut the computer down then have inventory see it off and inventory WOL it, once on the auto-deploys start going instantly.

Having the WOL step would allow this to be automated as well as it be a good quick test for WOL before physically deploying the machine to its location, rather than having to do it manually.

If there's a better way to get the heartbeat auto-deploys to start going I'm open to suggestions there as well!




Date Votes
  • -2
  • A couple things to check for heartbeat: Make sure your heartbeat is set to an appropriate interval for the number of devices you track in Inventory. It's possible that if you've added a lot of new machines since you last set your heartbeat settings that your heartbeat can't get to them before it starts over. If you have 500 or fewer machines, the default 300 seconds is fine. If you have over 500 machines, add 60+ seconds for every additional 100 devices. Also make sure the right ports are enabled on the endpoints. We had a newly imaged machine not respond to scans, heartbeats, or deployments until we opened up all the recommended ports (then we made sure to include those changes for the rest of the OU the device was added to). 

    If you think that your devices might boot up too quickly on a reboot step from Deploy and that might be causing them to sit at "reconnecting", try turning off Fast Boot/Quick Boot in the BIOS, and adding 2-5 seconds of logo/boot screen display time.

    Let me know if any of that helps!

  • I'll try adding to the interval for heartbeat.

    I'm not having any issue with connecting to the station at all - it's showing in inventory as online, I can ping, manually heartbeat, deploy, scan, etc. without issues.  The issue I'm having is my auto deploys are set to start deploying on a heartbeat.  The way it appears that is working is even if the computer is ON and it can send a heartbeat and come back online, the auto deploy will not start deploying until it first sees the computer OFF and then does another heartbeat seeing it on.  

  • It sounds like the heartbeat is your only trigger for the deployment, correct? If that's the case, you may want to have other triggers enabled, like daily or interval. I've personally found that scheduling a deployment using only a heartbeat can take some time to hit all the targets and deploy successfully. When I was working with over 1000 computers, I'd set my schedules for a heartbeat plus a daily trigger and it tended to work out better than a heartbeat alone.

  • Correct.

    I figured setting it to heartbeat only would simply work better due to it only hitting the devices that are actually on.  If I set it to daily or interval it would be starting hundreds of deployments for devices that are not online - either sticking them in the retry queue, waiting for them to try to wakeup, or possibly getting stuck in "connecting" before stopping and moving onto the next in the queue.  That seems like it would make a lot of continuous deployments going on that are always going to fail compared to the heartbeat that will only start going when they see an online computer.

    (about 1/2 to 2/3 of the devices are laptops that get turned on and off multiple times a day on a random schedule). 


  • Okay, that clears up a lot! :)

    You can always disable the retry queue either at the package level (scheduled deployments from your own packages) or schedule level (auto deployments from prebuilt packages), which should make it so deployments are only happening on the triggers you set. (If I'm interpreting the documentation correctly, that is.) Additionally, you can use the "Stop deploying to remaining queued computers after ___" feature if you're worried that the deployment might run too long after the trigger starts it. If you'd like a shorter timeout for computers stuck as "connecting" so the deployment moves through the queue faster, you can change TCP timeouts by going to PDQ Deploy > Preferences > Performance.


  • I mean I'm pretty happy with the way the auto-deployments are behaving with heartbeat, I'd really rather not put manual intervals on there because it would almost never hit the mobile devices (sometimes they're only on for 15 minutes in a day).  

    The only thing not working as well as it could is when I have that fresh image I'm forced to turn it off and back on before it starts auto-deploying, hence if there was a WOL deploy step that just tells inventory to use it's WOL command, similar to how deploy can send a scan after the deployment, that would be perfect as I could have the package shutdown, sleep for 30 seconds and then WOL to then get the heartbeat auto-deploys going. 


  • Write a utility to send a WOL packet to the machine from Powershell. Could be a simple little console app that you input the MAC address does it's thing and then WHAM-O, you're on your way with the autodeployments.


    It's interesting that you are having this issue at all with your imaged machines. I'm using a Heartbeat schedule to a Collection in Inventory (we target a specific security group), and packages are deploying just fine. That being said....we stage them elsewhere and they kinda just sit around until we get to them. By the time they do they have their apps.

  • There's a PowerShell cmdlet (or group of them) for almost everything, isn't there, Stephen? :)

  • Powershell is life. I'm serious when I say it'll change the way you admin.

  • @ Stephen,

    Having to enter the mac address would kind of defeat the purpose of "auto" though wouldn't it? The great thing about inventory's WOL is that it grab's the MAC off its scanned NIC and doesn't need any input..


    Yeah if I manually turned them off to put them where they're actually going to be used, the regular turning on then activates the heartbeat and they go fine - the reason I'm trying to force it to go before that is to ensure those applications are on before any user goes to use them (again mostly due to the laptops, the desktops the second I plug them in and turn them off they start going before anyone goes to use them, the laptops would sit there off until they're used). 

  • You are correct in that it isn't very "Auto", unless you leveraged the Inventory database. But this idea is quickly becoming ugly. I don't like it anymore. Haha.