But a certain set of servers must NOT be monitored on SQL level since that is done by another company. However, all other components on those very same set of servers must be monitored by SCOM R2 none the less. And to make things a bit more challenging, all other SQL servers present must be monitored by SCOM R2.
So how to go about it? There are multiple approaches available here. But personally I believe in taking care off it at the source and not at the end. Why? It is better to keep the SCOM Console clean of any SQL related Alert from that certain set of servers instead of having the Console displaying anything that the Operators are told to ignore. That is really some noise any SCOM environment can do without. Also it will cause unneeded data in the SCOM R2 databases.
Some MP Theory
(very shallow it is, I know…)
As we all know, any MP starts with some or more Discoveries. These Discoveries detect all MP related components/classes/objects and populate the MP related Groups. Against these Groups is all the monitoring targeted. (This is a huge simplification about how a MP works but this is all we need to know for this blog posting).
Actually, when the Discoveries do not find any SQL server of that particular set of servers, never ever will SCOM R2 monitor any SQL related aspect of those servers. So never ever will a SQL related Alert be raised for them. Time to disable the Discovery of any SQL related component on those servers.
This is what I did:
- Created a Group which is dynamically populated with ALL Windows Computers except for the set of servers which must not be monitored (the naming convention used for the servers allowed for an easy to use formula.) ;
- Disabled – one by one – every Discovery targeted against SQL 2005 and SQL 2008, targeted against Windows Server (For all objects of class: Windows Server);
- Started the PS extensions for SCOM R2 where I ran this cmdlet: Remove-DisabledMonitoringObject. This empties all Groups which have been populated by the in Step 2 disabled Discovery;
- Enabled explicitly the Discovery with an override where used the Group (Override > For a group…) created in Step 1.
- Reran Steps 2 to 4 for every SQL related Discovery.
After some time the SQL Server Views in the SCOM Console dropped all SQL Servers of that particular set of Servers. All other SQL Servers returned neatly in those very same Views.
6 comments:
Hi Marnix.
I want to start with saying you have a great blog!
I might have missunderstod this post but isnt it easier to create a group for the servers that ar not supposed to get discoverd and then disable the discovery for that group?
Hi Snajgel.
Thanks for the compliments! Much appreciated.
What you propose is another viable approach as well. However, since the Discovery has to disabled in order to empty the related groups I have chosen to leave it like that and enable it only for the dynamically populated group not containing the specific set of servers.
But again, your approach is viable as well.
Cheers,
Marnix Wolf
How do I stop existing sharepoint 2010 servers from being discovered. I have many servers we need turned off?
Hi Robin.
The approach as described in this posting doesn't work?
Cheers,
Marnix
Hello,
Thanks for your post. Isn't it more easy to make an override and disable for a specific object of the class. Or perhaps your method is more relevant for a lot of object where the discovery should be disabled.
Thanks.
Question - which discovery did you target? The DB Engine or the DB Installation Discovery Source (Installation Seed)?
Post a Comment