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
16 votesNoted · AdminMark Silvey - ConfigMgr Product Team (Admin, System Center 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
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.
FWIW, this was introduced in CB 1806.
1,887 votesstarted · AdminMark Silvey - ConfigMgr Product Team (Admin, System Center Configuration Manager) responded
I’m re activating this one based on the fact that we don’t show the intrusive reboot countdown after the software was installed. We still have some work to do here to make this experience meet the requested behavior.
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.