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.
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.