Windows LiveWindows Live™
 
 
Operations's profileOperations ManagerBlogLists Tools Help

Blog
    3/29/2007

    Where are those management packs?

    For those of you who are trying to get a head start with Operations Manager 2007, we have noticed some confusion when trying to load management packs.
    On the mangement server, there is a management pack directory. However, those management packs are already loaded into the Operations database.
    On the installation media itself, you will find a management pack directory, e.g. \ManagementPacks. From there you can import management packs for:
    • Exchange Server 2003
    • Information Worker 2003, Information Worker 2007
    • SharePoint Portal Server 2003
    • SQL Server 2000, SQL Server 2005
    • System Center ASPNET 2007
    • Windows Client 2000, Windows Client XP
    • Internet Information Services 2000, Internet Information Services 2003
    • Windows Server 2000, Windows Server 2003
    • Windows Server 2000, Windows Server 2003 (Active Directory)
    • Windows Server AD Client Monitoring
    • Terminal Services 2000, Terminal Services 2003
    • SharePoint Services 2000, SharePoint Services 2003
    Here's something nice Microsoft built into the management pack import process: f you try to import a management pack when one already exists with the same or later date, you will receive an error and not be able to import it.
    11:34 PM | Add a comment | Permalink | Blog it | Operations Manager 2007
    3/24/2007

    What's the big deal about MOF?

    If you look at Microsoft's website these days, there are several indications (unrelated to various trade rag articles about it back in January) that the release of Operations Manager 2007 may be imminent. First, you can look at Microsoft's Management Pack Catalog (http://go.microsoft.com/fwlink/?linkid=43970) to see a search category added for Operations Manager 2007 management packs. Second, if you are signed up for the OpsMgr 2007 beta, the Connect website shows a new document named OpsMgr_RC2_to_RTM_Upgrade.doc, dated March 23.
     
    If you have read any of the advance datasheets or whitepapers for Opsmgr 2007, you will notice discussions about model-based monitoring and MOF. What's the big deal about MOF?
     
    More than just another TLA (Three Letter Acronym), the Microsoft Operations Framework is geared towards managing Microsoft technologies. It is a structured methodology used to describe IT operations, and Operations Manager is a tool to implement that framework using model-based monitoring.
     
    At its core, the MOF is a collection of best practices, principles, and models. The MOF Process Model includes four quadrants:
     
    • Changing - representing instances where new service solutions, technologies, systems, applications, hardware, and processes are introduced.
    • Operating - concentrates on performing day-to-day tasks effeciently and effectively.
    • Supporting - respresents the resolution of incidents, problems, and inquiries, preferably in a timely manner.
    • Optimizing - focuses on minimizing costs while optimizing performance, capacity, and availability in delivering IT services.
    Now let's think about Operations Manager. It is a tool that incorporates model-based management, and best practices and principles as incorporated in its knowledge base and rules. How does that tie in with the quadrants of the MOF Process Model?
     
    • Changing - as you add new components to your environment, you should investigate whether a Microsoft or third-party management pack is available to monitor that particular applicatoin, system, or hardware solution (if not, you can always define your own, building a model that describes the "vital signs" and monitoring attributes of that application).
    • Operating - Operations Manager includes operational tasks that can be initiatated from the Operations console. These tasks are loaded into the Management Server with various management packs, and you may also define your own tasks.
    • Supporting - Operations Manager is all about monitoring daily operations. Using management packs, one can interpret and act on information gathered from each monitored component to resolve difficulties.
    • Optimizing - by using Operations Manager to minimize your downtime and keep your operations running smoothly, you are able to minimize operating costs and reduce system outages which ultimately will cost your company money!

    Even more than its MOM 2005 predecessor, Operations Manager 2007 incorporates principals of MOF, model-based management, DSI, SDL, and XML thoughout. DSL focuses on automating data center operational jobs and reducing associated labor through self-managing systems. SML, which is based on XML, can be used to create a blueprint of a system, defining system elements and capturing data pertinent to development, deployment, and operatons - making that model relevant across the entire IT life cycle. OpsMgr 2007 captures knowledge through models, putting that knowledge in a structure that the software can act on. By incorporating models and methods for monitoring within its mangement packs, Operations Manager 2007 uses a structured approach to determine if there are situations requiring attention.

    Operations Manager is more than just an upgrade to MOM 2005, as it is a complete rewrite. What's new in OpMgr 2007? That would be a really long blog entry! We look forward to its release and will keep you updated with future articles about OpsMgr 2007.  

    1:21 PM | Add a comment | Permalink | View trackbacks (3) | Blog it | Operations Manager 2007

    MOM 2005 Reporting - Grooming and Shrinking the Reporting database

    How to Groom and Shrink a Reporting database

    We had a MOM 2005 reporting database which had not been archiving correctly and had grown to the point that there wasn’t enough free disk space to run the grooming process, due to increases in the size of the log files. Based on business requirements and hardware constraints the decision was made to trim down the content of the reporting database down to 35 days from what was originally data that was more than 500 days old. The original database size was approximately 55 GB with no free space, after successful grooming it was moved down to .5 GB (prior to re-activating the DTS package to transfer from the Operations database to the reporting database).

    To accomplish this, we took the following high level process (all scripts referred to are included in full below):

    1. Identify the count of each of the 6 fact tables using the "Table Count" script, and keep track of those statistics going forward.
    2. Identify the oldest data in the tables using the "Oldest Date" script.
    3. Determine the date difference between the oldest date and the current date with the "Date Diff" script.
    4. Set the grooming interval to higher than the highest date using the "Set Grooming" script. This is done to ensure the grooming process will work as long as there is no data that needs to be groomed.
    5. Verify the change tot he grooming settings with the "Check Grooming" script.
    6. Start the reporting grooming job (called SCDWGroomJob) in the SQL Agent jobs section of the SQL 2000 Enterprise Manager.
    7. When the job (hopefully!) succeeds, run the "Truncate Log" script to free up some of the transaction log space.
    8. Change the grooming setting to slightly less than the highest difference so that the next grooming job will be configured to actually groom out data.
    9. Re-run steps 5 though 8 for the new setting.
    10. Continue this process with decreasing values (the oldest data in the database we were working through was 508 days!). For that particular environment we were grooming settings which decreased from: 700, 500, 400, 350, 275, 200, 125, 35.
    11. Finally we were able to decrease the size of the reporting database through the "Shrinkfile" script.
    12. Last, w reactivated the scheduled task to move data from the Operations database to the Reporting database and started growing the data again; but this time up to a maximum of 35 days.

    Fact Table Statistics:             700 Days         400 Days         350 Days         275 Days

    AlertFact                                          715                  715                 715                  715
    AlertHistoryFact                            32,184             27,919             21,481             15,748
    AlertToEventFact                          38,969             34,123             27,609             21,151
    EventFact                                4,415,065         4,291,870        4,079,922         3,862,984
    EventParameterFact                    828,708           828,708            828,708            828,708
    SampledNumericDataFact      152,648,971     138,060,142     121,863,087       98,431,535

    Fact Table Statistics:             200 Days         125 Days          35 Days

    AlertFact                                          715                  715                  26
    AlertHistoryFact                              9,234                3,051                   1
    AlertToEventFact                          17,230                8,467                   5
    EventFact                                3,752,214          3,022,275             3,625
    EventParameterFact                    828,708             828,708             3,315
    SampledNumericDataFact        87,401,639        47,819,874          413,745


    Scripts

    Check Grooming

    This script checks the current state of the grooming settings.
     
    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs
    Join classschemas cs
    On cs.cs_classID = wcs.wcs_classID
    Where cs.cs_tablename = 'SC_AlertFact_Table'
    And wcs.wcs_mustbegroomed = 1
     
    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs
    Join classschemas cs
    On cs.cs_classID = wcs.wcs_classID
    Where cs.cs_tablename = 'SC_AlertHistoryFact_Table'
    And wcs.wcs_mustbegroomed = 1
     
    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs
    Join classschemas cs
    On cs.cs_classID = wcs.wcs_classID
    Where cs.cs_tablename = 'SC_AlertToEventFact_Table'
    And wcs.wcs_mustbegroomed = 1
     
    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs
    Join classschemas cs
    On cs.cs_classID = wcs.wcs_classID
    Where cs.cs_tablename = 'SC_EventFact_Table'
    And wcs.wcs_mustbegroomed = 1
     
    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs
    Join classschemas cs
    On cs.cs_classID = wcs.wcs_classID
    Where cs.cs_tablename = 'SC_EventParameterFact_Table'
    And wcs.wcs_mustbegroomed = 1
     
    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs
    Join classschemas cs
    On cs.cs_classID = wcs.wcs_classID
    Where cs.cs_tablename = 'SC_SampledNumericDataFact_Table'
    And wcs.wcs_mustbegroomed = 1
     

    Set Grooming

    Set the grooming date on each of the six fact tables. The last number will vary depending on what the grooming interval needs to be configured for.
     
    Exec p_updategroomdays SC_AlertFact_Table, 700
    Exec p_updategroomdays SC_AlertHistoryFact_Table, 700
    Exec p_updategroomdays SC_AlertToEventFact_Table, 700
    Exec p_updategroomdays SC_EventFact_Table, 700
    Exec p_updategroomdays SC_EventParameterFact_Table, 700
    Exec p_updategroomdays SC_SampledNumericDataFact_Table, 700
     

    Table Count

    Identify the total number of records in each of the fact tables for later comparison.
     
    select count(*) from SC_AlertFact_Table
    select count(*) from SC_AlertHistoryFact_Table
    select count(*) from SC_AlertToEventFact_Table
    select count(*) from SC_EventFact_Table
    select count(*) from SC_EventParameterFact_Table
    select count(*) from SC_SampledNumericDataFact_Table
     

    Oldest Date

    Identified the oldest data in the database through the following queries: (very slow to run).
     
    SET ROWCOUNT 2
    select DateTimeLastModified from SC_AlertFact_Table order by DateTimeLastModified
    select DateTimeLastModified from SC_AlertHistoryFact_Table order by DateTimeLastModified
    select DateTimeAlertAdded from SC_AlertToEventFact_Table order by DateTimeAlertAdded
    select DateTimeGenerated from SC_EventFact_Table order by DateTimeGenerated
    select DateTimeEventStored from SC_EventParameterFact_Table order by DateTimeEventStored
    select DateTimeAdded from SC_SampledNumericDataFact_Table order by DateTimeAdded
     

    Date Diff

    Based upon the results of the oldest records, identify the oldest date in the database through using a difference in dates (the first date is the oldest date found in the fact tables)
     
    select datediff (day, '2005-10-27', getdate())

    Truncate Log

    To clear out the SystemCenter Reporting log files.

    BACKUP LOG SystemCenterReporting with TRUNCATE_ONLY

     

    Shrinkfile

    To shrink the reporting database.
     
    dbcc shrinkfile(REPLOG,2)
    BACKUP LOG SystemCenterReporting WITH TRUNCATE_ONLY
    dbcc shrinkfile(REPDATA,2) 

    12:45 PM | Add a comment | Permalink | Blog it | MOM 2005