Some samples:
- Groups Reports:
- Database Usage (Operational Database & Data Warehouse):
- RunAs Profiles:
These Reports are all to be found in one MP. Before importing the MP a new Data Source in SSRS has to be created. The document, to be found in the same zip-file which contains the MP, describes how to go about it.
A good MP it is!
MP to be downloaded from here. (Free registration is needed before the MP can be downloaded. And as stated before: RTFM because an additional Data Source has to be created.)
6 comments:
This is useful. Only one problem with most of these reports, and that is the fact that they hit the operational database. The operational database is not intended to be used as a reporting data source for good reason, and that's why a data source must be manually created. Maybe the SSC author would consider using queries that hit the DW to bring this MP in-line with best practices. I have a good number of the DW queries on my blog for reference (http://blogs.technet.com/b/jonathanalmquist/archive/2009/04/25/operations-manager-2007-sql-queries.aspx).
Hi Jonathan.
Thanks for your feedback. As a matter of fact I know one of the authors of this MP. I will send him your comment so he can take a look at it. He is a busy man but also one who takes comments like yours very seriously.
Cheers,
Marnix
Jonathan, we were well aware of this fact, but also know that PFE's and consultants use queries against the operational DB every day to solve customer issues. We provided this to make that task easier and safer for all, as their very purpose in part was to provide 'top generators's type reports for the OperationsManager database as a troubleshooting tool.
In fact, many of these queries came from Kevin Holmans blog. While we understand best practices well, I would argue you are missing our intention here. We are reducing the need for admins to query the database manually...making this a safer operation when it is necessary.
I dont see these reports being written for "reporting purposes".
They are for health analysis. Totally different. Nobody is suggesting to do long term reporting for trending and capacity planning from the OpsDB. If you LOOK at the reports - they are to analyze the health and operations of the management group, and much of that MUST be gleaned from the OpsDB.
1. When the query has little I/O impact and completes quickly, there is very little (if any) risk of impact to operations.
2. Not all customers deploy the reporting/warehouse component, and therefore we MUST have OpsDB queries for these.
3. Not all data is written to both DB’s, so we should analyze BOTH in general. Event and performance inserts can be controlled to the OpsDB, Warehouse, or both. From a HEALTH perspective - you must look at whats in the OpsDB.
4. Some data can ONLY be gotten from the OpsDB... like OpsDB sizes, top tables, run-as information, statechanges not groomed, perfsig bloat, etc....
Hi Jonathan, Pete and Kevin.
Never ever I expected this posting to become a topic of discussion between many highly respected SCOM guru's. Nice it is since it gives an insight view of how people look at SCOM, what it is and isn't.
Also it underlines my statement that SCOM isn't a product which can be totally mastered and understood by a single person.
When I may add my two cents here, I personally believe that these reports are a great extension for every single SCOM implementation with Reporting already in place.
With a single click on a mouse button one can see what is going on.
For myself I have put this MP on my list of 'Must Haves', along side with the Scheduled MM Tool from Tim McFadden for instance.
Please feel free to comment since it really shows that this blog is about the community and FOR the community, like System Center Central.
So thank you all for taking time to comment. Much appreciated.
Cheers,
Marnix
With all due respect to the authors of these reports, and to Kevin Holman for creating very useful SQL queries to analyze health of the OpsDB, I want to say that this MP provides more value than causes any problems. I understand the intent of the reports, and I believe this is a "must have" for SCOM admins. I also understand that there are just some types of data we must query from the OpsDB in order to solve some of the trickier problems we run into. My intention was not to knock the reports, or anyone that contributed to them. I respect each one of you, and everyone here adds great value to the community. I only wanted to offer some input, so that the community realizes that almost all the data represented in these reports that are using the OpsDB as a data source can also be mined (with more history and just as much detail) from the Data Warehouse. This may be something to consider for future releases of this already very useful management pack. Keep up the excellent work!
Post a Comment