High Level Steps Migrating From SCOM 2007 R2 To OM12 SP1 When Running Windows Server 2003 & SQL Server 2005

Got this request from a reader of my blog to provide the (high level) steps for migrating from SCOM 2007 R2 CU#4 (or higher) to OM12 SP1 when running Windows Server 2003 and SQL Server 2005.

Since I am very busy these weeks I don’t have the time to go through all the required steps in detail. Luckily I have written many postings touching these steps. So I will describe the required steps in a high level in this posting, referring to the relevant postings. There is much to tell, so let’s start.

First things first: tAP or upgrade?
So you have a SCOM 2007 R2 CU#4 (or higher CU# level) in place and want to migrate to OM12 SP1? However, the migration is a bit more complex since the SCOM 2007 R2 servers (RMS, MS server(s) and even perhaps Gateway Server(s) run on Windows Server 2003 and use SQL Server 2005 for the related databases and reporting functionality.

Another IMPORTANT thing to reckon with
There is NO direct upgrade path from SCOM 2007 R2 CU#4 (or higher) to OM12 SP1. It’s like this: SCOM 2007 R2 CU#4 (or higher) > OM12 > OM12 SP1.

In cases like these there are two valid approaches: either you start all over with a brand new OM12 SP1 environment and phase out the current SCOM 2007 R2 environment step by step, or you upgrade the SCOM 2007 R2 environment to Windows Server 2008 R2 SP1 x64 and SQL Server 2008 R2 SP1 first before upgrading it to OM12.

Per situation it’s a hard decision to make. Read this posting of mine, al about tAP (the Alternative Approach) and write yourself a business plan. Of course not in all details but at least covering the costs involved, required resources and time.

Like any other migration/upgrade, preparation is KEY. So prepare yourself…

Upgrade it is…
OK, so the decision is made, based on objective information and an upgrade it will be. These are the steps to follow.

1. Upgrade to Windows Server 2008 R2 SP1 x64
   This is required for all SCOM 2007 R2 server roles (RMS, MS server(s) and Gateway(s)). Best approach here is to introduce new servers (VMs are most preferred) and make them MS servers first (even when that server has to replace the current RMS). Of course for Gateway Servers, you make them Gateway Servers, not MS servers .
   
   When those new MS and Gateway servers run perfect and have no issues at all, it’s time to move them into production. Basically meaning the current MS servers are replaced by the new ones. Don’t touch the RMS yet! So the new MS servers, based on Windows Server 2008 R2 SP1 x64, will take over the monitoring functionalities of the current ones. Don’t forget about third party software like Savision, Veeam and Jalasoft for instance! The require special care and planning as well.
   
   When that’s all OK, keep the old MS servers running for a couple of days so there is always a fall back. When SCOM is still running like clock work, you can remove them (one by one!) from SCOM 2007 R2.
   
   Now you have the RMS which is still based on Windows Server 2003 and a MS which is based on Windows Server 2008 R2 SP1. This server will become the new RMS. Don’t forget about your notification model since the RMS takes care of it all. Read this TechNet library article all about promoting a MS server to RMS and demoting the current one.
   
   Don’t forget the Encryption Key here since you’ll need it! Read this posting of mine, Step B.
   
   Make sure though to test this scenario (promoting a MS to RMS and demoting an old one) in a test environment. This way you’re familiar with it!
   
   For your Gateway Servers, simply use them as the new ones and uninstall the old ones. Sometimes it’s a challenge to make the Agents communicate with the new Gateway Server when those Agents are manually installed…
   
   And don’t forget to install .NET Framework 4.0 and Microsoft Report Viewer 2010 on those same servers, preparing them for the upgrade to OM12 SP1 .
   
   
2. Upgrade to SQL Server 2008 R2
   This one is a challenge. Simply because SCOM 2007 R2 Reporting can be a pain in the b#ckside. My personal lessons learned are simply to remove SCOM 2007 R2 reporting temporarily and reinstall it on the new SQL Server 2008 R2 SP1.
   
   Another challenge might be the customized Reports. Also prepping the new SQL Server(s) with the correct security settings, CLR enabled and so on can be a challenge.
   
   Gladly I have written a series about it all, consisting out of three postings: Preparing for migrating to OM12: Moving from SQL 2005 to SQL 2008. This series covers many aspects of this step.
   
   
3. Now all is OK time to migrate to OM12
   Read this series of mine, consisting out of six postings: Migrating from SCOM R2 CU#5 to OM12.
   
   
4. The last mile
   As my much respected fellow MVP Cameron Fuller states in one of his blog postings, it isn’t possible to upgrade directly from SCOM 2007 R2 CU#4 (or higher) to OM12 SP1. The way to go is: SCOM 2007 R2 CU#4 (or higher) > OM12 > OM12 SP1.
   
   When OM12 is in place, healthy and fully functional, you can upgrade to OM12 SP1, as I described here.
   
   
5. The extra mile
   Now with OM12 SP1 in place, Windows Server 2012 and SQL Server 2012 SP1 are supported as well. So why not upgrade?
   
   Read this posting of mine: Upgrades: System Center 2012, SQL Server 2012 (SP1) and Windows Server 2012, the list at the end of the posting, number 2 for upgrading to Windows Server 2012 and number 3 for upgrading to SQL Server 2012 SP1.

With this posting I hopefully provided enough information to run an upgrade to OM12 SP1 when running SCOM 2007 R2 based on Windows Server 2003 and SQL Server 2005.