René Kierstein
My feedback
-
2 votesRené Kierstein
shared this idea
·
-
16 votesRené Kierstein
supported this idea
·
-
1 voteRené Kierstein
shared this idea
·
-
1 vote
What if we let you use scripts from the new scripts node in 1706tp?; and that had versioning; and multiple server groups could use the same scripts…. would that help here?
René Kierstein
commented
Is the original idea with server group dead or do you have an Update for to share with us?
Managing an Enterprise, we nede a nice Way to Update clusters
René Kierstein
commented
feature request:
Option to measure if node is successfully updated, before continue to next node.René Kierstein
commented
- Please also add the possibility to use a powershell function library
- Excuete script at local directory at the server being updated
- cmdlets, so a server group can be configured remotely. We will use a CMDB system to store server group info / configuration and will use this info to configure the group in SCCM
-
543 votesRené Kierstein
commented
I could add a requirement to be able to share Configmgr objects between tenants like: Applications, packages, os Images, global conditions, driver packages, base lines, custom reports etc.
in this way ISP could save a lot of work, being able to re-use objects.We have a setup like this where we have a "master site" from where we can migrate objects to tenants, using powershell and the build in migration engine.
-
1 voteRené Kierstein
shared this idea
·
-
18 votesRené Kierstein
shared this idea
·
-
616 votesRené 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.
René Kierstein
commented
You should consider to include following functionality and error checking:
What should happen if one server in a sequence fails updating? Should the sequence stop and perform a rollback and report the error.
(generally, the ability to rollback software updates deployed by SCCM would be nice)
At least make it possible to configure if the sequence should stop or continue in case of an error.Using scenario “Specify the maintenance sequence”
Each step should have pre and post script options, including error handling (return codes). This is required to be able to control if a cluster resource is successfully moved to another cluster node before continuing the update sequence
Make sure that the function works with both software deploy and Windows updates.Make sure that there are good logs. I can foresee some issue troubleshooting a failed update sequence if logging is missing.
Automated Support for patching SharePoint Farms (without having to take the entire farm offline)
Validate cluster services are online pre / post patching
Improved In-console Monitoring for patching critical servers like cluster > more detailed state messages sent back to server > state messages for critical server patching sent through with a higher priority (like the state messages for SCEP are)
Ability to configure alerts for cluster patching .
Ability to configure email enabled alerts for cluster patching failure / success
Ability to trigger Orchestrator runbooks as pre / post cluster patching actions
PowerShell cmdlets to configure cluster patching feature in Config Manager
-
18 votesRené Kierstein
commented
at least write back at state message, that explains the problem installing all patches
-
30 votesunder review ·
Admindjam
(Product Director, or Executive, System Center Configuration Manager)
responded
We’ve started doing work in this direction. Look in the Tech Previews for things called “cluster patching” that lets you orchestrate multi-machine patching.
René Kierstein
commented
The plan for supporting cluster aware patching could be extended with some more logic, so updating tiered solutions could be managed in a nice way.
-
20 votesRené Kierstein
supported this idea
·
-
34 votesRené Kierstein
commented
it's good idea
Should be extended with a check if there is a pending installation.
no need to run pre/post if there is no installation to be done in the maintenance windowpre/post must include powershell possibility
René Kierstein
supported this idea
·
With CB1806 and the new "currently logged on user", it should be possible to identify workstations with no logged on users, and then ignore maintenance windows.
so basically an deployment option to ignore MW, if currently logged on user is NULL or explore.exe isn't running.