Implement native cluster aware patching within SCCM to support cluster aware updating
Implement native cluster aware patching with SCCM to support cluster aware updating.
Preview shipped in Tech Preview
Juan Perez commented
I just noticed the link in the cluster manager. Having cluster aware patching, would be a great feature. It doesn't have to be automatic either, just as long as it can be started and let it run. Beats hanging around to do one at at time.
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.
Glen Harrison commented
Has this feature definately been killed off by MS? There's a post on technet from a guy saying he has had to point his hosts towards the internet for updates over configmgr. Unfortunately doing that means any sccm update reports won't show full complaince across the estate. Big no no for us as we need to prove all servers are patched.
As I can understand, this feature is abandoned.
It would be useful to:
1) implement availanility sets with update domains
2) implement pre- and post-update scripts running from run as acounts (it also possible to involve JEA approach)
any progress, this is still broken in 1802.
Desperately need this. Whats the hold up?
Is this feature dead or what? 2 years on and it's still in pre-release, no word anywhere about that changing, and it still doesn't work.
Benoit Machiavello commented
Same problem here. First computer in the group can patch. Each other never get updates with the status "waiting for lock".
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.
Tom Brisby commented
The server group functionality is nice, but I've been struggling to find any documentation describing what happens when deployments are applied to collections with this setting enabled. With no custom node drain or resume scripts applied, are the nodes simply rebooted without any sensitivity to the cluster resources? Are there any example node drain/resume scripts available? What I'd eventually like to see is a more true integration of Cluster aware updating and how that process proceeds with SCCM. Right now, SCCM can be used to select specific patches to place in a SUG and then deploy them, but using SCCM to patch clusters is still nebulous and feels..dangerous. Cluster aware updating is much healthier for the clusters, but doesn't have any connection to SUGs in SCCM meaning that WSUS has to be directly managed as well.
Any update on this please?
It would be prudent to 1. include basic documentation on use of feature 2. the feature does appear to be functional but has issues in 1606, tech preview for 1609 does not even mention this feature or improvements to it. 3. This feature should be a number one priority as it is a basic requirement for datacenter automation. 4. No new version preview or production should be released without updates to this feature which is currently broken.
I notice there are more features released in 1606, but the maintenance sequence list only populates in one of my environments... Is there a trick or step that I am missing, or is that a known issue?
Martin Wüthrich commented
the feature is shipped within the Current Branch 1602. Will there be some more information on the TechNet Pages?
Justen H. commented
Take a look at what Infront Consulting has to offer - OPAS; it's a great tool to addon to SCCM. It handles the patching of clusters and other applications or server groups such as web farms or Exchange DAGs - it SO easy to use and is becoming hugely popular.
A must have IMO: http://www.infrontconsulting.com/opas
Hi, I did try this out with a 2 Node cluster. The following happened:
allowed offline 51% - both rebooted at the same time
allowed offline 50% - both rebooted at the same time
allowed offline 49% - none of them rebooted: even though the restart windows indicated, that an automatic reboot will happen, after the grace period, nothing happened. both windows were showing 00s remaining, none of them rebooted.
Nicolas Vaneberg commented
What would be great, would be to be able to create one collection and all clusterer machines as members of it and that sccm could handle that in once. For the moment we need to create one collection for each cluster. I need to work with maintenance windows, so creating x collections + x maintenance windows is not feasible for me. For the tests I had with TEchnical Preview 3, it's a lot of work to configure and maintain it. One collection with all clusters and same maintenance window should be a very great improve. Else i'll continue with Orchestrator runbooks to handle the clusters patching.
René Kierstein commented
True, they talked about it at ignite, but the new feature must include better control with the cluster progress update than presented in the session.