Migrating from SCOM R2 CU#5 to OM12. Part II: Prepare yourself…

----------------------------------------------------------------------------------
Postings in the same series:
Part I   - The environment
Part III – Pre Upgrade Tasks for Operations Manager
Part IV – Upgrade Tasks for Operations Manager
Part V  – Upgrade Tasks for Operations Manager, continued
Part VI – Wrapping Up 
----------------------------------------------------------------------------------

In the second posting of this series I’ll describe the preparations which need to take place prior you start the actual migration. Please take note that during the migration itself other preparations are required as well, also referred to as Pre-Upgrade Tasks (two sets of them actually) and one set of Post-Upgrade Tasks.

Before I start however I want you to be aware of these two important items (A & B):

A: Dead links
The set of (online/offline) OM12 documentation Microsoft offers isn’t totally error free unfortunately, like containing dead links. For instance, the links in the (online/offline) documentation referring to the System Center 2012 - Operations Manager Upgrade Process Flow Diagrams don’t work many times and result in a Page Not Found error:

Or you end up on a page which only shows a part of the diagram and isn’t clickable at all..

Also some links referring to the Supported Configurations page results in the same Page Not Found error. So for the completeness I put the set of working links (at this moment that is) here:

• OM12 Supported Configurations;
• Single-Server and Distributed Upgrade (Simple) Process Flow Diagram;
• Single-Server Upgrade (Complex) Process Flow Diagram;
• Distributed Upgrade (Complex) Process Flow Diagram.

You’ll find yourself many times on these pages since they contains tons of worthwhile information.

B: What SQL Collation settings do I need?
The (online/offline) documentation isn’t very clear here. For instance based on the information on this page under the header Verify the SQL Collation, one might think that different collation settings are supported by OM12.

However, IMO(!), the only real supported collation setting is SQL_Latin1_General_CP1_CI_AS as stated on this website all about the Supported Configurations for System Center 2012 - Operations Manager. As far as I am concerned, that page is leading. So make sure you run that SQL Collation setting.

Some MPs (Exchange 2010 Reporting MP and the nWorks Veeam MP) require that SQL Collation setting in order to function properly. So be warned!

OK, now it’s time to start.

Complex or Simple Upgrade Scenario
Basically Microsoft considers two kinds of upgrade scenario’s. Simple or Complex. By no means a Simple migration doesn’t refer to a small scaled SCOM R2 environment. Nor does a Complex migration refer to enterprise scaled (distributed) SCOM R2 environments.

Simple or Complex refers in this case whether your SCOM R2 environment runs on by OM12 supported software. The most important components here are the Server OS version for your Management Servers (RMS, MS and Gateways) and SQL server and the version of SQL Server:

1. Required Server OS for RMS, MS and Gateway Server:
   Windows Server 2008 R2 SP1;
   
   
2. Required Server OS for SQL:
   This might seem a no-brainer but there is caveat here. For SCOM Reporting Windows Server 2008 R2 SP1 is required where as for the other SQL Server roles (Operational database and the Data Warehouse) Windows Server 2008 SP2 (or higher) will suffice. In smaller environments a single SQL Server runs both databases and hosts the SSRS instance for SCOM R2 Reporting as well. For this kind of SQL Servers Windows Server 2008 R2 SP1 is required! So check and double check!
   
   
3. Required SQL Server version:
   At least this is the same SQL Server version across all OM12 roles (Operational database, Data Warehouse and SSRS): SQL Server 2008 SP1 or higher (SQL Server 2008 R2, or SQL Server 2008 R2 SP1).

When these components are supported by OM12 you have a Simple upgrade scenario and when not, well you find yourself in a Complex upgrade scenario. Of course, when your SCOM R2 environment runs on non-supported OM12 Server OS and/or SQL Server version, you’ve got ‘some’ work to do BEFORE you can even think of migrating SCOM R2 to OM12. However, Microsoft has documented these steps as well.

But even when your SCOM R2 environment runs on SQL Server 2008 SP1 or higher and the RMS, MS servers, Gateway Servers and SQL Server(s) run on Windows Server 2008 R2 SP1, the migration scenario can still become a complex one? Why? Read on…

