Revamp ConfigMgr's cluster patching, and remove it from PreRelease
Cluster patching feature was added in #SCCM CB 1602, but has been in prelease for a long time. It needs to:
1) Have improved/revamped UI
2) Remove dependency on collections
3) Orchestrate patching for any machines, not just servers/clusters
4) Remove the feature from prerelease
Nudging this to started again… as there are even more updates in #MEMCM 2001.2 and 2002 tech previews.
Levi Stevens commented
Please note there are also bugs, you cannot have more than one "Server Group" with sequential patching. I reviewed the SQL stored procedure code, multiple groups step on top of each other on the sequencing.
Also, the pre/post script boxes is too small, I had to call a script from a share. It would be ideal to point to a script in a package and have the SCCM client download and cache the script locally.
peter kluver commented
Looks like 1902 has this feature called "Server groups", however it is still in Pre-release. Any idea in what feature SCCM version it will be brought to release status?
Device Availability Groups are coming soon that will replace the old server groups (while DAG was the name chosen at MMS, if DJ gets his way it will be called Machine Orchestration Group, so keep an eye out for either name).
Dani Kuci commented
Just upgraded to 1810, SCCM is still cluster-ignorant. When will this feature be introduced?
John Storbeck commented
It would be nice to hear from Microsoft, or is this a victim of Azure Collective?
Still waiting on this feature to work 3.5 years later
This should have included direct connection to SCVMM or Hyper-V clusters to call that native Window Cluster Aware Update function. I get that for SQL and Exchange there would be some custom scripting required but for Windows and Hyper-V there are already built in CAU feature and triggering that process via PowerShell does not always deal with node drain correctly.
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.
[Deleted User] commented
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?