The road to Operations Manager 2012 – Upgrading to

Last updated  Nov 30th, 2012


This article is a collection of experiences from the field when upgrading from Operations Manager 2007 R2 to System Center 2012 Operations Manager. I will keep it up to date with the new discoveries my team and I will come through. It will not detail the upgrade process, already well documented on Technet (see references), but the common pitfalls and errors to avoid.

It will also be the main index for “The road to Operations Manager 2012” series (see the references section).


As you may know, 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

The two approaches are different and have implications in terms of risks, availability and implementation time. In the following table, I try to summarize the high level pros and cons of both approaches:



In place

Monitoring availability

100% availability, but operators may need to watch two different consoles

Downtime when upgrading the databases.

Service loss risk


The database upgrade phase is critical, be prepared for the need to restore the RMS and the databases

Monitor on pair with old infrastructure

Can be challenging especially if monitoring SNMP devices, specific instances overrides need to be recreated, explicit membership groups need to be repopulated

All your monitoring rules are upgraded

Implementation time

It will take time especially the content migration phase

The minimum you can get


Why upgrade

Why should I upgrade? This is not a silly question at all. If you have a sound Operations Manager 2007 R2 infrastructure you should ask yourself when it will be worth to upgrade (sooner or later you must upgrade for support reasons, but mainstream support will end on July 2014, so there’s still plenty of time).

If you take away all the marketing hypes, there are still many good reasons to upgrade; the following is my personal priority ordered short list:

1.      Better agents reliability – agents are much reliable, with Operations manager 2007 R2 CU 5 we had on average 1,5% trouble agents each day, after upgrading the troublesome agents ratio turned down to 0,5%

2.      Application Performance Monitoring – APM is the most effective new feature in System Center 2012 Operations Manager. If you don’t know yet about APM take a look here

3.      The new dashboards that can be embedded in Sharepoint sites are worth a look, even if they have some limitations in this release

4.      Cross platform support (xPlat) has been improved and J2E basic monitoring has been added, for those who wants to extend Operations Manager outside the Microsoft realm this can be a driver

5.      Network monitoring is a v1 release, it’s an acceptable starting point for ports monitoring, but don’t expect fireworks


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

My 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 you can take a look at 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:

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. So, if you performed any unsupported mods to your databases be ready to reapply all what’s still needed. In our specific case we applied a mod for the Exchange 2012 aggregation we had to port after the upgrade. The red line in the following graph is the SQL server CPU usage before and after the mod.


Remember to install .net framework 4.0 on all your Management Servers and Gateways, it is needed even if you don’t plan to use xPlat or Network Monitoring.

Remember, after upgrade your MG is set to evaluation mode, so you need to enter the proper license key to fully activate it, see

Side by side upgrade – Issues from the field

During the multihoming phase we experienced only a slight increase in CPU usage, but a tangible augment of the memory foot print of the agents. In certain cases, this increase went 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.


The road to Operations Manager 2012 – Upgrading ACS

The road to Operations Manager 2012 – Sites and gateways

The road to Operations Manager 2012 – MP compatibility

The road to Operations Manager 2012 – Managing *nix systems

Upgrading from System Center Operations Manager 2007 R2

Does-It-Work-In-OM12? Serie

SCOM 2012 – Critical Considerations in Migration Planning

Know issues when upgrading from OM 2007 R2 to OM 2012

OpsMgr 2012 – agents across slow WAN links are unable to communicate


– Daniele

This posting is provided “AS IS” with no warranties, and confers no rights.

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: