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.
Sean Culligan
shared this idea
19 comments
-
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
-
Jeff
commented
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:
https://enterinit.com/sccm-client-package-for-osd-deployment/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.Happy :)
Microsoft, we still need this feature, and preferably, at least 2 more maintenance window types: Client Upgrade, and Application Deployment maintenance windows.
Thanks.
-
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??
-
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.
-
Anonymous
commented
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.
-
Calum
commented
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. -
bdam
commented
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...
-
LoveHate-ConfigMgr
commented
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.
-
Ray Rosen
commented
Please consider adding a check box to "Ignore Maintenance Windows" in the feature dialog box that sets OverrideServiceWindows=TRUE on the hidden advertisement.
-
Jeremiah Abbott
commented
I mentioned something about this at MMS 2017 during a NoF session. I'd like to see an additional Maintenance Window type added for Client Upgrade. Our environment uses maintenance windows pretty heavily, but there are some devices that do not get routine maintenance windows. It would be nice to be able to apply something specific for the sake of AutoUpgrade.
-
Austin WongCarter
commented
Or we could add a maintenance window just for Client upgrades, but there needs to be a way to control it.
-
bdam
commented
Yes please. It's pretty common to have a non-repeating maintenance window to prevent anything happening on certain devices. At least, any deployment that doesn't explicitly override the window. Any devices in such a window will never apply the automatic upgrade. Further, you cannot add custom deployments to the client packages so the only recourse is to create your own.
-
Koenraad Rens
commented
To me it seemed strange this used the maintenance window.
We are upgrading from 1511 to 1607 and using the automatic upgrades for the first time. We gave the upgrade 14 days.
Clients wait until the maintenance window. But at that moment ccmsetup only creates the Upgrade Task which will be started somewhere in the future. It didn't seem this task respected the Maintenance Window.
In our site with maintenance windows once every week, most upgrades will be started at the end of the 14 days period. -
Travis Adams
commented
Or to expand on this, have the ability to target where and how the upgrade will happen. Id like to give a heads up to a geographical location (hey St. Louis you are going to be upgraded over the next few nights). It would help out for ongoing deployments, to steer clear of those sites while a client upgrade is happening.