@ITrooster, I'm fairly certain that the cert requirement is because in order for ConfigMgr to manage the update signing cert it needs to move private keys around. You don't want that done outside of a secure/encrypted channel. I'd be happy to be wrong though.
No votes but sign me up for this one. If the team is looking to use the power of the cloud to give you insights into your environment this seems like a no-brainer to me.
Check it out in 2002 Technical Preview https://docs.microsoft.com/en-us/configmgr/core/get-started/2020/technical-preview-2002#bkmk_ssu
It appears that my earlier UVI got merged into this one. Though similar they were not the same in the technical details that matter.
Just again this month (May 2019) Microsoft released updates that required the same month's SSU be installed. In this situation this UVI won't matter: only the SSU will be detected as applicable. The solution is to run a software update evaluation after _all_ updates have been installed to see if any new one are now available. The product currently has a setting to do that after reboot but the SSUs don't require a reboot.
TL;DR: We need to run a software update evaluation after all updates are installed regardless of reboot.
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.
@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.
The recent Servicing Stack Update released out of band in May was made a requirement for the June cumulative updates but itself did not require a reboot. This created a conundrum for organizations patching devices with maintenance windows. Because of the lack of reboot on the servicing stack update there was no option to run a full evaluation that would detect that the cumulative update was now applicable and install it within the same maintenance window.
A few ways to solve that problem but the one that strikes me as straight forward is to modify, extend, or duplicate the "if any update in this deployment requires a system restart, run updates deployment evaluation cycle after restart" feature introduced in CB 1606 to allow it to run a full evaluation after all of the updates have installed, regardless of the reboot condition. Where maintenance windows allow this would enable the user to install updates that are newly available regardless of reboot.
Bonus Points: Support an option that does so even if the updates fail. So many times simply retrying an install solves the problem.
Yes please! There's so many poorly written queries out there. Even if you know to use indexed fields ... how can you know which are and which aren't?
Related to this, we should put some kind of preview function that gives results and timing for queries. If we want people to write more efficient queries then let's give them to tools to do so.
A picture says a thousand words, I should have included this from the start
This feature was introduced in the product in 1802 and came out of pre-release in 1806: https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-phased-deployment-for-task-sequence
283 votesNoted · AdminMark Silvey - ConfigMgr Product Team (Engineering Manager, ConfigMgr, Microsoft Endpoint Configuration Manager) responded
Thanks for the feedback!
I forget when exactly but at some point in the Current Branch releases I believe this was implemented.
Yep, you've got the column there ... but it's never populated.
Agreed. There's already a few UV items for downloaded/deployed. Expired updates by definition cannot be deployed and an ADR cannot select them as-is.
Tom, when used by ConfigMgr WSUS does not download updates content. At least, it should be. If it is then you have a mis-configuration somewhere along the line.
That being said, ConfigMgr _will_ store the content twice by design. First in the source folder for your (update) deployment packages and then again in the content library. The later is single-instance-storage but it's at the file level so you aren't going to gain much, if anything, with updates.
Another area I'd like to see these used is the Server Group patching pre and post scripts.
Ok ... but the whole point of Phased updates is to make the phases based on reaching some kind of success/fail. If you want to make it based on date ... use normal deployments? What, specifically, are you looking for here that normal date-based deployments don't do?
Welp ... someone's gotta say it: this is fixed in the latest release.
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
FWIW, this was introduced in CB 1806.
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?)