Presently I am conducting an installation of Operations Manager 2012 to replace my customer’s current Operations Manager 2007R2
installation and I wanted to pass along some thoughts and experiences. Please note that this is not a detailed step-by-step review. At this point in the project we have finalized our architecture and implementation plans and have executed an in-place upgrade in the lab. Production deployment will occur in the very near future.
The first thing to talk about is why we chose an in-place upgrade. Normally I prefer to stand up a fresh system and perform a side-by-side migration. The side-by-side method ensures that no unresolved problems will be carried over to the new system and you can deploy agent upgrades in a phased fashion as opposed to all or nothing. In this case, my customer wants to preserve the data that’s been collected in the Reporting Data Warehouse and the in-place upgrade is the only way to save this data. Fortunately Microsoft provides very good documentation to help you plan for and to guide you through the upgrade process. The documentation at http://technet.microsoft.com/en-us/library/hh205974.aspx describes various upgrade scenarios and provides informative flow charts and checklists. For this installation we use the “Distributed Upgrade (Complex)” because our current 2007R2 system runs on
32-bit servers with SQL Server 2005 and OpsMgr 2012 requires 64-bit with SQL Server 2008. Another important item to note is that the only supported upgrade path if from 2007R2 to 2012 RTM. If you want to end up with OpsMgr 2012 Service Pack 1, you’ll need to install the Service Pack after the upgrade is complete.
To prepare for the upgrade, review the Microsoft flow charts and checklists and develop your step-by-step plan. The upgrade is not particularly difficult but there are many steps and it can be rather tedious so having a clear picture of the process is an absolute must. Another excellent resource for upgrade planning is the blogs of Kevin Holman http://blogs.technet.com/b/kevinholman/. Kevin provides many step-by-step guides for upgrades, Service Pack installs, and Cumulative Update installs. After the planning is done, make sure the
2007R2 system is functioning properly and that all clients are healthy. Also the 2007R2 system must be running Cumulative Update 4 or later. This is also a good time to review the currently installed Management Packs. Remove Management Packs that are no longer
needed and upgrade any that don’t depend on OpsMgr 2012 features. If you identify Management Packs that require 2012 functionality, upgrade those after the upgrade is completed.
One last important preparation task is to backup the RMS Encryption Key. This task is listed in the step-by-step but make sure to get a fresh backup even if your 2007R2 configuration has not changed. You don’t want to get to the point where you upgrade the Management Group and realize you don’t remember the RMS Key password!
My step-by-step plan mirrors the Microsoft steps with one exception. I replaced the SQL Server 2005 database with SQL Server 2008R2 as a preparation task instead of an upgrade task. I did this because there are special steps that need to be taken when using OpsMgr 2007R2 Reporting Services on SQL Server 2008R2 as described in this KB Article, http://support.microsoft.com/kb/2425714. By doing this as a preparation item I was able to isolate the SQL Server replacement so that I could directly deal any problems outside of the larger upgrade process. Following the instructions in the KB Article, the SQL replacement was successful.
The rest of the upgrade worked as expected until I executedmthe steps to upgrade the Management Group from the Secondary Management Server. On the Installation Location page of the upgrade wizard, the only option was a greyed out “C:\Program Files\System Center 2012\Operations Manager\” entry. This was odd because there were already files installed on the D:\ drive of the
Management Server and I wasn’t expecting new files to be installed at this point. I started searching for information on the situation but was unable to find anything. I thought perhaps this is expected and continued with the upgrade. The upgrade did complete successfully but the wizard informed me there were warnings. Unfortunately, the specific warning messages “flashed by” on the screen so I wasn’t able to see specifics. My next step was to review the setup logs which are located at %LocalAppData%\SCOM\Logs. Oddly enough, the warning messages were nowhere to be found in the logs and to make matters worse, none of my agents were communicating with the new 2012 Management Group.
Things weren’t looking good but by reviewing the event logs on the Management Server and the clients I determined that the old RMS had not been demoted. I demoted the 2007R2 RMS manually and went on to look for alerts in the Operations Console. In the Operations Console I had alerts that the SPNs had not been registered properly so I registered them manually. After rebooting the Management Server, clients started reporting to the new 2012 Management Group and I breathed a sigh of relief. After all this drama, I gathered my setup logs and contacted Microsoft Support to help explain what had gone wrong. The end result was that the logs reviled
nothing about my installation directory problem but we did find entries that indicated there were still “relationships” on the old RMS. These relationships would be clients, network devices, or other OpsMgr objects reporting to the old RMS but the logs did not
detail the specific devices. Another anomaly was that if objects were still reporting to the RMS, I should have failed the
prerequisite check and I should have not been able to proceed with the upgrade. Unfortunately, Microsoft could not provide an explanation. Anyway at the end of all this I did wind up with an OpsMgr 2012 Management Group that was fully functional.
The upgrade in our lab environment was troubled but it was ultimately successful. Being a lab system, I suspect that somewhere along the way inconsistencies may have been introduces during testing that had an impact on the upgrade. I also realized that there was an old MOM 2005 installation on our lab RMS that may have caused some issues. As you would expect our production environment is much more tightly controlled so I’m still optimistic about going ahead. Needless to say, when we execute our production upgrade I will be taking special care during the Management Group upgrade process.