Not sure when it made it in but 1810 has phased deployment for software updates.
This is the one thing keeping my organization from being able to adopt modern management in our environment and is really hurting our cloud adoption. (Try not to think about that too hard or it'll hurt.) Why even bother developing the product if this isn't included?
Further, along the same lines. The other thing that nearly always failed was for the installation process to verify that all components/roles had been stopped. Every. Single. Time. SQL would fail to go into single user mode because there were active connections to the DB and thus the upgrade would fail part way through.
AMEN Christopher. In our org our DBAs (who really are great, we love them) wanted a service account for the install versus using my own account. Makes migrations much easier when the DBO isn't an account that is no longer in AD. As a result, almost all of our initial upgrade attempts failed for one reason or another. So please enhance the pre-req check to look for all the necessary permisssions needed. Just today my TP upgrade stalled for hours before failing b/c it wasn't a local admin on the stie server. Had to dig into the logs to figure out it couldn't create a folder due to lack of permissions. This just seems like a very straight-forward thing to add.
For reference, all of this and more: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/accounts#site-installation-account
What you're looking for is the Update Reset tool released in CB 1706: https://docs.microsoft.com/en-us/sccm/core/servers/manage/update-reset-tool
This more or less a dupe of this: https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/34608748-run-software-update-evaluation-after-updates-have
The patches _do_ apply in a determinate order. If the metadata for a CU requires a SSU then the CU will not be applicable and therefore not be offered for install in the first place.
FWIW, this was introduced in CB 1806.
1,854 votesstarted · AdminMark Silvey - ConfigMgr Product Team (Admin, System Center Configuration Manager) responded
Updating to started since this just shipped in the 1902 technical preview.
Part of the problem for us is that a lot of people have multiple screens these days. Power users will have their laptop as their 'main' monitor for email/IM and then two for actually getting work done. The various notifications appear only for a few seconds and in their periphery vision. To be perfectly honest, not sure what the best solution is, we just need the option to make it more intrusive.
While this UV focuses on the reboot experience I'd like to suggest this applies equally, or even more importantly, to the 'you have updates available' notification. We want to be WAY more in your face with those to encourage the user to trigger the updates when it's convenient for them ... which eliminates the whole reboot problem all together.
As far as I'm aware, there's no dependency on the endpoint being an actual server OS let alone one in a cluster. You can treat any device as if it was a group or cluster. Unfortunately, the feature is just straight-up broken.
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?)
Preview shipped in Tech Preview
It'd be nice to have something official from the product team on this but I'll try and faithfully represent what I've heard djam say about this.
This feature is not dead, otherwise it wouldn't be in the product anymore.
The product team believes the GUI makes it nearly impossible to configure correctly (something something 'maintenance windows'). I'd like to get some clarification on this because I worked for a long time and reached a Sr Escalation Engineer who couldn't help me configure it correctly. He simply did some very quick tests and called it 'broken' (see bug reports below)
The plan is to fix the GUI and re-write the back-end to ride over the BGB/Fast Channel used for the scripts and CMPivot features. Hopefully that fixes the locking issues and might even lead to some interesting reporting (dashboards dangit!)
Remember, I'm just some rando guy on the internet but the scuttlebut is that they hope to work on this for 1810.
Just closed a month-long case with Premier support. I think it's fair to say that as of CB 1706 this feature just doesn't work the way it is designed to.
Now that we have the 'Run a PowerShell Script' option it seems pretty obvious to use that feature here for the node drain scripts. That should fix the 512 character limit. Additionally, I hope it would make sense to then add a run-as feature to use service accounts for thinks like Exchange and SQL where workloads need to be moved and the local system isn't going to have that kid of access.
For those looking for documentation: https://docs.microsoft.com/en-us/sccm/sum/deploy-use/service-a-server-group
I just tried using this for the first time in 1702 and it would appear the script is limited to 512 characters. I have difficulty believing that's going to be enough. I had to condense and cheat just to get a script to run scheduled tasks.
Which raises another suggestion here; we need to be able to run the scripts as a particular account. The machine account shouldn't have access to move Exchange/SQL resources.
This applies to package deployments (advertisements) as well. Log the other user out and the package deployment shows up.
This is already possibly using Microsoft Desktop Optimization Pack (DaRT).
@Hermann, I agree, integrating the SSU into the CU is the better solution but it's not one the ConfigMgr product team can do. Since the SSU updates the mechanisms used to install the CUs who knows if that's even technical possible.
I'm not sure I understand your endless loop comment though. The loop will end when either the maintenance window finishes or all applicable updates are installed. To clarify, we're not talking about full evals after _each_ update, just after _all_ the updates have been installed.
Phase 1 of these feature is in 1602 production
As Tony Peters calls out, the 'Show Collections - Advanced' is basically a killer feature. No ConfigMgr admin should be without it.
Beyond that, I would love to see some content routines. For example: redistribute content to failed DPs for either a specific piece of content or globally.
I think this would need to be a client settings. I know that more than a few organizations intentionally leave this enabled so that users can directly scan and updated against Windows Updates. One of the more rational reasons is to allow security to be at the bleeding edge and to manage themselves that way yet still managing to make sure updates are applied and reported.
Check out the new uninstall behavior in 1804 tp.
Not quite sure TP ability lines up with this UV item. The UV is asking to uninstall when no longer targeted by a deployment. The TP uninstalled when an approval is denied/revoked. Those strike me as totally separate.