So… it seems that Server Automation and Maintenance Windows (locking) don’t seem to play well together.
Maintenance Windows are a great tool for automating things like patching and other maintenance items. Action something once against systems with defined windows and they do whatever is pending in that window then lock back down. I’ve expanded on the idea and added logging, window approvals, Vm snapshots prior to window, etc using a custom lock override site so administrative tasks (Mw definitions, etc) run regardless of current lock. All works like a charm!
Enter Server Automation. I’d like to use SA for patching clusters, etc and utilize the same Maintenance Window functionality. So a cluster hit’s it’s maintenance window, runs the plan, etc…
But… SA and locks don’t play well… An SA Action to a locked system doesn’t just wait for the system to unlock. If fails the step.
It would be GREAT if SA had something in the way of - step 1 - wait for unlock.
Perhaps this can be accomplished with a fixlet as step 1 that does nothing except pause while locked in the action script? It seems this would not allow the enforce window fixlet (that unlocks the system) to run and I’d have a catch-22 situation.
I plan on doing some testing in my lab but was wondering if anyone else has run into this…
Hey Chad - so have you added your ‘unlock’ fixlet as the first step in the plan?
One option might be to schedule the plan to start at the beginning of your maintenance window and have it unlock the endpoints and run all the content before locking it again at the end.
I think what he is saying is that he wants the SA action to constantly be active but the actual “kick-off” to be controlled by the opening of the maintenance window since you can’t seem to schedule a repetitive schedule within SA.
Dutch is correct…
The whole point of Maintenance windows is that it negates the need for action these targets at this time and these targets at another time. The actions just sit there and wait with a status of locked until the MW time arrives. Which is nice as you can create a patch baseline and action it only once, and it patches dev systems on week 3 of the month, qa on week 4, prod on week 1, etc (just an example assuming patch Tuesday - week 2 - patches). Makes for an elegant system. One action and it follows proper lifecycle. No chance for errors as it’s the same action patching everything.
The trick is fitting SA into the mix for more complex items like clusters.
Chad, I was actually surprised when i started looking into SA that you can’t seem to schedule a repetitive action. I really like the fact that you can now monitor a site, drop in a (patch) baseline and it applies that baseline to any open action… but it doesn’t do me any good if I can’t control when…
Yea… Server Automation seems to be a bit of a first-gen tool. Pretty limited. I look at it like it’s essentially a dumb operator I can tell… run this fixlet and based on what happens, stop that fixlet and run this one. Great idea, but it’s certainly not “automation” if I can’t set a repetitive schedule.
I think if it had the ability to set a step parameter on what to do if locked (wait / fail), I could fit it into the mix much better.
FYI… Did some more testing on this… I was hoping that I could use a custom task with locked action parameters and use a constraint “In Maintenance Window” matches “yes”. But no joy. When the Server Automation Engine takes action on the task, it complete strips all constraints even when those constraints are locked in the task definition. And if I put it on the relevance, I’m sure the generated action would just say not relevant and pass that step… So… I can certainly find no way to make Server Automation and Maintenance Windows play nice together…