Complex and Simple Upgrade Scenario’s in Real Life
IMHO, there aren’t many SCOM R2 environments which run only Microsoft software. I have seen many SCOM R2 environments which run third party software like, but not limited to:

1. Third Party MPs (Veeam, OpsLogix, Jalasoft, Bridgeways, NiCe etc etc);
2. Third Party add-ons (Savision Live Maps™, Savision Vital Signs™, etc etc);
3. ACS add-on Secure Vantage (SVT).

For this kind of software, contact your vendor in order to find out whether this software (or better the version) supports OM12. And not just that, also check whether new or updated licenses are required.

Sometimes third party software can be a challenge to migrate to OM12. For instance SVT might require a whole upgrade scenario of its own when you’re running an old version of SVT, before you can even consider the migration to OM12.

Another thing to reckon with are the MPs which are supplied by the community, like (but not limited to):

• xSNMP MP Suite
  When this MP is in place, your SCOM R2 environment can be upgraded to OM12. The xSNMP Suite will continue to work but you can’t add new SNMP devices since the base discovery class is changed in OM12 nor can you rediscover these devices. Which basically means the xSNMP MP becomes static in your OM12 environment. (Thanks to Pete Zerger for this information);
  
  
• OpsLogix Ping MP
  This MP adds some functionality to the regular SCOM R2 Console by using a special dll file. OpsLogix has stated they’re working on an OM12 version. The dll used for the SCOM R2 Console won’t work with the OM12 Console. So remove that file. Your configuration for the OpsLogix Ping MP will stay in tact as long as the OpsLogix Connector isn’t removed.
  
  
• Addendum MPs
  For some MPs there are addendum MPs (Server OS and AD for example). Check these MPs before migrating a SCOM R2 environment which runs those MPs to OM12.
  
  
• SCC Health Check Reports MP
  This MP seems to work properly in OM12.
  
  
• Logical Disk Space Report
  No issues. Works fine in OM12.
  
  
• PKI Verification MP
  This MP seems to work properly in OM12.

Therefore, build yourself an OM12 test environment and test those MPs in order to see whether all is still OK. In some cases it might be required to remove some MPs before starting the migration. Or, remove some parts of it, like the dll file used for the OpsLogix Ping MP since the SCOM R2 version isn’t compatible with the OM12 Console.

As you can see, even when your SCOM R2 environment runs on supported Server OS versions for OM12 and SQL is OK as well, there still might be some challenges which need to be addressed. And: NEVER ASSUME! Always be sure! So build that OM12 test environment.

So the preparation for migrating to OM12 comes down to these steps:

1. RTFM the official Microsoft documentation about the upgrade process. Not just once but a few times. And don’t stop thinking. When in doubt go the forums and post your question;
2. Familiarize yourself with the Upgrade Process Flow Diagram which fits your situation. Know what steps you have to take and in what order.
3. Check whether the Server OS and SQL Server versions are in line with OM12. When not, fix it. Might sound easy but it isn’t, I know from first hand experience. So take your time;
4. Check the third party MPs and add-ons you’re running. Check whether they’re OM12 compatible. And check the licensing requirements. When something isn’t OM12 ready, fix it according the  advices as set out by the vendor;
5. Know what you’ve got, like (but not limited to):
   1. RMS;
   2. How many MS Servers;
   3. How many Gateway Servers;
   4. How many SQL servers are being used for SCOM R2;
   5. Which server hosts the SCOM Web Console;
   6. How many pushed SCOM R2 Agents;
   7. How many manually installed SCOM R2 Agents;
   8. The SCOM R2 service account credentials.
6. Build yourself a test environment, even when it’s only a single-server solution (it’s better to run two OM12 MS servers, but when resources are really limited for some basic testing, a single-server solution will suffice);
7. Check the backups of the RMS, MS servers, Gateway Servers and SQL Server(s) used for SCOM R2. Are they in place, functional and OK?

Only now you’re ready to start the upgrade as described in the documentation provided by Microsoft. In the next posting of this series I’ll describe the first steps in the upgrade process, so stay tuned.