Saturday, February 27, 2010

New Core MP for SCOM R2

Just came across two very interesting and detailed blogs by Marnix Wolf about the core MP update for SCOM R2.
Marnix really did a great job showing all what's new!

Part 1 - Core Monitoring Reports
http://thoughtsonopsmgr.blogspot.com/2010/02/newest-core-mp-for-scom-r2-new-road.html
Part 2 - Agent Management (nice!)
http://thoughtsonopsmgr.blogspot.com/2010/02/newest-core-mp-for-scom-r2-new-road_26.html

Configuring OperationsManagerDW grooming

Last week i did some maintenance on a Operations Manager 2007 R2 Data Warehouse. Because this piece of OpsMgr maintenance is sometimes 'forgotten', i thought it would be nice to blog about this.

After this initial deployment, there has not been much maintenance. Thanks to the integrated maintenance jobs through the Operations Manager 2007 internal management pack library and having enough disk space, no actual problems did arise.

You should, probably, know that an out-of-the-box deployment of OpsMgr 2007 keeps the collected information in your Operations Manager Datawarehouse for 400 days.

Using the sizing tools from Microsoft and from books like 'Unleashed' you can calculate how much disk space you would need keeping 400 days of historical information.
Also keep in mind the backup method you will need to use, because of the rather large database files. Always consult the Database Administrator for your implementation and maintenance plans.

When a company starts of with OpsMgr 2007 with a number of 500 agents and no known future company aquisitions no problems arise. But when that company begins to expand and more agents are becoming managed by this management group, you should really do some recalculation of the your database growth for your OperationsManagerDW as well as for your OperationsManager DB. There are some pretty handy built-in reports in Operations Manager you can use to see the daily growth. Also use the Operations Console Monitoring views to view the Database Size performance counters.

If you find that the current span of historical data is not right and has to be modified there a multiple ways for doing this.

The old way: Using a sql queries and stored procedure http://aquilaweb.com/blog/index.php?itemid=41
The new and easier way: Using a simple tool, dwdatarp.exe http://blogs.technet.com/momteam/archive/2008/05/14/data-warehouse-data-retention-policy-dwdatarp-exe.aspx

I prefer the new and easier way for obvious reasons :). I you don't want to wait for the next groom workflow, run the procedure 'p_partitioningandgrooming' on the SQL database.

Within the next two weeks i'll be performing a OperationsManagerDW relocation. Of course I'll post the details and my experiences with this actions. Note that a complete 'OpsMgr shutdown' is neccesary to do this, so your agents should be configured with enough cache memory to hold on.