Matt Goedtel on Operations Management : Operations Manager 2007, Configuration

ADMP and Tuning for Performance Reports

mgoedtel — Mon, 23 Feb 2009 04:27:00 GMT

The latest Active Directory management pack deployment guide has a small section entitled "Enabling or Disabling Performance Data for Reports" and it was generating some good dialog internally between some colleagues and the product group. This section recommends that you disable the Performance monitor for the class "Active Directory Domain Controller Server 200x Computer Role" in order to minimize performance data collection for reports. However, this is a base aggregate monitor that is basically responsible for reflecting the best/worse case of health relative to the state of the child monitors. It has no direct impact on controlling the behavior of the child monitors, nor performance collection in general.

If you really want to disable performance data collection because reporting is not important to you, then you should be focusing on the performance collection rules. They are denoted as such with the words "performance collection" in the name of the respective rule. Examples in the ADMP are:

AD Global Catalog Search Time Response Performance Collection
AD DC Performance Collection - Metric Memory Committed Bytes

If you want to disable performance alerts because you are not concerned with certain performance issues with your DC's (as you may already know these facts and don't want to be constantly reminded), then you should be disabling the respective performance unit monitor. Examples in the ADMP are:

AD DC Last Bind Monitor
AD DC Op Master Domain Naming Last Bind Monitor

Run As Profiles in Operations Manager 2007 R2

mgoedtel — Mon, 26 Jan 2009 05:36:00 GMT

One of the new features of R2 that hasn't received any attention yet (at least to my knowledge) is how we changed the functionality of Run As Profiles. Today in Operations Manager 2007, you associate a RunAs Account for a particular RunAs Profile on a specific computer. Pretty straight forward and if I remember correctly, the same as MOM 2005 (haven't touched it in some time so my memory is vague). When I was testing my custom ADMP (my lab environment is running on R2), I was caught off guard because I needed to associate a RunAs account with a RunAs profile as part of my testing, and it took me some time to figure out how to configure it correctly (since the on-line documentation for R2 was not updated to provide an appropriate level of guidance).

In Operations Manager 2007 R2, when associating a RunAs Account for a particular RunAs Profile, you can now target the the profile to any class available in Operations Manager and see the logical relationship between the two. Take for example a script that we run as a response to a monitor or a script that performs some level of monitoring against a SQL Server database. Instead of associating the profile with the agent, you can associate the profile with the database instance or the SQL Server Database Engine for that agent. So any workflow that requires running under a specific set of privileges in order to access the instrumentation correctly, you will be able to target the profile by group, object, and instance class. This follows the same logic as targeting a workflow today (monitors, rules, discoveries, tasks, etc.).

While today's management packs for Operations Manager aren't developed with this strategy in mind, by the time R2 comes out I would expect to see them supporting this.

Finished - SQL Log Shipping Configuration Guide

mgoedtel — Wed, 22 Oct 2008 03:24:00 GMT

I just submitted to Chris Fox for review and posting on the OpsManJam site, the guide "System Center Operations Manager 2007 Configure SQL Server Log Shipping Guide for Operations Manager 2007 Operational Database" that I have been working on in my spare time. This guide currently only covers the implementation of Log Shipping as an HA option for the OperationsManager (operational) database, not the Audit or Data Warehouse database, and provides guidance on configuring the secondary SQL Server and the management group when the primary SQL Server becomes unavailable. While I have reviewed similar documentation developed by others outside of Microsoft, I felt it necessary to ensure detailed guidance is consistant with our other published whitepapers. I am a stickler for consistency and detail, if you have not realized that already!

While I could have also covered the Data Warehouse and Audit database, it would have taken a bit more time and I felt I could add guidance for those two databases in a future version.

As soon as I see it published on the OpsManJam site, I'll post an update. However, I am sure you have RSS feeds enabled and will be notified accordingly.

Disk Space Requirements for the Operations Console

mgoedtel — Sun, 27 Apr 2008 06:31:00 GMT

When you launch the Operations Console on your workstation or even on the management server (or RMS for that matter), the data from the Operations Manager database is cached locally in the file "momcache.mdb." By default, the console will poll the SDK Service on the RMS every 15 seconds to update the local cache. Depending on the number of agent managed systems that are in the management group, potential size of the database will be (as indicated by the Product Group):

100 server deployment = 300 MB
1000 server deployment = 600 MB
5000 server deployment = 1 GB

The database file is located in %USERPROFILE%\Local Settings\MIcrosoft\Microsoft.Mom.UI.Console.

For my small lab environment with only 12 servers being actively monitored by Operations Manager with many core and custom management packs, the file size is 34 MB (as an example).

So if you are intending or are already hosting the console on a Terminal Server or Citrix Server, you will need to factor this in to ensure you don't impact the volume supporting other shared applications.