I just got done with my previous post on setting maintenance mode for a group of objects, and I happened to check Boris Yanushpolsky's blog. Bori's blog is an outstanding reference for various Command Shell scripts, and I have to give him credit for helping me come up to speed on several concepts. Turns out just tonight put up a script for....yep, you guessed it....setting maintenance mode on a group of objects.
As it turns out, I spent more time getting the script to run in a management pack, using overrides, etc. The script that Boris did is more complex than the one I did by putting computers into maintenance mode along with their health service. If that one fits your requirements better, than it should take all that much effort to move it into my sample management pack. Just a matter of pasting the script code into my write action and swapping around some script arguments.
Brian a great post and it looks like a very innovative solution. I will be trying this out hopefully today. A question for you. Instead of providing what looks like an instance of a server object in the group for maintenance mode is it possible to use some other class object that is a little more discreet? What I'm looking for is the ability to put a single monitor or rule or a grouping of monitors/rules into maintenance mode for a given server.
Any target that has Command Shell installed should work fine. I just went for a class hosted on the RMS because I was relatively sure that would have Command Shell, and I'm guaranteed that there is only one. I could come up with a variety of alternative targets based on different requirements though.
Brian, I'm not sure if the previous post was meant to address my concern about putting a discrete monitor in maintenance mode. If so I am confused as to how it applies. I tested the sample MP and it works fine but when I try to remove a server object from the maintenance mode group I get an error in the UI and this associated event log entry:
Event Type: Error
Event Source: OpsMgr SDK Service
Event Category: None
Event ID: 26319
Time: 3:37:57 PM
An exception was thrown while processing PerformGroupMembershipDiscoverySnapshot for session id uuid:d52ffdb1-ed85-421f-8088-31b6c04c022a;id=98.
Exception Message: The creator of this fault did not specify a Reason.
Full Exception: System.ServiceModel.FaultException`1[System.InvalidOperationException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to System.InvalidOperationException: A membership rule for the target "bwren.MaintenanceGroup1" failed with the following error: "Invalid column name InstanceName_97408C11_D1C8_5BCE_EF78_74F0473964F3 for query MTV_SelectProperty_8745931a-1e36-47cc-a609-191635d1c319." There are two common conditions that could cause a membership rule to fail, 1) a cycle was formed by having two groups contain each other, 2) the monitoring relationship class used is incompatible with either the source or target monitoring class. Please review and correct the membership rule to avoid further failures.).
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Misunderstood the question. You can use any monitored object in the group. The script doesn't distinguish at all what kind of object it's setting maintenance mode for.
Looks like a UI error related to maintaining the group membership. It wouldn' have anything to do with the rule or the script since that just reads the group in order to determine with objects are members.
You can certainly create a new group and specify that in the GroupName parameter on the rule.
Anyone else seeing this problem?
I'll have to investigate the class hierarchy in more detail. I suspect I will be limited to the granularity Microsoft provides in their class implementations for their management packs. For my custom applications I will need to create my own class structure to provide the level of granularity required.
A couple more questions for you.
Q1) What is the best way to scale this solution out?
I can add additional groups and rules to the sample pack you provided but what if I need to provide maintenance mode to separate organizational entities? If I clone the pack do I need to copy over the discovery? I think not as long as the proxy object is discovered once by the first pack I should be good. Perhaps I should have a separate MP just for the discovery and then all the maintenance mode packs will be the same.
Q2) What needs to be done to accommodate failure of the RMS and subsequent promotion of a secondary management server to RMS status?
We probably will have powershell and command shell on at least the RMS and an alternate management server for contingency. I can through overrides only target one specific object of the proxy so for normal operations it's not an issue. In a failure situation we would have to manually update the overrides so that the maintenance mode script runs on the new RMS. This may be beyond the scope of this blog but designing for continuity would be a great topic for what might be a series of posts.
Q1) If you mean separate management groups, you would need to copy the MP into the other one. That would be a completely different installation so it would need its own discovery for the Command Shell Proxy.
If you're talking about a single management group but just another rule/group, then you can target the same Command Shell Proxy. That was the point of that class - to give me a single target to run any of those Command Shell scripts against.
Q2) While I didn't test this at all, it should work fine if we promote another machine to RMS. The Command Shell Proxy discovery is just running against the RMS class. I'm going on the assumption that OpsMgr will identify the new RMS. The next time that the Command Shell Proxy discovery runs, it would run against the new RMS and be rediscovered there.
Thanks for the response. For Q1 I was thinking about the same management group. If I have multiple management packs for maintenance mode they don't all need to have a discovery module. Correct? If so I should probably have a maintenance mode library pack which just specifies the discovery routine and class definition. The class can then be targeted by multiple maintenance mode packs for the various support teams/organizational entities.
Brian, BTW I've created a vbscript to add additional groups and rules to the initial MP as required. Using this approach I can extend the MP to satisfy whatever requirements may come up and have the group and rule names be more descriptive/specific.