* locate "grey" hosts

* verify fixes for OpsMgr / Agents

 Daniele, The MS-delivered OpsMgr Health Check is a great service for Premier customers I have no doubt. I think we were envisioning something likely a bit less complex that would be available to the other customers (often in smaller environments) as an ad-hoc tool for assessing health. 

This would be great for community support scenarios and for customers outside the Premier support plans without budget for pro services engagements for assessing the health of the SCOM deployment.

 An OpsMgr Health Check Script should perhaps also include a check to find 1) any targeting mistakes (groups targeted instead of classes) and 2) If possible, any object discoveries created with a dangerously low  interval.  

I have been drawing more thoughts to the Health Check tool and have the following to add;

• We can check for a failed backup as well as a successful backup but we never monitor for the fact a backup is even being attempted.

• We also check the fact the Transaction logs are getting close to be full

• We could check that the SQL Server is setup correctly like Auto Grow is False etc

 An OpsMgr Health Check Script should perhaps also include a check to find 1) any targeting mistakes (groups targeted instead of classes) and 2) If possible, any object discoveries created with a dangerously low  interval. 

The second suggestion would really help.  Again today, I found yet another 3rd party MP running discoveries every 5 minutes on every server we manage.  It would actually be a great monitor or something.

for 2), Daniele Grandini's blog lists a few good queries for this

http://nocentdocent.wordpress.com/2009/05/23/how-to-get-noisy-discovery-rules/

OpsMgr Health Check Requirements Summary and Next Steps

Here's a categorized summary of your suggestions mentioned as important elements of an OpsMgr Health Check. Many of you already a quite a few scripts, queries (or links to them) in your posts. I've left the pointers out, as we have some additional round of discussion on the "what to check" before we talk about the "how to check".

I've put our names by your suggestions so we can ask one another for clarification or further justification if needed.

Next Steps

As a next step, I would suggest we;

• Take a look at the list below and identify any critical checks we think are missing.
• Ask the owner for clarirfication / justification if necessary 
• Throw out ideas on how this should be delivered (Powershell script, Management Pack, etc)

Result should be a refined list for which we can begin to review data collection options and discuss how to best deliver a report in an easily consumable format. Powershell seems a likely choice, but don't want to make any assumptions at this stage.

Respond to this thread with your additional thoughts, questions and suggestions

Categorized List of Your Suggestions

1. RMS / MS / Mgmt Group Health, Configuration and Connectivity

1.       Look for database latency - High count of event 2115 in the RMS / MS OpsMgr Event Log (Pete)

2.       Collect agent count reporting to each MS & RMS (Pete)

3.       Retrieve recent warning and critical events from RMS OpsMgr Event Log (Pete)

4.       Verify patch levels on RMS / MS (Ziemek)

5.       Check that the MP's are getting regularly updated from DB to RMS and from RMS to Management Servers.. (Sameer)

6.     Check if deployed MPs are up to date (Holger)

7.       Check for overrides in the Default MP (Matthew)

2. Management Pack Configuration and Versioning

1.       Check for targeting mistakes (rules and monitors  targeted to groups)  (Tommy)

2.       Check for object discoveries created with dangerously low intervals (Tommy)

3.     Query for all scripts, collect them, run them, catch the errors. The eventlog doesn't provide you with too much information regarding scripterrors. (Tenchuu)

3. SQL Database Health, Configuration, Maintenance  and Grooming

Configuration

1.       Check proper database sizing based on monitored server / device count (Pete)

2.       Check SQL configuration against supported configurations / best practices (Pete)

3.       Verify SQL Broker is enabled (Matthew)

4.     Check that the SQL Server is setup correctly like Auto Grow is False etc(Simon)

Operational Health

       1.   Check for a failed backup as well as a successful backup but we never monitor for the fact a backup is even being attempted. (Simon)

2.       Check the fact the Transaction logs are getting close to be full (Simon)

3.       Check Operational DB grooming history (Matthew)

4.       Large Table Query (Matthew)

4. Agent Health and Configuration

         1.   locate "grey" hosts (Ziemek, Matthew)

         2.   Verify patch levels on RMS / MS (Ziemek)

can help you guys out for sure. let me know.