You must have the MOM 2005 RTM version of Eval to upgrade to MOM 2005 RTM Licensed Version.
1) The upgrade from the evaluation version of MOM 2005 can be performed after the evaluation version has expired.
2) You must then run the MOM 2005 licensed version (MOMServer.msi) on the server that has the MOM 2005 Eval Version. Setup will detect if it is an upgrade and will provide a checkbox asking you if you would like to upgrade to MOM 2005.
The EVAL upgrade to the licensed version will uninstall and reinstall the files and registry of the product.The database holds the settings for MOM and these will remain as they were last configured even after the upgrade process.
During the upgrade, the timebomb information is removed and for this reason the database is modified during upgrade. Backing up the database is a security measure that is recommended by all enterprise products that prevents the data from being lost if a problem occurs during the upgrade process.
Users and passwords for the MOM accounts will require to be re-entered at upgrade time. The accounts need to have access to the correct components, but do not require to be the same ones used during the original install.
Upgrade Procedure:
Run the licensed version MOMServer.msi on each of the components that need to be upgraded.
Scenario 1: All MOM components on a single server
Follow the Above steps and upgrade the agents from the Administrators Console. If you have an Agent behind a firewall you will have to install the agent manually.
Scenario 2: Distributed configuration
You will first upgrade the MOM Database, then the Management server (all the Management Servers if you have more than one) then all the Consoles and then the Agents. If you are “upgrading” from the RTM evaluation version to the RTM Select the agents are identical and do not have to be upgraded.
Note: Your MOM Management Packs do not need to be re-imported, unless there is a newer version of the MP that you would like to use.
Information/workarounds/solutions provided may not be supported by the Microsoft Operations Manager. Comments expressed by the blogger maybe subjective and are subject to change.
A question that I hear frequently is "How do I create a read-only Operator Console"?
The MOM security groups are 'MOM User', 'MOM Author', and 'MOM Administrator'. Unfortunately, there is no 'MOM Read-only User' security group. This means that there is no possibility of creating a completely secure read-only user profile. The Operator Console does not have some other kind of switch on it which will put it into read only mode either. Bummer!
However, there is some hope. You can make the web console web site "read-only" and point your users to the web console if you dont want them to change anything.
Here is how you do it:
1. On the server hosting the Microsoft Operations Manager 2005 Web Console application, open the %INSTALLDRIVE%\Program Files\Microsoft Operations Manager 2005\WebConsole\web.config file in a text editor.2. In the <appSettings> node change the node “<!--add key="Readonly" value="true"/-->” to “<add key="Readonly" value="true"/>”.3. Stop and Restart the Microsoft Operations Manager 2005 Web Console application in the Internet Information Services snap-in.
This will disable all of the constrols on the web pages so that nobody can make any changes.
A few notes on this:
1) This is not a secure solution. You will still need to add the users to one of the MOM security roles. Once user has been granted the permission, he can either a) install a Opertor Console and use it to change things or 2) write code that calls the DAS directly to change things.
2) This change will be applicable to all users that access the web console on this server. If you want to have some users have a read-only experience and some users to have a writable experience in the web console you will need to set up multiple web sites and point the users to the appropriate one depending on what you want them to do.
MSDN Magazine has a great article on how to write a manageable application and then montoring it with MOM, entitled Instrument and Monitor Your ASP.NET Apps Using WMI and MOM 2005. This really gets to much of the core of DSI which starts wtih designing applications with management in mind and then developing a feedback mechanism from operations back to development using MOM. Thanks to Michael Jurek for this article.
Enjoy!
Many customers are interested in best practices for securing their MOM 2005 deployment. Beyond the documentation we provide (see the MOM Security Center as part of the MOM 2005 Admin console\Information Center) here are a couple more tips:
Hope this helps.
Here is some background that led to the decision to take this dependency on Windows Installer (MSI) 3.1v2 in MOM 2005 Service Pack 1. I completely understand how this dependency may complicate or delay your deployment of MOM 2005 SP1 particularly in highly locked down environments.
This Windows Installer 3.1v2 update (version 3.1.4000.2435) was released as a High Priority update on 5/12/2005. Installing the Windows Installer update generally requires a reboot following installation. If you have not installed this, it is useful to consider bundling the Windows Installer update with recent security updates that have been released.
Finally, note that it is fine to leave agents at RTM version after the server is updated to SP1. This is a fully supported scenario and allows you to get the MOM servers to SP1 first and then update agents as managed servers get Windows Update 3.1v2.
Feel free to leave comments - I appreciate your feedback.
Thanks!Dale Koetke (Lead Program Manager)
The MOM 2005 Sizer tool is finally available. This is the final version that is officially released to the public. The MOM 2005 sizer helps you predict the hardware requirements for your MOM deployment based on the number of computers that you will be managing. It can also predict the network utilization.
This tool is based on a huge amount of testing data compiled by the MOM performance and scalability test team.
You can download the tool here:
http://www.microsoft.com/downloads/details.aspx?familyid=93930640-fa0f-48b3-8eb0-86836a1808df&displaylang=en
It is not possible to configure the default email notification format through the administrator console. It is possible to edit the global page and command format but not the email format. Many people ask how they change the default email format at a global level. The only way to do this is to use an unsupported SQL update query.
First of all, the global formats are stored on the Configuration table in the OnePoint database. To view your current default email formats run this SQL query:
select * from configuration where DataName in ('EmailSubject','EmailMessage')
You will see some pretty cryptic text in the DataValue field. This is what MOM uses to generate the text of the email subject and message by substituting in various alert fields from the alert that is generating the notification.
These are the default settings in MOM:
Email Subject:
Operations Manager $%AlertLevel%52 $ Alert on $56 $\$55 $
Email Message:
Severity: $%AlertLevel%52 $ Status: $%ResolutionState%53 $ Source: $50 $ Name: $62 $ Description: $63 $ Domain: $56 $ Agent: $55 $ Time: $54 $ Owner: $51 $ (view with $AlertURL$)
To update the message use a SQL query like this:
update Configuration set DataValue = '<YOUR MESSAGE FORMAT HERE>' where DataName = 'EmailSubject'
update Configuration set DataValue = '<YOUR MESSAGE FORMAT HERE>' where DataName = 'EmailMessage'
Given this information you should be able to use the $ examples (for example $56 $ will substitute in the domain name of the computer generating the alert) above to figure out how format your message the way that you like. Keep in mind that changing this setting will affect all email messages sent by MOM that have not been overridden at the individual notification response level.
The MOM 2005 Operator Console has a great hidden feature most people don't know about - .omc files! A .omc file is a file which stores your personalization settings for the console session. You can do a File/Save As at any time to start a new .omc file. From then on, while you have the file "open" your personalization settings will be stored in the .omc file. You can then put the .omc file on your desktop and open the console to a personalized view of the console.
Things that are stored in the .omc file:
How is this useful? Here are some ideas how to take advantage of this feature:
Give it a try! Here are the steps:
Leave a comment to tell me if you think this is a useful feature or not!
There are quite a few situations recently which have come up where you might want to bypass the MOM 2005 installation prerequisite checker. These include installing MOM 2005 (not SP1) on a Yukon server, installing the MOM UI on Windows Vista, or installing MOM 2005 in a situation where the prerequisite checker does not acurately detect the software installed or hardware.
If it detects a failure to meet a minimum software or hardware requirement, the MOM 2005 prerequisite checker is designed to prevent the user from installing the product and getting into a bad state until the minimum required software or hardware is installed.
In these situations, you can bypass the prerequisite checker by installing from the command line and passing a parameter which tells the MOM setup to skip the prerequisite check. To do use msiexec.exe and pass PREREQ_COMPLETED="1".
See the MOM 2005 Deployment Guide for more details on the required and optional command line parameters.
See MSDN for more information on the msiexec.exe command line parameters.