Allow the Client Upgrade to be performed outside maintenance windows
We would like the Client Upgrade feature to allow the client to be upgraded outside of maintenance windows but also give the option to only install when no user is logged in, like deploying Applications allow.
491 votes and "UNDER REVIEW" since 2018. What is the escalation process for this "user voice"?
3 years later, still no fix to implement this simple request... Please Microsoft, how much more time you will need to complete the review of this request ???
This would be perfect
Bryan Dam commented
FWIW, there was already a UVI for this that now had hundreds of votes: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/15032517-allow-the-client-upgrade-to-be-performed-outside-m
Bryan Dam commented
FWIW, there's already a highly-voted upon UVI for this: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/15032517-allow-the-client-upgrade-to-be-performed-outside-m
Kelly Walsingham commented
Agreed, the option to install outside of MW should be there as default and you either can select it or not, based on your use case requirements.
Ryan Berilla commented
A new MW type for client upgrades would be perfect IMO. The client upgrade process takes 2 maintenance windows to complete the upgrade. The first window only downloads ccmsetup and creates the scheduled task to download the rest of the bits. The second window triggers the upgrade. This means that it will take at least 2 months to upgrade clients for customers that have a single monthly MW on servers. Also, having a separate MW for upgrades would allow the client to upgrade by itself and not during the most critical time for the client. Most servers have one chance to install patches, apps, etc during their monthly window. Removing the client upgrade from that critical MW helps ensure that the installs complete successfully.
If a new MW type is not an option, fixing this issue would certainly help a lot. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/18487429-make-automatic-client-upgrade-more-intelligent-to
I added my vote on here last week, but then I found a way to do this that worked REALLY well for me, and it seems its basically a Microsoft supported feature(how new I am unsure) that I had never heard of, and indeed it seems Microsoft should have communicated it better.
So I'm just hoping this info is as useful to you guys as it was to me. I found this article:
It defines a really short and sweet process:
1. Create a package based on definition.
2. Publisher Microsoft and Client Upgrade type, source folder pointed to a folder that's got a copy of the SCCM client installation bits.
3. This creates a new custom package based on both the client installation bits and the silent installation program Microsoft uses for upgrade. When you deploy the program you will see your new deployment name is auto-appended with 'Configuration Manager Agent Silent Upgrade' signifying its got some built in mojo of its own.
4. As you will see the program does NOT do /autoupgrade the standard way in the command line(which will check for and fail if there is not a maintenance window, even though you deployed it with 'Ignore Maintenance Window'), instead it's kicking autoupgrade mode on by means of the policy the client gets when these targets are in the Pre-Prod Client Upgrade collection - more on that below.
5.One thing I need to add here - the targets need to be in your Pre-Prod Client Upgrade collection - the one defined in client upgrade tab of Hierarchy settings. If not, they will run this CCMSetup custom package, but without upgrade policy being 'allowed to upgrade', the ccmsetup wont upgrade them - they will reinstall at the same version, not the upgraded version.
6. I deployed this package with Allow software installed outside the Maintenance Window, that let the package kick off without one, and the secret sauce of Client Upgrade Policy(via the Pre-Prod Client Upgrade collection) did the upgrade without checking for a maintenance window itself.
7. Whole thing was very quick and easy. 5 minutes later, my first test machine with no maintenance window was upgraded to the latest SCCM version.
8. I've since upgraded about 50 this way so far, and all successful. It works very well.
Microsoft, we still need this feature, and preferably, at least 2 more maintenance window types: Client Upgrade, and Application Deployment maintenance windows.
Aaron Young commented
We have a number of clients that have older versions of the client, and we're forced to upgrade via some other mechanism because the auto-upgrade never touches them. We can ignore maintenance windows for other important things we want to force on clients... but not the client itself? I'm adding my voice to the request for a way to ignore maintenance windows on automatic client upgrade. Pretty please??
Bryan Powell commented
It is great that client upgrades now respect maintenance windows per the "Automatic Client upgrades - respect defined maintenance windows" feedback. However, we now are dealing with the opposite issue.
We have very narrow maintenance windows defined for our servers and as such 75% of our clients were out of date 2 months post upgrade. It would be great for a toggle on the upgrade configuration so we can choose the behavior for the upgrade to respect the windows or not, similar to a normal application deployment. This way we would not need to manually push the client upgrade out to bypass the windows.
Daniel Ratliff commented
This is definitely a concern for us as well. We have a single maintenance window for servers each month. When the client upgrade runs it can potentially impact our patching deployments. We need a way to ensure that the client upgrade does not impact our patching deployments.
This is a nice improvement specially if you have servers with no maintenance Window or the maintenance Window is in the future. Since the cliente upgrade doesn't require reboot I would like to have this option to install outside the maintenance window.
Gabriel Lopez commented
I would prefer to have the option for another MW type just for Client Upgrade only and/or also the option to bypass MW with a checkbox.
Rob Ostry commented
Mobile workstations may seldom be online during a maintenance window. We need a new option to allow for client upgrades outside of the maintenance window. Below is a suggested UI improvement to support such an option:
Just got hit by the exact scenario described by bdam and LoveHate-ConfigMgr this morning, one of my collections had most of its clients fail to patch as the client upgraded partway through the installations.
Please, if we can't allow the client upgrade to be performed outside maintenance windows, at least add some logic so that the client doesn't upgrade whilst it's running tasks like software installations, or add another maintenance window type for client upgrades. I don't know what state most of these clients are now in but it's not pretty.
Hmm, interesting points brought up below. If this is done during a MW that might interfere with ongoing updates/installations. So maybe we need another MW type or an option to only update a client outside of a MW? Or just internal logic that verifies that none of those activities are going on before initiating the update (maybe that's already a thing?)
Rich Newton commented
Most of our servers are under a blanket maintenance window which prevents the client from upgrading. For those servers we have to create a separate package and deploy it with the option to run outside of maintenance windows.
Paul Wetter commented
I had client updates hose my patch cycle last month for over half my servers. Why I haven't run into this before, dumb luck I guess. Until something is done with this, a custom deployment as bdam suggested, I guess. Or a strategic reconfiguration of maintenance windows maybe...
Automatic Client Upgrades honoring maintenance windows only can step on the Software Updates deployment, rendering them in a "Installing" state as the service is pulled out from underneath with an unfavorable recovery. A reboot does not seem to correct the status state of the deployment. Disabling the deployment; Allow policy to be revoked; Enable the deployment; This returns the Software Updates deployment to a Downloaded State but System is pending a reboot in most cases due to some or all of the updates having been successfully installed but the system not rebooted. Ugly to say the least.
Joel Holliday commented
Adding my voice to this request... we find ourselves having to create a custom client upgrade package just so that we can send the client servicing outside Maintenance Windows.