Upgrade superseded available application immediately
Make it possible to automatically upgrade an application that is deployed as available immediately (without having to wait for the maintenencewindow to apply.)
This was previously the default behaviour, but is no longer possible? Can this be made an option again?
One more thing - the scope of removal/upgrade should never exceed the scope of the targeting collection, either user or device. I believe that is the bug that this issue was for:
So if that issue really was fixed (?) then all we need now is to separate the deployment options for both the "Available" and the "Required" parts that are inplicit in an Available deployment of a superseding application where superseded installations exist in the targeted population (either user or device).
I vote for this - and also please increase votes available - the number of really good, even essential improvements is far greater than a paltry 10 votes.
At the minute, I could use 20 votes, and perhaps 40, given that we can tie up multiple (up to 3) on a single item.
When superseding application is 'Available' these options are greyed out, but when we tick "Automatically upgrade any superseded versions of this application", then the User Experience activities to be performed outside the maintenance window, should be allowed: Software Installation and System Restart, And get back the option to prevent restart on a server.
By the way, the supersedence 'Uninstall' action runs as soon as the policy on the PC is updated, removing the old version, but the new version does not automatically install, it seems to be waiting (for that annoying maintenance window) even though it's not necessary to wait.
And some sites would not want the uninstall to go straight away, so the maintenanance window options should be made configurable, and apply to the removal of the previous version too, instead of what we have now: the removal running straight away, and the new install waiting till the evening.
BUG: I would classify the inconsistent behaviour above as a bug, which could be resolved by activating the configuration of the Maintenance Window options in the SCCM console, and tying both the old removal and the new install to those configured maintenance window options.