Matt Goedtel on Operations Management : MOM 2005

Release Management 101

mgoedtel — Mon, 28 May 2007 03:48:00 GMT

Commonly I come across a scenario with customers where they focus on implementing MOM/OpsMgr, yet do not think about process in relation to the tools. A prime example with Operations Manager or MOM is with Management Packs and Release Management - Plan, Build, Test, Review and Deploy (simply speaking). You can't just simply download a Management Pack, import it into your management group, and then expect it to go off and begin monitor your environment (Lets face it, there will be some level of inaccurate alerting that will occur even though the developers have tuned it to minimize "noise"). And why? Because everyone implements technology differently out of the box - customizations, tightening security, etc. Therefore, some level of tuning needs to occur before you "release" it into production.

From a Release Management perspective, you need to:

Plan the release - identify who needs to be involved in the release (teams and roles), the schedule, the project plan (if necessary), what's affected, documentation, etc. Review the deployment guide that accompanies the Management Pack, and prepare to test it in a lab environment.
Build the release - Develop the process, tools, and technology required to release into production. Here you are going to determine how you are going to deploy the Management Pack into production, which typically is importing it on a Management Server in the management group or use an automated method from the command-line or SDK. This could be the default MP and/or custom MP (depending on the situation).
Test - Once you have the build package developed and accepted, you then need to test the Management Pack and tune it based upon your requirements. The changes you make to the defalut MP should be saved in a Custom Management Pack to avoid those changes being overwritten when you import a new version of the MP (for MOM 2005. For OpsMgr 2007, you need to save your changes in a custom MP because the MP's that are released by the vendor are sealed and cannot be modified). Document the customizations you make and implement a version control system as well. Make sure the changes return the expected results - alerts are raised for valid issues, thresholds are set to variances outside of expected performance characteristics, etc. Basically no ambiguous alerts and that you are seeing the results based upon how you have the service or application configured in your environment.
Review & Deploy - review with the necessary parties the results of the different phases of the process and if accepted, the MP can be deployed into production based upon the RFC submitted to the CAB (Change Advisory Board). If there are concerns or issues, it may not be approved and back to testing to rectify the concerns or issues. In addition, store the MP and documentation in a DSL (Distributed Software Library) - such as a share repository for all MP's or even something like Visual SourceSafe where it is logically structured per type of MP and version. Important for tracking and control of changes so that you maintain in a centralized manner. Don't forget to update your CMDB if you have one to follow the process for Configuration Management.

This may appear to be alot of unnecesary red-tape, but the point I am trying to make is do your due diligence in reviewing the MP and what it does, the requirements and caveats, and test it before you go ahead and implement in production. This is an enterprise monitoring product that should be controlled to ensure accurate notification of true health or reliability issues with services and applcations monitored in your datacenter. More importantly, the business will feel confident in IT meeting SLA's and the report data being reliable and that you are actually able to provide it.

Removing a Tiered MOM 2005 Management Group

mgoedtel — Mon, 19 Mar 2007 05:21:00 GMT

So I was working with a customer the other day wrapping-up some final requirements they had for their MOM 2005 implementation, after being away for a couple of weeks. Due to some significant changes in their headcount and long-term organizational structure, they had decided to modify the original MOM 2005 architecture (two tiered hierarchy with three management groups, each in separate forests to monitor AD DC's) and reduce to a single management group. This single management group would monitor specific roles/servers in the other forests. as well as the forest the management group was defined in, except Active Directory (Since the ADMP does not support monitoring DC's in other forests).

One thing that is not outlined in our documentation or on-line help, is the removal of a MOM-to-MOM Product Connector between target and source management groups. First thing that came to mind since I never had to do this before was delete the relationship from the Source Management Group, since that is where you define it from in the first place. Sure enough, that was the right method. One thing to note is that you need to log on to the source Management Server with the DAS account defined in the domain where the target MOM management group resides in order to perform this operation, or your you will receive an "Access Denied" error message. This is because the MMPC will by default, use the DAS account for authentication and is a member of the MOM Secuirty local group on the source management group. If there were no trust relationships established between the two domains, then a client certificate would need to be associated with the service account and map it to an account that is member of MOM Service security group on the destination management group.

So take note, don't just decommission a source management group without deleting the MMPC relationship first, or else you may have to resort to "less than desireable" measures to remove it from the target management group.

Installing the MOM 2005 Consoles on Windows Vista

mgoedtel — Tue, 06 Mar 2007 06:24:00 GMT

So I thought for my first blog posting, I would discuss how to install the MOM 2005 consoles (Administrator and Operator) on a Windows Vista client. Hmm, should be straight forward enough, no? Well unfortunately the MOM 2005 Setup prerequisite checker will state the minimum requirements have not been met - specifically with regard to the OS. So how do we get around this? By referencing the MSI Package – MOMSERVER.MSI from the command-line providing specific properties to avoid the prerequisite checker and successfully installing on Windows Vista.

Minimum Requirements: Because MOM 2005 was developed using .NET 1.1 managed code, .NET Framework 1.1 must be installed! Remember, .NET Framework 3.0 is included with Windows Vista and you can install prior versions of .NET side-by-side. Once you download .Net Framework redistributable package from here - http://www.microsoft.com/downloads/details.aspx?familyid=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en install it and then you can the proceed with the installation of the MOM 2005 Consoles.

Installing the Consoles: I recommend installing from the MOM 2005 SP1 media that is available on MSDN subscription or SA media and not the MOM 2005 RTM media. Once you find the source media, the command-line syntax to install the consoles is the following - MSIEXEC.EXE /i MOMSERVER.MSI ADDLOCAL=”MOMXUI” MOM_SERVER=”[Computer Name that hosts the MOM Management Server]” /qb

For further details on the command-line properties for MOMSERVER.MSI, please review the Microsoft Operations Manager 2005 Deployment Guide found on TechNet and review the section “Deploying MOM 2005 in Advanced Environments\Deploying MOM Using the Command Line” and you will see a sub-section for “MOMSERVER.MSI.” Use the following link - http://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/b7b0c768-64d1-486e-b9ed-7292c9e545f9.mspx?mfr=true

One note that should be mentioned, once the installation of the MOM 2005 consoles is complete and you execute one of the consoles; Vista will display a warning message indicating “known compatibility issues.” In my experience thus far, no issues have been encountered but your mileage may vary. The installation has been tested using MSDN and SA media on both Windows Vista x86 and x64 Ultimate SKU. It has not been tested on the Enterprise SKU; however there is no cause for concern as the differences between the SKU’s are simply the features installed.

So there you have it folks. Enjoy!