Deployments stuck on queued

I set up a deployment for the 22H2 enablement package to go out to our pc's. this was set to start at 10 pm on a heartbeat trigger 74 machines in this first batch. I came in the next morning and all but 9 of them were still on queued.

I had another deployment set to start at 2am on a different set of machines just a simple reboot for anything that had not been rebooted in 7 days and the same thing %90 stuck on queued.

I had restarted the server that day before setting up these jobs and did a flush dns as this happened the week prior on jobs as well.

Any ideas would be greatly appreciated.





Date Votes
  • How many deployments are you allowing to be run at once?


  • The deployments were running at night. I am not sure how many were running at that time. I am pretty new to PDQ I inherited this set up so maybe I need to tweak?? We did increase ram from 16bg to 24 this morning as well. Also when I reran the 22H2 deployment this morning it ran without an issue. 

  • You might want to bump those numbers up.  If you're only allowing 8 to run at a time and you had 72 total, that could take a little while...especially if the deployment is waiting for a machine to come back online after a reboot.

  • What kind of number would you suggest ?   

    My environment has a total of 650 devices, and I will at times want to push to all of them.  

    Not sure if that is recommended or if I should do it in smaller groups ? 

    Thanks for your input. 

  • Mine are set at 20 and 64.  Are your machines connected to a LAN or VPN?  All on the same subnet as PDQ or remote?  If on a LAN where bandwidth isn't a consideration, you could go even higher than 20 concurrent and bump the bandwidth utilization up.

  • We one primary location with the majority of the device and 4 other smaller locations with varying bandwidth capability those location have between 15-74 devices;

    we also have a good number of work from home as well as traveling sales force so from day to day no way to know that bandwidth ability. 

  • For the remote locations, I would consider moving your Repository to DFS with a replication partner in each site.  Machines in the remote site would pull their updates from the local partner and save bandwidth and make deployments run faster.

    Personally, I have most of my deployments like 21H1 or whatever run on a heartbeat.  Machines come online and get their updates.  It's rare that a ton of machines come online all at once, so this kind of staggers the deployments for you.


Please sign in to leave a comment.

Didn't find what you were looking for?

New post