This documentation is archived and is not being maintained.
Migrating from MOM to Operations Manager 2007
At a Glance:
- Planning an Operations Manager deployment
- Assessing hardware needs
- Preserving historical data
- Testing plans
Server monitoring and management is a critical part of any modern IT infrastructure. It is vitally important to ensure that your IT infrastructure is not only working correctly but that it is adequate to support the load exerted on it by users. Gathering this information is easier
said than done, however, and knowing what to do with the information once you have it is another story altogether. Fortunately, there's help. Microsoft® Operations Manager (MOM) has been making this possible for seven years, and its latest incarnation, System Center Operations Manager 2007, expands on that foundation.
System Center Operations Manager 2007 offers numerous significant improvements over the previous version, MOM 2005. The core architecture has been redesigned and greatly improved to allow the product to be more aware of applications spread across multiple devices and also to be aware of not just servers but all the components that make up a server.
Furthermore, Operations Manager boasts a powerful collation engine that is able to aggregate alert data, greatly reducing the number of spurious alerts, as well as a Health Explorer that helps streamline the process of locating and resolving issues.
There are self-tuning thresholds and a baselining engine that allow you to easily track performance usage across your environment, and the reporting engine is much improved, offering superior graphics and drill-through reporting. Take a look at Figure 1 for a taste of the visual presentation of report data.
Figure 1 Availability Report in Operations Manager 2007 (Click the image for a larger view)
Operations Manager can even be used to monitor desktop machines as well as servers. Here are some additional features offered by Operations Manager 2007:
- Excellent monitoring for the Windows Server System™ platform
- Powerful application monitoring capabilities and functionality
- Automation of common tasks
- Next-generation database engine facilitating enterprise-level scalability and control
- Security enhancements and Active Directory® integration
For even more information about the new features that are available in System Center Operations Manager 2007, check out the article "Keep an Eye on Your Servers with Operations Manager 2007" by Pete Zerger in this issue of TechNet Magazine.
Migrating to Operations Manager
Before you plan your migration to Operations Manager 2007, you need to be aware that there is no direct upgrade path for the product. With such significant architectural changes to Operations Manager, the product could not remain compatible enough with previous versions to allow an in-place upgrade. Therefore, if you are currently running either MOM 2000 or MOM 2005, you will need to consider one of the migration strategies described later in this article.
If you are not running a previous version of MOM, however, you can simply install the new version of the product. Keep in mind that you'll have to decide very early on in the project whether you have sufficient in-house skills to carry out the installation or migration or whether you'll need to obtain assistance from a third party. Obviously, this will have an impact on the overall cost of the project, so it should be considered at the begining of this process.
For those who are not currently running MOM, the deployment is straightforward: plan and design the architecture and then deploy the software. However, if you are using MOM, Microsoft supports two migration scenarios; side-by-side on the same hardware and side-by-side on different hardware. Let's explore both.
Side-by-Side on the Same Hardware In this scenario, you install Operations Manager on the same physical hardware as your existing MOM 2000 or MOM 2005 architecture. This approach is useful for sites where the MOM infrastructure is not heavily utilized and where the server hardware is sufficiently powerful to co-host both old and new versions. You should only consider this path if the installation of Operations Manager will not seriously impact the performance of the current MOM servers.
Side-by-Side on Different Hardware In this case, the new installation is performed on new or different hardware. This is the preferred approach as it ensures that there will be little impact on the current management infrastructure while the migration is taking place. It is worth noting that additional hardware is not necessarily required. The new Operations Manager 2007 servers can be staged on virtual machines until the old server hardware can be reallocated.
Before you commit to a particular migration strategy, there are some important points to consider.
First, you need to think about hardware and software requirements and the associated costs. Even if you decide to stage or provision some or the entire Operations Manager infrastructure onto virtual machines, you still need to allow for OS and application licenses as well as OMLs (Operations Management License) for each agent to be monitored by Operations Manager.
Second, you need to plan for resourcing to carry out the work. In a small business, this may not be a particularly complex or difficult plan, but in larger companies it will be a key part of the overall migration strategy.
You also need to consider the potential impact this migration might have on either the current monitoring infrastructure or the server estate as a whole. You should plan for every eventuality, including the possibility of server reboots or even failures of critical production servers.
Note that if you are using either the Microsoft Access™ database in MOM 2000 or the SQL Server™ data warehouse in MOM 2005 for archive data storage and reporting, migration of this data to Operations Manager 2007 is currently unsupported.
Planning for a Successful Migration
As a consultant, one of the biggest problems I see is inadequate deployment planning. Therefore, once you decide whether you will install on new or existing hardware, the next step is to create a project plan.
Your project plan should list the stages of the project suggested in this article—though this is not an exhaustive list. Be sure to allocate sufficient time for each stage of the project, and to account for any resources that are required.
As I noted, System Center Operations Manager 2007 has a significantly different architecture than MOM 2000 and 2005. For starters, there is an additional server role in Operations Manager, the Root Management Server (RMS). The RMS manages the configuration for the Management Group, handles all connections to other Management Groups and third-party products, and is also responsible for security across the Management Group. This role can be held on an existing System Center Operations Manager Management Server, but in large, complex environments it should be given its own physical server. Also, the concept of tiered Management Groups that existed in MOM 2005 has been replaced with Connected Management Groups. In this new architecture, no alert data is actually passed between the Management Groups; instead, alerts from Connected Management Groups are simply presented in the UI of the requesting Management Group. In addition, if you're thinking about installing agents on machines in untrusted domains or workgroups, you will have to use certificates to allow the agent and Management Server to mutually authenticate (a feature that is forced in Operations Manager).
In order to design the architecture for System Center Operations Manager, you will need to consider the number of servers and clients you plan to monitor, whether they are located in a trusted domain, which applications and platforms you need to monitor, and whether you want to monitor your network infrastructure. You also need to identify any applications that will require custom rules or management packs.
This is the stage at which you should identify your management pack requirements. Once you have determined the applications you'll monitor, you can decide which management packs you are going to install. Management packs contain rules, monitors, tasks, and classes that apply to a particular application or operating system and should be imported if their associated application or operating system is in use in your environment. The choice of management packs at this stage will impact the hardware and software requirements and the amount of time that should be allocated to installing and configuring the software.
Once you have an idea of the architecture of your Operations Manager infrastructure, you should break out the System Center Capacity Planner 2007 tool (in beta at the time of this writing). Use the tool to map out your network and server infrastructure and simulate running it against your planned Operations Manager deployment to ensure that it is sufficient to monitor and manage your infrastructure.
It is at this point you should also pay particular attention to architectural design if you are planning to migrate. You need to consider the fact that MOM 200x will be running alongside Operations Manager, resulting in additional network traffic.
Deployment is the next stage to think about. You need to be sure that adequate hardware is provisioned before you install the software. If you are installing into a new environment, physical hardware is better, especially for the database server. However, Management Servers can be virtualized if physical hardware is not an option. In a migration scenario, the use of virtualized servers is a good alternative to purchasing hardware to stage the new infrastructure. In this situation, you can use virtual machines to stage Operations Manager while the old MOM servers are decommissioned and rebuilt.
Once the servers have been provisioned, you can begin to install the software. First, make sure that the servers that will run Operations Manager have the required software prerequisites to support it. For example, if you are running SQL Server 2000 and are planning to install Operations Manager on the same server, you will need to first upgrade to SQL Server 2005 with SP1. To check this, you can run the Operations Manager prerequisite checker from the System Center Operations Manager installation media.
After all of the software prerequisites are in place and you've configured SQL Server and Reporting Services, you can begin to install the Operations Manager software. In a single-server environment, this is easy; you simply run the Operations Manager setup file on the server, then run the Operations Manager reporting setup if you want to use that feature. In a distributed environment, however, the Operations Manager components need to be installed on the individual servers in the correct order. First, you install the database, then the first Management Server, which will automatically be assigned the Root Management Server role. After this, any additional Management Servers can be installed. As the final step, you install the Web console and the reporting components.
At this stage, you should make sure that your new infrastructure mirrors your existing monitoring before attempting to take advantage of any new features. Any management packs used in the legacy environment should be duplicated in the new Operations Manager deployment. If there is an Operations Manager management pack available, you may wish to import it, but any management packs that do not have newer versions will need to be exported from the current Management Group, converted using the MPConvert tool from the installation CD and imported into Operations Manager—unless you have a small or simple custom management pack, in which case it would be better to simply recreate it. There is also a tool that is useful when duplicating configuration. The MOM 2005 to Operations Manager migration tool helps to duplicate configuration from an existing MOM Management Group to Operations Manager; you'll find it on the Operations Manager installation CD as well. Figure 2 shows a typical configuration during a migration.
Figure 2 Typical configuration during migration (Click the image for a larger view)
Once your configuration is duplicated, you need to ensure that you are actually getting the same alerts and collecting the same data with Operations Manager as with MOM. Fortunately, the Operations Manager agent can coexist with legacy MOM agents so both agents can run simultaneously. You can collect data from both and compare them side-by-side for accuracy before decommissioning the legacy system.
Next you should formulate a testing plan. Testing may consist of simply comparing the alerts from the legacy system with those of the Operations Manager system, but may also go as far as to require the purposeful generation of alerts to thoroughly assess the new infrastructure. Once you are satisfied with the test results, you can begin to uninstall the legacy MOM agents, by using either the MOM console or Add/Remove programs on the agent machines.
Reporting is a big part of a MOM and System Center Operations Manager deployment and also needs to be addressed. The existing SystemCenterReporting database can't currently be migrated to Operations Manager 2007, so you can create a new instance of Reporting Services for Operations Manager and keep the existing MOM 2005 (SystemCenterReporting) database in a dedicated SQL Reporting Services instance to display the legacy reports. The new reporting console in System Center Operations Manager 2007 is integrated into the product so it is not recommended to use the Reporting Services console for anything other than Operations Manager. The migration of reporting data is something that may be addressed in the future by means of a data migration script, but in the meantime you might have to say goodbye to your archived reporting data and simply take comfort in the fact that when you start generating your new flashy reports, management will be so excited they may not even notice that your old data is gone.
System Center Operations Manager offers significant improvements over MOM 2000 and 2005, but these advances can come at a cost. A major change in the underlying architecture (and the resulting lack of a direct in-place upgrade path) means that deployment costs have the potential to be higher. The key to minimizing these costs is to that you adequately plan and ensure that you have the right people for the job. Do this and you can reap the benefits of Microsoft's hard work with System Center Operations Manager.