Upgrade paths to System Center 2012 Operations Manager

John Joyner explains the various upgrade paths to System Center Operations Manager 2012 for current users of SCOM 2007 R2. Find out the options before you decide if it's worth the effort right now.

When Microsoft released the suite of eight products in System Center 2012 last month, these included the new version of System Center Operations Manager (SCOM). People who use SCOM today to get their jobs done want to know about the new release, and to have answers for questions like "how soon should I upgrade?" and "what are the considerations?"

The System Center 2012 Operations Manager release includes new features like network device monitoring and application performance monitoring that may be interesting to many users of the previous product, Operations Manager 2007 R2 or earlier releases such as SCOM 2007 and even MOM 2005 (Microsoft Operations Manager, the predecessor to SCOM).

The topic of this article is upgrading to the 2012 release of SCOM for current SCOM 2007 R2 users. Because upgrading to a new version of SCOM is going to take some work, you want to know if it's going to be worth the effort. Particularly for smaller customers of SCOM 2007 R2, those with a single "all in one SCOM server" (when running already on 64-bit Windows Server 2008 R2), there is a quick upgrade experience like that shown in Figure A. For larger SCOM customers, the upgrade needs to follow a specific upgrade path with a number of steps.

Figure A - The SCOM 2012 upgrade wizard, ready to upgrade all SCOM 2007 R2 components on one server.

Strategic decisions

In general, there are no hugely compelling reasons to rapidly upgrade to the new SCOM release. However, if one of the new features is very appealing to you, this is an incentive to upgrade sooner. For example, if you have a problematic line of business web application built on Microsoft's .NET framework, the new Application Performance Monitoring (APM) feature of SCOM 2012 could enable a fast solution to lingering issues.

On the other hand, if your current infrastructure and SCOM environment are healthy and providing value, it's probably best to wait and deploy SCOM 2012 as part of a longer-term, broader plan. Thanks to the new System Center licensing that includes all the management products, many organizations will find economic benefit in deploying multiple System Center 2012 components in private cloud scenarios. Best practice is to deploy SCOM in concert with the other components to get the most out of Virtual Machine Manager (VMM), Data Protection Manager (DPM), Configuration Manager (SCCM), Service Manager (SCSM), Orchestrator, App Controller, and Endpoint Protection.

All upgrade paths are supported to either (1) re-use the existing database and carry the SCOM 2007 R2 management group forward into SCOM 2012 format, or (2) to stand up a new, parallel SCOM 2012 management group and seamlessly migrate agents to the new management group. As described in the following paragraphs, whether you can upgrade a particular SCOM 2007 R2 component in place depends on the operating system (OS) and SQL Server version installed on the existing computer.

The decision to upgrade the SCOM 2007 R2 database or migrate to a new SCOM 2012 database is a business decision. If you want to maximize the performance and scaling potential of your new SCOM 2012 management group, start with a clean database and migrate custom management packs and settings from OpsMgr 2007 R2. Also consider starting with a clean database if your SCOM 2012 architecture is delivered from a different platform or service location than SCOM 2007 R2.

In-place upgrade

If you have SCOM 2007 R2 running on supported operating system (OS) and SQL platforms, you can upgrade in place on all SCOM components and save a lot of time. In a single-server scenario, this is a Windows 2008 R2 Root Management Server (RMS) running SQL Server 2008 SP1 or SQL Server 2008 R2. Both the SCOM database and the SCOM components are upgraded to the SCOM 2012 release. In a multiple-server SCOM deployment, these OS and SQL requirements exist for all computers you want to upgrade to SCOM 2012 components. Before you can upgrade the SCOM 2007 R2 database to SCOM 2012 (which is the last step in an upgrade project!), every component in the management group needs to be running SCOM 2012. That means every agent, gateway, report server, web console, and secondary management server needs to be upgraded to SCOM 2012. Microsoft makes this easier with an Upgrade Helper Management Pack. The helper management pack (Figure B) keeps track of which SCOM 2007 R2 components still need to be upgraded, and in what order you should upgrade them.

Figure B - The Upgrade Helper Management Pack keeps track of the order of SCOM 2012 component upgrades.

Side-by-side migration/update

If you have SCOM 2007 R2 running on non-supported operating systems (OSs) and/or database platforms, you will need to migrate one or more SCOM components. However, even if your RMS is running on an unsupported platform, such as a 32-bit OS or a clustered RMS, you can still upgrade the SCOM 2007 R2 database in place by using an ‘upgrade from secondary management server' scenario.

  • If you have management servers or gateways that can't upgrade in place, migrate the SCOM 2007 R2 role off the computer, then reinstall the SCOM 2012 role on a computer that meets requirements.
  • Optionally name the upgraded computers running SCOM 2012 components the same names as their SCOM 2007 R2 predecessors.
  • These role migration scenarios most likely involve management servers and gateways running 32-bit OS and any RMS running in a fail-over cluster. Neither of these platforms can upgrade in place.

Upgraded components that are downstream can continue to report to legacy upstream components when rolling out an upgrade. For example, SCOM 2012 agents can report to a SCOM 2007 R2 gateway or management server.

Likewise, SCOM 2012 gateways can report to SCOM 2007 R2 management servers. Leveraging this concept, 'leap-frog' upgrades from the edges of your SCOM 2007 R2 infrastructure, in an inward direction.

Figure C shows how multi-homed agents (in the bottom row of the diagram) communicate with legacy SCOM 2007 R2 and new SCOM 2012 management groups simultaneously in a side-by-side migration scenario.

Figure C - Migrating to SCOM 2012 management group using dual-homed SCOM 2012 agents.