🤘 0 reputation



Joined: 3/21/2018

Last seen: 1/8/2019

  • +1 for set priority's on deploy packages. And perhaps not helpful, but in case it is for anyone, I've semi-resolved this priority issue with scheduling.

    All of my In-Policy PDQ Deploy Packages fall into one of six schedule tiers. Those schedule tiers allow for six levels of priority. (Of course you can have as many as you want)

    Starting on each even hour is schedule one. Then each subsequent schedule is set to start 30 seconds after the previous. All are set to abort 1 minute prior to the next even hour. So 2:00:00, 2:00:30, 2:01:00, 2:01:30, 2:02:00, 2:02:30 - All set to abort at 3:59:00.

    As to my particular reasoning for these schedules? Getting security updates out and installed sooner than other 3rd party updates.

    Schedule 1 is for High Priority downloads to distribution points. Schedule 2 is for Low Priority. Schedule 3 is for High Priority P2P downloads at remote sites for the high priority packages. Schedule 4 is for Low Priority. Schedule 5 is to run the install for the locally staged High Priority packages at remote sites. Schedule 6 is for Low Priority.

    Distribution Point and P2P downloads are ran using Powershell jobs deployed by PDQ to lookup the % of bandwidth permitted at each site for the given time of day and RoboCopy metering the downloads to that rate. It's getting me by for now but I am working on a more complete solution that takes PDQ out of the equation in regards to any and all distributions. At that point PDQ would just be scheduling the installs for the already downloaded packages.

    Final note, none of this is a knock on PDQ. The product is great for what it's designed to do, and it's our business's fault for being so behind on network architecture. PDQ is just not designed to push updates for business's with 255 remote sites all running 1.5 Mbps connections, which are already maxed out during business hours. Perhaps if each site had a server OS to enable Push/Pull copying, but they don't and I'm left with a mess to keep cleaned up security wise. Feel free to ask if you have any questions or are curious about my distribution solutions.

  • Understood. It would make things a little easier, but there are ways around it regardless and I love your software!


    For other users:

    I'm deploying OS Upgrades and was wanting to perform some post upgrade configurations and apply the new OS's Monthly Rollup.

    For anyone else reading this wanting the same thing, I created a Collection for the new OS version. I created a scheduled deployment to the Collection which is triggered by heartbeat, and will apply the Configuration and Monthly Rollup. So as a machine comes back online from the upgrade, it should receive the post upgrade packages once the heartbeat period has elapsed.

  • What if step 2 installs an application which inherently reboots the machine and does not support a suppress reboot switch? Can the same package continue executing when the machine comes online?


    Perhaps if step 3 is a sleep step giving enough time to ensure the machine is back online? And if so, could there be a means to create a heartbeat step to wait until the machine is online, and then continue with the rest of the steps?

  • Has this feature since been added?


    Perhaps step the application uninstall/install of step two reboots the machine on it's own.

    Step 3 is a heartbeat step that waits until the machine is back up to resume the package?