System Center Operations Manager by Jonathan Hambrook

September 11, 2007

Monitoring VMWare ESX using a SCOM

Filed under: Architecture, Microsoft, SCOM 2007, VMWare — opsmgr @ 1:53 pm

Monitoring VMWare ESX with SCOM isn’t a hard thing, however getting correct and relivent information in a clean and easy way can be. This guide I have compiled with VMWare should provide the mechanics of setting up monitoring between VMWare ESX and SCOM.

— UPDATE : If you have trouble with the link its due my limit being reached. I will add a secondary site ASAP. Wasn’t prepared for the responce —
Download Here:
Mirror 1
Mirror 2


May 10, 2007

Enterprise Operations Management Architecture Design

Filed under: Architecture, Microsoft, SCOM 2007 — opsmgr @ 9:36 pm

Below is an example of a design I have build and implemented it shows the data flow and the distribution of data and load to increase redundancy and distribute network load.

SCOM Solution Design

SCOM Data Warehouse Database Sizing

Filed under: Architecture, Microsoft, SCOM 2007 — opsmgr @ 9:25 pm

Data warehouse storage requirements can vary considerably depending on the data retention requirements so we would need more information in order to make any estimates.  As with the ops DB, the single largest factor in DW size is the amount of perf data that will be retained.  Since the DW will automatically aggregate performance data on an hourly and daily basis you can dramatically lower storage requirements by grooming out raw perf data aggressively and relying on the aggregated data for long-term trending reporting.

SCOM Operations Database Sizing

Filed under: Architecture, Microsoft, SCOM 2007 — opsmgr @ 9:24 pm

Sizing for the Ops DB is highly variable depending on which Management Packs are installed and what grooming policy is configured.  Without knowing the details of the deployment I can give you some “worst case scenario” numbers derived from an MSIT Management Group that manages 3000 servers and has all of the out-of-the-box MPs deployed along with 18 custom MPs and a 4-day retention policy (with the exception of performance signature data which is retained for just 2 days).  In this case MSIT allocated 60 GB for the Ops DB, of which they actually use about 35 GB.  Performance data accounts for about 75% of the total storage requirement with about 55% being used to store sampled performance data (which is retained for 4 days) and another 20% being used for performance signature data (which is retained for 2 days).  After performance data, collected events and monitor state change events account for the next largest category of storage used in the Ops DB with each accounting for about 10% of the total storage requirements.  Alerts account for about 1% of the storage requirement.  The remainder of the storage used is divided among a large number of tables with no other individual tables or data type accounting for any significant percentage of storage.  With over 85% of total storage requirements being derived from the above operational data I wouldn’t spend much time doing detailed calculations of storage requirements for other data types.  Unless you have unusual data retention requirements I would recommend using something similar to the MSIT storage allocation which will give you plenty of room for growth and some flexibility in adjusting data retention.

With regards to SQL log file storage requirements, the operational requirements are fairly trivial but you will want to allocate quite a bit more storage than required for day-to-day operations in order to cover the occasional need to delete Management Packs.  MSIT uses 16 GB for transaction logs in their 3000-server MG.  Under normal operations they rarely use more than a few hundred MB of this space (even while using the full recovery model with 15-minute log dumps) but much more is required on the rare occasions when large MPs need to be deleted.  A significant amount of data can be deleted in a single SQL transaction when large MPs are deleted.  MSIT has used up to 12 GB of log space while deleting some MPs.  I would recommend that you allocate a similar amount of storage to avoid any problems with full transaction logs when deleting MPs.

Blog at