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.
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?
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
Option to measure if node is successfully updated, before continue to next node.
- 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
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.
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.
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
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.
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.
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 window
pre/post must include powershell possibility