This is an WARNING alert box.
This is an ERROR alert box.
This is an INFO alert box.
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.
Thanks
0
Comments
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.
https://www.pdq.com/blog/distributed-file-system-in-windows
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.