If you are using Microsoft Operations Manager (MOM) and plan to upgrade to Operations Manager (OpsMgr) 2007, this is the chapter you are looking for. This chapter discusses the options available for migrating to Operations Manager 2007 and provides troubleshooting tips you’ll want to be aware of during the migration process. We will talk first about what you need to know for planning for your migration.
Before starting the migration process, you will need to plan your OpsMgr 2007 implementation. As discussed in Chapter 4, “Planning Your Operations Manager Deployment,” prior to migrating to OpsMgr 2007 you should assess, design, plan, and test the process within a proof of concept (POC) environment.
Part of your assessment should include identifying the servers that currently provide MOM services. The specific server configuration used by your organization will determine which steps are required for your migration and the complexity of the migration. If you installed all MOM components on a single server or single management group, the migration is far simpler than if there are multiple management groups. If you are not familiar with the details of your current MOM 2005 environment, do not pass Go. Return to Chapter 4!
The first major concept to be aware of when migrating to Operations Manager 2007 is that there is no upgrade process. Although it would be great to be able to put in the installation media and click “upgrade,” that is not viable with OpsMgr 2007 due to the significant changes that have occurred since MOM 2005. You can approach a migration to OpsMgr 2007 in three different ways:
Starting clean
Same hardware
New hardware
The approach you will take will vary, depending on the current state of your monitoring environment and the hardware in place for that environment. For a quick reference on the information needed prior to the installation or migration of OpsMgr, see the pre-installation checklist (OpsMgr Pre-installation Checklist.xls) introduced in Chapter 6, “Installing Operations Manager 2007,” and included on the CD for this book.
One option for implementing Operations Manager 2007 is to start clean and install OpsMgr as if it was a new installation. This approach includes the following activities:
Install Operations Manager as a new installation (see Chapter 6 for installation details).
Configure your installation to provide the required functionality.
Once Operations Manager 2007 meets the requirements of the organization, decommission the original monitoring product.
The starting clean option does not provide a migration path but may be the best solution in certain cases. To explain this better, we need first to discuss the supported migration options for OpsMgr 2007:
MOM 2000 SP 1—MOM 2005 SP 1—OpsMgr 2007
If you are currently on MOM 2000, you can upgrade to MOM 2005 SP 1 (see Microsoft Operations Manager 2005 Unleashed for details on migrating from MOM 2000 to MOM 2005). After completing that upgrade, you can then migrate to OpsMgr 2007.
MOM 2005 Workgroup—MOM 2005—OpsMgr 2007
The supported upgrade path is to upgrade to the full version of MOM 2005 and then migrate to OpsMgr 2007.
OpsMgr 2007 RC2—OpsMgr 2007
If you were involved in the beta process for Operations Manager, you can update Release Candidate 2 (RC2) to OpsMgr 2007.
Evaluation OpsMgr 2007—OpsMgr 2007
If you have a Select CD image, you can upgrade the evaluation version of OpsMgr 2007 to the full release version.
Tip: Upgrading the Evaluation Version to the Full Volume Licensed Edition
You can upgrade the 180-day evaluation version of Operations Manager 2007 (available at http://www.microsoft.com/technet/prodtechnol/eval/opsmgr/default.mspx) without reinstalling the product. The Microsoft Volume License (MVLS) website, located at https://licensing.microsoft.com, provides license keys and downloadable media for Microsoft Volume License customers.
The Volume License version of the Operations Manager 2007 installation media includes LicensingWizard.msi in the SupportTools folder. This wizard provides the capability to convert the evaluation version of OpsMgr 2007 to the full version.
This information is documented at http://support.microsoft.com/kb/937826.
Here are some situations where it may make more sense to start clean and install OpsMgr as a new installation:
MOM 2000 installations—. Considering the time required for upgrading to MOM 2005 and then to migrate to Operations Manager 2007, it may make more sense to use the clean start approach.
MOM 2005 Workgroup installations—. Similar to a MOM 2000 installation, it may make more sense to start clean in this situation, considering the time required to upgrade to MOM 2005 and then to migrate to Operations Manager 2007.
Non-MOM installations—. If the current monitoring product is not a previous version of Microsoft Operations Manager, we recommend you start clean.
Abandoned MOM 2005 installations—. If the current installation of MOM 2005 is abandoned or no longer in use, there is minimal investment in what was previously installed.
The starting clean approach includes planning, installing, configuring, and decommissioning steps:
Planning Operations Manager 2007—Read Chapter 4 and Chapter 5, “Planning Complex Configurations,” for information on the planning process for Operations Manager 2007 deployments. These chapters apply regardless of what approach you will take for installing or migrating to OpsMgr 2007; focus on identifying the current monitoring solution and the functionality that it provides.
Tip: Documenting Your MOM 2005 Environment
As part of your migration to Operations Manager 2007 from MOM 2005, you should document the current MOM 2005 environment during the Assessment phase. Enhansoft provides a tool to assist with documentation, available from its website at http://www.enhansoft.com/ under Downloads -> MOM Documentation Script.
Installing Operations Manager 2007—Chapter 6 discusses the process to install OpsMgr 2007, including the various available components.
Configuring Operations Manager 2007—The OpsMgr solution will need the appropriate management packs installed and will need to be configured to meet the requirements identified during the planning phase.
Decommissioning the original monitoring solution—Once OpsMgr 2007 has met your requirements, you can decommission the original solution.
The primary issue with the starting clean approach is that it does not automate converting your current monitoring solution to OpsMgr 2007. By comparison, Table 7.1 shows the items converted during either a same hardware or new hardware approach.
Table 7.1. MOM 2005 Management Pack Components with OpsMgr 2007 Converted Equivalents
MOM 2005 | OpsMgr 2007 |
|---|---|
Alert severity | Health state |
Rule monitor | Alert-generating rules |
Rule | Non-state-generating rules |
Collection rule | Performance rule |
Computer group | Computer Group class |
Installation class | Two discovery rules generated during conversion |
Class (used for state monitoring) | Class |
Rule | Rule or monitor |
Script | Module type |
Task | Task |
Notification group | Notification rules |
Knowledge | Knowledge article |
Topology | View |
With that long of a list in Table 7.1, it looks like about everything converts, right? Well, not exactly. The migration does not convert the following items:
Reports—. With OpsMgr 2007, the Data Warehouse and the reporting functionality are completely rewritten.
Operators—. You must manually re-create operators as part of the migration.
Console scopes—. You must define console scopes as part of the migration.
To perform these conversions, we will review the other options available for migrating to Operations Manager 2007. These are the same hardware and new hardware approaches, which we review in the following sections of this chapter.
If you have decided not to use the starting clean approach for your migration, the next consideration is whether to use the same hardware or new hardware for your migration to Operations Manager 2007.
The migration process enables you to share the hardware used by your current MOM 2005 environment with the new Operations Manager 2007 environment. You can install the OpsMgr agent on the those systems currently running the MOM 2005 agent, resulting in a new OpsMgr 2007 agent reporting to the OpsMgr 2007 environment, while the original MOM 2005 agent continues to report to the original MOM 2005 environment. We refer to sharing hardware between MOM 2005 and OpsMgr 2007 as the same hardware approach. Figure 7.1 shows a simple two-server configuration running on MOM 2005 before the same hardware migration is started.
This configuration displays a single management server monitoring the agents in the environment with an additional server providing database and reporting functionality.
When you’re considering what migration approach to take, the first question to ask is whether the hardware current provides the MOM 2005 functionality is sufficient to run both OpsMgr 2007 and MOM 2005. To provide the Operations database functionality in this configuration, the recommended hardware specifications will vary based on the number of monitored agents:
100–500 agents—. Dual-processor, 2GB memory, and two-drive RAID0+1 disk subsystem
500–750 agents—. Dual-processor, 4GB memory, and four-drive RAID0+1 disk subsystem
1000 agents—. Dual-processor, 4GB memory, and eight-drive RAID0+1 disk subsystem
The first OpsMgr 2007 management server you install will be the Root Management Server (RMS). The recommended hardware for this component is a dual-processor system with 4GB of memory and a two-drive RAID1 disk subsystem.
When considering performing a same hardware migration, if any of the following items are true, you should seriously consider a new hardware migration (discussed in the “New Hardware” section of this chapter) instead:
Current hardware insufficient—. If the current hardware installed for MOM 2005 does not meet the hardware specifications mentioned in this chapter or Chapter 4, there will be a negative impact on OpsMgr performance both during and after the migration.
Change of design—. With the new components of OpsMgr 2007, you may want to consider a new design. Using a same hardware approach, the same design exists after the migration is complete. As an example, if your current MOM 2005 environment has a single nonclustered management server (which is a common configuration in small organizations), you cannot use the same hardware to provide a high-availability solution such as a clustered RMS.
Shared SQL Server—. If the server providing database functionality is shared with other applications, this may represent an issue for a same hardware approach. The OpsMgr 2007 operational database requires at least SQL 2005 Service Pack 1.
MOM 2005 Reporting impacted—. As part of the upgrade process to Operations Manager 2007, there are significant changes made to the reporting functionality. Once you install the reporting components for OpsMgr 2007 on the MOM 2005 reporting environment, the reports for MOM 2005 are no longer accessible.
64-bit systems—. OpsMgr 2007 supports 64-bit Windows operating systems and benefits from the performance of running in a 64-bit OS. If the current hardware running MOM 2005 is 64 bit but the operating system is not, you will be unable to take advantage of the 64-bit platform unless you use the new hardware approach.
Figure 7.2 shows what the configuration would look like when performing a same hardware migration for the management group configuration, previously displayed in Figure 7.1.
Tip: Always Back Up!
The one time you do not have a backup is the one time you will need the backup. This is our MOM/OpsMgr version of Murphy’s Law.
The good news is that both migration approaches use the same steps; they vary only on what servers you actually perform the installation. We will review using the same hardware approach in a case study later in this chapter.
We next discuss the new hardware approach and the steps required to perform it, because you can also use these steps with the same hardware approach.
If new hardware is available for the migration to Operations Manager 2007, from the component perspective the installation will mirror those discussed in Chapter 6.
If we take our example shown in Figure 7.1 and perform a new hardware migration on it, Figure 7.3 is the result.
In a new hardware migration (as well as the scenario previously discussed in the “Same Hardware” section), the OpsMgr agent is installed on the systems currently running the MOM 2005 agent. The MOM 2005 agent reports to the MOM 2005 environment, and the OpsMgr 2007 agent reports to the OpsMgr 2007 environment.
Tip: Issues with 64-Bit Domain Controllers in Migrations from MOM 2005 to OpsMgr 2007
There is an issue if you are monitoring 64-bit domain controllers with both MOM 2005 and OpsMgr 2007 while using the Active Directory Management Pack. This is due to a conflict between the Active Directory Helper Object (OOMADS) between the two agents.
To work around this issue, exclude each 64-bit domain controller from monitoring by MOM 2005 and uninstall OOMADS 1.0.3 (the version used by the MOM 2005 agent) from the 64-bit domain controllers. Then install the new version of OOMADS on the domain controller. OOMADS is located on the OpsMgr CD within the HelperObjects/<version> directory.
The primary negative for using the new hardware approach is the requirement to purchase additional hardware to provide OpsMgr functionality (hardware specifications should be determined based on the information in Chapter 4). Additional negatives with this approach include requirements for more rack space, backup power, and increased management for supporting the additional servers.
Many organizations purchased hardware designed for the growth required for their MOM 2005 solution. As a result, the hardware is often insufficient to run both solutions on the same physical systems.
In the “Same Hardware” section of this chapter, we explained the reasons why you should or should not use the same hardware as part of the migration process. In general, it results in a better migration experience when you use the new hardware migration approach versus the same hardware migration. With the new hardware approach, the installation gains the benefits of a clean installation of the operating system (including the benefits of a 64-bit platform if one is chosen) and will not have to share resources between the two applications.
Although you must acquire extra hardware for the new hardware approach, it does not necessarily mean that additional hardware will be required once the project is complete. Let’s take an example where your current MOM 2005 solution is running in a two-server configuration (a management server and a SQL Server system running the reporting and database components) and the hardware is relatively new. You install new hardware for the OpsMgr 2007 solution, and the agents are reporting to both environments. Once the OpsMgr 2007 solution provides the required functionality, you can shut down the MOM 2005 solution. After you decommission MOM 2005, the server(s) providing that solution will now be available for use elsewhere in your organization.
The same hardware and new hardware approaches are just that: approaches. They are not strict in their interpretation that you can only do a same hardware approach or a new hardware approach. Your environment may require a hybrid of the two approaches. As an example, we can look at an organization with a MOM 2005 environment that has a single management server as well as a combined database and reporting server. Due to performance issues in this configuration, the goal is to split out some of the functionality that the combined database and reporting server is providing.
Figure 7.4 displays the resultant hybrid migration. This migration uses a same hardware approach for the management server and part of the database requirements. However, it introduces new hardware into the design to enable separating the OpsMgr 2007 Reporting Server and Data Warehouse Server Components.
Using a hybrid method, combining both the same hardware and new hardware approaches, provides a much more diverse approach to deploying the OpsMgr solution, and you should consider it if there is a requirement to use at least some of the original hardware from the MOM 2005 solution.
One other concept to think about when migrating to OpsMgr 2007 is the swing server approach. You will often see this approach in Exchange migrations, where a new server is deployed running the new version of Exchange and then users are migrated to the new server. Once the old server is no longer required, it is rebuilt using the new version of Exchange; users are then migrated back to the original server. The swing server provides a method to use temporary hardware in a migration, which allows you to use the original system hardware for the new solution.
With OpsMgr 2007, you can apply some of the swing server concepts, but the migration will be far more complex than any other migration approaches discussed in this chapter. This is not a recommended migration approach, but we include it for consideration as an approach that may be available later in the product cycle for OpsMgr 2007. The high-level approach to this type of a migration would include the following tasks:
Back up the current MOM 2005 environment.
Install the RMS on new hardware.
Install the Operations database on new hardware.
Install the Data Warehouse database on new hardware.
Install the Reporting Server Component on new hardware.
Install the OpsMgr agent on the servers you will be monitoring.
Validate functionality of the new OpsMgr 2007 solution.
Configure OpsMgr to meet the identified requirements.
Uninstall the MOM 2005 environment, including agents.
Reinstall the operating system on the original MOM 2005 management server, database server, and reporting server machines.
Install the OpsMgr 2007 management server on the original MOM 2005 management server hardware.
Install SQL Server 2005 and configure it with database and/or reporting functionality.
Move the RMS from the new hardware back to the original management server hardware.
Move the database and reporting functionality.
Decommission all new hardware provided for the migration.
Tip: Moving the Database and Reporting Functionality
While initially there was no method to move the Operations and Data Warehouse databases to other servers, we have investigated these processes and documented the procedures for moving both these databases.
An article on how to move the Operations database is available at http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!177.entry. Microsoft has since updated the Backup and Recovery guide (available at http://technet.microsoft.com/en-us/opsmgr/bb498235.aspx) to include a process to move the Operations database.
We also have written an article on how to move the data warehouse, which is available at http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!235.entry. (Links to both these articles are available as live links in Appendix E, “Reference URLs,” and these processes are also discussed in Chapter 12, “Backup and Recovery.”)
Microsoft has also updated their Backup and Recovery guide to include the steps to move the data warehouse.
We have discussed a variety of approaches to migration within this chapter, including starting clean, same hardware, new hardware, hybrid, and swing server. In the next section of this chapter, we will review the same and new hardware approaches as examples of migrations.
To understand the actual migration process in more depth, we will go through two case studies on how to approach the migration. These examples will focus on the two primary methods to migrate to OpsMgr 2007: same hardware and new hardware.
The Eclipse Company deployed MOM 2005 in a single management group using a single-server configuration. Eclipse monitors 100 servers with MOM 2005 and wants to be able to use the same hardware to monitor its environment with OpsMgr 2007. Eclipse has accepted that once the migration process is complete, the reporting information from the MOM 2005 environment will no longer be accessible online. Therefore, Eclipse has generated a backup of the database and the reports so it can re-create the reporting system if that is required later.
See Chapter 4 for information on planning a migration such as this one. This section assumes that you performed an effective assessment, planning, and design prior to installing OpsMgr 2007.
The first step in the Eclipse migration was to deploy OpsMgr 2007 on the same server where MOM 2005 was already functional. The company identified a unique name (GROUP2) for the new management group. The deployment involved installing the Operations Manager 2007 RMS, Operations Console, Operations Database Server, and the Reporting and Data Warehouse Components (for details on installing these components, see Chapter 6). Eclipse deployed agents using the Operations console and validated the functionality of the OpsMgr solution.
Next, Eclipse installed the MOM 2005 to OpsMgr 2007 Migration Tool. You can find this tool on the System Center Operations Manager 2007 installation media. Run the setup program (SetupOM.exe) and select the option Install MOM 2005 to Operations Manager 2007 Migration Tool. This option requires that both the MOM 2005 SP 1 user interface and the OpsMgr 2007 user interface exist on the same system.
The actual installation of the migration component has no wizard screens; there is only a confirmation message that the setup succeeded. The installation creates a program called the Migration Tool, available on the Start menu within the System Center Operations Manager 2007 folder. To run the Migration Tool, perform the following steps:
The Migration Tool invokes the System Center Operations Manager Migration Wizard, which is displayed in Figure 7.5.
This wizard provides management pack migration from a MOM 2005 management group or the file system. Use the file system approach in a two-stage migration, where you gather the information from the MOM 2005 management group and store it on the file system for later integration with OpsMgr 2007.
On the next screen of the wizard, we specify the management server name, as shown in Figure 7.6. For the Eclipse environment, the management server is named MOM.
The next step is to configure the settings for whether the wizard will migrate managed computers and management packs, as well as what specific management packs to migrate. These choices are shown in Figure 7.7.
On this screen we specify whether we going to migrate computers and management packs. “Migrating” computers is quite benign; this option generates a file of the computers that we can later use for installing agents, so it is highly recommended to check the option.
Deciding which management packs to migrate is a little more complex to determine. Figure 7.7 shows all the management packs installed in the MOM 2005 environment, including those that were custom developed.
Our recommendation is to take the list and uncheck those that have corresponding management packs listed on Microsoft’s System Center Pack Catalog site as Operations Manager 2007 management packs (http://go.microsoft.com/fwlink/?LinkId=71124). Mark the check box of any custom management packs required in OpsMgr 2007 so the wizard will attempt migration.
On our first attempt with this wizard, we chose to migrate the DHCP Server, DNS Server, and Print Server management packs (which were not available as OpsMgr 2007 management packs at that time). Although the wizard completed successfully, it was unable to actually migrate the DHCP and DNS management packs. If you cannot successfully convert your MOM 2005 management packs with the Migration Wizard, you may want to try using the MP2XML and MPConvert utilities, which we discuss in Chapter 13.
For our example in Figure 7.7, we have left only the Managed Computers and Microsoft Windows Print Server management pack options checked. Because we chose the Managed Computers check box, the next screen requests the location to save the managed computer export file, as shown in Figure 7.8.
This file contains the names of the servers currently managed by the MOM 2005 management group. The file itself is a text file with each server’s fully qualified name (FQDN) on a separate line within the file. In our example, we stored this at the top of the C: drive in a file named called c:export.txt.
Because we are doing a same hardware migration, the server name is the same name as on the wizard source screen. For our example in Figure 7.9, where we specify the managed destination, the server is MOM.Eclipse.com.
The last step runs the migration and displays the status for actions specified. For our Eclipse migration, we successfully performed both the export and migration of the Microsoft Windows Print Server management pack (see Figure 7.10).
Performing this process integrated the Print Server management pack with the Operations Manager 2007 environment and generated an exported file listing the computers managed by MOM 2005.
The next step is to take the exported file and install the agents on OpsMgr 2007 using this file. Run the Discovery Wizard in the Operations console. In the Administration node, navigate to Discovery Wizard -> Advanced Discovery and then choose the option Browse for, or type-in computer names (see Figure 7.11).
You can now deploy these systems using the Discovery Wizard, which will integrate the new agents with OpsMgr 2007 while they continue to be managed by MOM 2005. To deploy to the systems that were exported, copy and paste the contents of the exported file into the Discovery Wizard into the Browse for box shown in Figure 7.11. For more detail on the Discovery Wizard, see Chapter 9, “Installing and Configuring Agents.”
For the Eclipse Company, the following list summarizes the same hardware implementation as it occurred during the migration:
Assessed the current MOM 2005 environment.
We identified one management group, one management server, and one database/reporting server.
Identified requirements for OpsMgr 2007.
Performed a backup of the current MOM 2005 environment.
Downloaded all prerequisites identified by the two different systems.
The original management server will now be a RMS, Operations console, and Web console in addition to the original functions. The first server required installing .NET Framework 2.0, PowerShell, and .NET Framework 3.0.
The original database server/reporting server is now the Operations database, Reporting server, and data warehouse, in addition to its the original functions.
This server required SQL 2005 SP 1, KB918222 (both SQL and Reporting components), and .NET framework 3.0.
Validated the functionality of the original MOM 2005 environment.
SMS 2003 also uses the database server; we validated that SMS 2003 was still functional after installing the OpsMgr prerequisites.
Determined the current name for the management group in MOM 2005 (Eclipse).
Used GROUP2 as the new management group name for OpsMgr 2007.
Created service accounts, including OM_MSAA, OM_SDK, OM_DWWA, and OM_DRA.
Installed the OpsMgr operational database on the original database server.
Installed the RMS, Operations console, and Web console on the original management server.
Validated the functionality of the reporting services on the original database server.
Installed the Reporting components on the original database server.
Validated functionality of both the OpsMgr and MOM installations.
Installed the Migration Wizard and ran the wizard.
The domain controllers immediately showed up as discovered.
Pushed the agent to a subset of the servers using the list exported from the wizard.
Identified issues with agent deployment. One issue was a Windows 2003 server without Service Pack 1 installed.
Validated the functionality of the MOM 2005 Operator console.
Validated the functionality of the OpsMgr 2007 Operations console.
The result from the same hardware approach was a two-server configuration running both MOM 2005 and OpsMgr 2007, displayed earlier in Figure 7.2. This process provided the foundation required for meeting the business requirements identified for the solution; once those matched, the original MOM 2005 environment could be decommissioned.
The second possible approach for migrating the Eclipse company was to perform a new hardware migration. After evaluating this approach, it was determined to be the approach that would provide the best long-term functionality for the company. Two primary reasons were identified for taking this approach rather than the same hardware approach:
The ability to provide a 64-bit platform for the OpsMgr solution
The opportunity to split out the Reporting server functionality from the Data Warehouse and Operations Database server
The original recommended configuration had also included the split of the data warehouse and Operational database to separate servers, but due to software and hardware costs, the decision was to keep these components together and to split them in the future if there were performance bottlenecks.
The first step in the Eclipse new hardware migration was installing the servers required for Operations Manager 2007. The company identified a unique name (GROUP2) for the new management group. Based on the business requirements for the OpsMgr 2007 product, the design included three servers:
RMS
Operations database and Data Warehouse server
Reporting server
After installing these servers and bringing the new OpsMgr 2007 environment online, the next step of Eclipse’s new hardware migration was deploying the Operations Manager 2007 console on the MOM 2005 management server. The reverse approach could also have been taken (installing the MOM 2005 console on the OpsMgr 2007 RMS), but because the goal is to obsolete the MOM 2005 environment, the decision was made to not install any MOM 2005 components on the permanent OpsMgr 2007 equipment.
After the current MOM 2005 management server was configured with the required OpsMgr 2007 components, the Migration Wizard was ready to install. As with the same hardware migration, this is available from the System Center Operations Manager 2007 Setup (SetupOM.exe) screen by selecting the Install MOM 2005 to Operations Manager 2007 Migration Tool. Then you can run the Migration Tool from the Start menu.
The following summarizes the Eclipse company’s new hardware implementation as it occurred during the migration:
Assessed the current MOM 2005 environment.
The assessment identified one management group, one management server, and one Database/Reporting server.
Identified the requirements for OpsMgr 2007.
Downloaded all prerequisites identified by all three systems.
Determined the current name for the MOM 2005 management group (Eclipse).
Used GROUP2 as the new management group name for OpsMgr 2007.
Created service accounts, including OM_MSAA, OM_SDK, OM_DWWA, and OM_DRA.
Backed up the current MOM 2005 environment.
Installed the OpsMgr Operations database on the new database server.
Installed the RMS, Operations Console, and Web Operations Console Components on the new RMS.
Installed the Data Warehouse Components on the new database server.
Installed the Reporting Components on the new reporting server.
Validated the functionality of the OpsMgr and MOM installations.
Installed the Migration Wizard on the MOM 2005 management server and ran the wizard.
Using the wizard required installation of the OpsMgr 2007 user interfaces, which also required installation of the MSXML 6.0 parser and .NET Framework 3.0. Figure 7.12 is an example of the Migration Wizard running, displaying MOM 2005 custom-developed management packs.
The domain controllers in the environment immediately showed up as discovered.
Pushed the agent to a subset of the servers exported from the wizard.
Identified issues with agent deployment. One issue was a Windows 2003 server that did not have Service Pack 1 installed.
Validated the functionality of the MOM 2005 Operator console.
Validated the functionality of the OpsMgr 2007 Operations console.
The result of using the new hardware approach was the previous two-server configuration running MOM 2005 and a new three-server configuration running OpsMgr 2007, previously displayed in Figure 7.3. This process provided the foundation needed for the business requirements identified for the solution; after those requirements were met, the original MOM 2005 environment could be decommissioned.
Because there is no upgrade path to OpsMgr 2007, with only a migration path from MOM 2005 to OpsMgr 2007, the troubleshooting process is greatly simplified. Currently no documented errors are associated with the migration from MOM 2005 to OpsMgr 2007 on the Microsoft knowledge base at http://support.microsoft.com. Here are the best tips related to providing the cleanest migration to OpsMgr 2007 from MOM 2005:
Back up your current environment prior to starting any installation.
Plan what you want your OpsMgr 2007 environment to look like (see Chapters 4 and 5).
Understand what MOM 2005 is performing in the environment so you can replicate that functionality in OpsMgr 2007. Plan to have sufficient time available to replicate all required functionality prior to decommissioning the MOM 2005 environment.
Be careful when choosing a same hardware approach. Remember that installing the OpsMgr 2007 Reporting Component causes the existing MOM 2005 reporting environment to be unavailable, as shown in the error displayed in Figure 7.13.
Be aware of the details of the installation steps for each of the components you will use in your design (see Chapter 6).
Make an educated decision on whether to start clean or use one of the hardware approaches (same hardware or new hardware) based on the content of this chapter.
