Share via

System Center 2012 Operations Manager: Upgrading from SCOM 2007R2

  • Article

Scope

This wiki page is aimed at collecting common issues and pitfalls when upgrading from System Center Operations Manager 2007 R2 to System Center 2012 Operations Manager.

 

Introduction

There are two paths to upgrade your System Center Operations Manager infrastructure to System Center 2012 Operations Manager:

  • A side-by-side upgrade – a new Operations Manager Management Group is added, agents are multihomed and then all the management packs, notifications, account and so on are added to the management group. Eventually, the old management group can be removed.
  • An in place upgrade – the current Operations Manager Management Group is upgraded, management servers first, then agents and in the end the root management server and SQL databases

See Upgrading to System Center 2012 - Operations Manager 

Recommendations 

Choosing the right upgrade method requires some planning, it is especially important to have a B plan if something goes wrong.

Common suggestions:

  • Never opt for an in-place upgrade if you cannot afford downtime for your monitoring infrastructure
  • For in-place upgrade you need to have a proper way to revert to the pre-upgrade status. This is true for gateways and management servers and critical for root management server and databases. Virtualization here come to rescue, but if your infrastructure is not virtualized be prepared for restores and extended downtime
  • If you do SNMP monitoring not using the product data sources, for example there are several MP that works with the OS SNMP service directly or via WMI, then you have to plan for coexistence since Operations Manager now uses its own SNMP network stack and you’ll end up with port conflicts if you use the OS SNMP service.
  • For side by side migration prepare and test a content migration plan
  • For side by side migration remember you cannot discover anymore SNMP devices the old way, so you should test and check if the SNMP monitoring Management Packs in use will work properly with the new SNMP stack
  • For side by side migration be prepared for some agent overhead derived from multihoming, several rules will be different in the new Management Group so cookdown won’t help so much.
  • Don't dare assume that if it worked in OpsMgr 2007 R2 then it must work in 2012, while this is generally true there are differences. In particular I want to highlight a big difference in channel optimizations that could lead remote agents to be unable to communicate, for more information on this topic see OpsMgr 2012 – agents across slow WAN links are unable to communicate.

 

In place upgrade - Issues from the field

To understand when issues can arise it is necessary a brief introduction on how the upgrade process works.

The “upgrade” process in reality first removes the Operations Manager 2007 R2 binaries and then installs the new code and settings. This implies if something goes wrong with the setup process there’s no true rollback, what you get in this case is a system without Operations Manager, any version, installed. Direct consequence if you try to launch setup again, it won’t find any old Operations Manager installation, which in turns implies it will pretend to perform a clean installation. This is typically not an issue for agents, but it can be troublesome for management servers and critical for the root management server and supporting sql databases. Then only recovery step in this case is to perform a system and database restore, depending on your infrastructure and databases size it can take a long time. This is why we discourage an in-place upgrade unless your entire Operations Manager infrastructure is virtualized, in this case snapshots can be used to speed up the rollback if it is needed.

In real world the blocker we got were related to database inconsistencies, for example we had managed entities with display strings more than 256 characters long or user roles with missing ENU display string. In both this cases we needed to revert to the pre-upgrade state, clear up the database and run setup again. You shall remember that during the RMS and databases upgrade the monitoring service is suspended. Again, be prepared to downtime if you go for an in-place upgrade. For more info on database inconsistencies see  Know issues when upgrading from OM 2007 R2 to OM 2012.

Another issue we faced on a customer site was related to the fact with used the dbcreatewizard to create the old Operations Manager database. This issue is well documented in this knowledge base article: http://support.microsoft.com/kb/2711375.

After the upgrade has completed you should expect for a prolonged CPU usage on SQL server, depending on the SQL server capacity and the size of the management group this can take several hours. During this period configuration and topology are recalculated, data warehouse reports and stored procedures are redeployed and so on. If you performed any unsupported mods to your databases plan for a review since they’ll be overwritten.

 

Side by side upgrade – Issues from the field

During the multihoming phase, only a slight increase in CPU usage can be observed. In the other hand, a tangible augment of the memory foot print of the agents is highly probable. In certain cases, this increase can go over the private bytes threshold over which the agents are restarted. This is not a major stopper, but if you don’t want to get into it, you can override the private bytes thresholds in both Management Groups to avoid agents restart.

 

References