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.

Set Deployment Priority?

Why is there not way to set priority on packages so that packages with higher priority get installed first?

 

Example is if I have a current deploy running and I want to Push out a separate package to just a hand full of computers, I should be able to set a high priority for this new deployment so that it gets higher priority in the deployment queue and gets pushed out as quickly as possible.

9

Comments

20 comments
Date Votes
  • Came here to suggest this.  I'm rather surprised this idea doesn't have more support.  Currently, I just abort the larger deployment already in progress, send out my smaller deployment, then redeploy to failed computers.  It works, but it's not very elegant.

    1
  • I would also benefit from an option like this. As Brian stated stopping the running deployment and then restarting it seems clunky and inefficient.

    1
  • Would also like this

    1
  • This would be very useful.

    1
  • +1 for this. I have another thread asking for the same feature. Currently sitting here now have waited over 30 minutes for a deployment to 20 computers (3-4 minutes a piece) to finally finish. Should have been able to be out the door and delivering them across town by now!! Really frustrating, when this seems like a trivial feature (I'm not a developer) to implement!

    1
  • This would be a great addition to PDQ, the only way we get around it (kinda) is to use nested packages to deploy let's say an OS patch before another OS patch

    In the nested package the other packages become steps, here we can change the order of the deployment or rather juggle the steps 1-17 to suit needs - see example below where I threw a bunch of packages together.

    Not the most elegant solution for some sort of deployment preference but gotta find what works if a particular installation requires groundwork beforehand

    You can also change the Concurrent Target Limits under preferences with Pro or Enterprise versions might make your deployments move along more steadily, but the higher the numbers, the greater the use of server memory, CPU resources, and network bandwidth all good things come at a cost.

    1
  • I came here to do a similar feature request. We use the auto deployments to manage a bunch of different installs so there are constantly installations queued. When I am building a new package and need to test it "Deploy Now" really means "Get it in the queue now and wait an hour" which makes ironing the kinks out of a multi-step package time consuming. I would love it if "Deploy Now" put the jobs at the front of the queue instead of the back. It would also work fine if we could go to "All Deployments" and somehow adjust the priority or bump a job.

    1
  • I would also like to see this. I have to abort the running deployments and reboot the machine with PDQ installed before I can successfully deploy something I need deployed straight away.

    0
  • This would be a great feature. Please look into adding this. Thanks

    0
  • I run into this issue with laptops that kick off multiple heartbeat deployments when they connect. The first deployment in the queue is always windows updates with all of the smaller, quicker deployments queued up after it. If the laptop is closed or shutdown before the windows update finishes, which is more common than not, then all of my other deployments fail with it. If I catch them happening during my office hours I can abort the update and redeploy so the smaller deployments succeed, but a lot of deployments run in the off hours because several departments operate 24/7. Being able to set a higher priority on deployments, or even to set a lower priority for the bigger packages, would help to optimize the deployment process.

    0
  • +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.

    0
  • Another +1. SCCM has "Low, Medium, High" options for deployments. I'd like to see something like this as well so low sends can go when nothing else critical is in front.

    0
  • Yes. I want this too. Can't see any option still

    0
  • only after they've started to deploy though. I want to be able to mark a package as -always- high priority

    0
  • That will be amazing but i think its hard to code that. As David said i also need a package as "always high priority" not during a job. 

    0
  • I just added Enable-PdqPackageAlwaysPrioritized to my PowerShell module named PdqStuff, version 4.4.0. It allows you to tag packages so their deployments will automatically be prioritized. To use it, run the following:

    Install-Module -Name 'PdqStuff'
    Import-Module -Name 'PdqStuff'

    Read the warning, then:

    Enable-PdqPackageAlwaysPrioritized

    To tag a package, add a Step (any Type will work), and set the Title to "Always Prioritized". I recommend disabling the Step so it doesn't slow down deployments.

    1
  • ooh nice. will certainly give this a go today

    0
  • Will it work if it's a Pre-Step?  I only ask because auto-update packages will only allow me to add a pre-step, not a regular one.  

    0
  • Yep! I designed it with Auto Download packages in mind. Pre and Post Steps are pretty much the only things that survive updates.

    0