Central Management - Improving the Upgrade Outdated Software deployment

[aledeniz]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

Recent versions of CCM have introduced a feature to automatically create a deployment to "Upgrade Outdated Software." On the Software page, there is a button labeled "Actions for Software" at the top right. Clicking on this button opens a menu, and selecting "Upgrade Outdated Software" creates a deployment with a step for each outdated software. While this feature is a great idea and much appreciated, its implementation needs improvement.

In real-world environments, multiple-step deployments are often unusable because many computers are frequently unreachable. With the Execution timeout defaulting to 14,400 seconds (4 hours) and the Machine contact timeout set to 0, the first step involving an unreachable computer will delay the deployment by 4 hours. If there are 52 outdated software items, completing the deployment would take 208 hours, which is more than a week! Although the global execution timeout is set at 14,400 seconds to prevent this, it means that the "Upgrade Outdated Software" feature is effectively unusable, as only the first step will be performed.

Describe The Solution. Why is it needed?

The primary request is to ensure that the execution of subsequent steps is not blocked. For example, if step 1 targets computer1, computer2, and computer3, once step 1 completes for computer1, it should immediately proceed to step 2 without waiting for all computers in step 1 to finish. CCM should handle computers like swimlanes. While computer3 may be stuck in step 1 until the machine contact timeout or execution timeout is reached, computer1 and computer2 should be able to move through the steps sequentially up to step 52, or whatever the final step in the deployment is.

It would be ideal also to be able to set the default machine contact timeout or execution timeout for all steps. The proposed defaults (0 and 14,400) are not fit for purpose for a real life environment. We always use 10 for machine contact timeout and 600 for execution timeout, while we calculate the global execution timeout from the formula ((number of steps * 600) plus 660). Problem is, there is no way for us to change the default, so we have to do it manually. With the deployments automatically created by the "Upgrade Outdated Software" feature updating these is completely unrealistic, as there are generally tens of steps to update.

Last but not least it would be great if it was possible to cancel the steps individually. At the moment we can only cancel the deployment, which will cancel the current step and all subsequent steps:

Additional Context

Currently on CCM v0.14.0

Related Issues

No response

┆Issue is synchronized with this Gitlab issue by Unito

[github-actions]

To vote for this issue, please add a 👍 emoji to the issue description. Votes in comments are not recorded.

[pauby]

If I understand correctly, there are three four issues here:

1. When creating a deployment from an 'Upgrade Outdated Software' Deployment, each package to be upgraded is added to its own step rather than being one step. The only part that causes me to pause is how many packages can be added to the same Chocolatey CLI command line before there are issues. We'd need to determine that. There are alternatives, such as a packages.config file that only has the package names in there, but it would require Support usage of a packages.config for the choco upgrade command choco#3721 to be implemented first.
2. The second issue is that a Deployment has to wait until all computers in the Deployment have reported back their status (or timed out) before any of them can move to the next step. It would be an improvement if there was a second Deployment option that continues with subsequent steps for a single computer, regardless of what the Deployment state of other computers is.
3. Deployment Step timeouts should be able to be set on a per-Deployment basis, and a global basis (for example in the CCM Settings).
4. Allow an individual Deployment Step to be cancelled. This has been raised over on Central Management - Allow cancelling an active deployment step #415.

Did I capture that correctly @aledeniz ?

[oed-pelza]

I also agree to this improvement. We never ever used a deployment plan with multiple steps for that reason. If we need multiple actions, its always an advanced script deployment step.

It works, but its very unhandy and you have to care about error handling and so on.

[pauby]

@oed-pelza did you upvote this issue?

[oed-pelza]

yes!

[pauby]

@aledeniz can you confirm I captured what you were looking for here?