OM12 and SCOM R2: Back to the Future

Even though I just returned this week after a three week holiday, I got this question already multiple times:

Why not install the beta of OM12 in the production environment?

First some background about the reasons why companies ask questions like these. Actually there are multiple reasons, like:

1. Some companies haven’t any monitoring solution in place, so they start fresh. Why not install the latest version of Operations Manager?
2. Other companies already have SCOM in place and want to run OM12 Beta since it offers so much new functionality.
3. Other companies want to run OM12 Beta alongside SCOM R2 in their production environment.

All mentioned reasons seem valid, but there are some caveats to reckon with:

1. OM12 Beta isn’t production ready yet, it’s still BETA after all. True, some companies are running it already in their production environment (including the company I work for) but that’s all under the Technology Adoption Program (TAP) umbrella. The amount of available slots in any TAP program is limited. Based on TAP participation one is entitled to support, outside TAP you’re on your own (of course there is still the community but outside the TAP program you won’t receive official support from Microsoft).
   
   
2. Running OM12 Beta is a good idea. You’ll have time to get familiarized with the future edition of Operations Manager. Also time to find bugs and report them. Having said that, OM12 Beta shouldn’t be installed in a production environment – when you don’t participate in the TAP - but in Test/Acceptance environments. This way you have the best of two worlds: a fully supported SCOM R2 environment in Production and an isolated environment to test drive the successor of SCOM R2. 
   
   
3. SCOM (R2) is the officially supported mainstream version of Operations Manager today. Looking back at how it started (SCOM 2007 RTM > SP1 > many bug fixes, patches and hotfixes > SCOM R2 > CU#1 up to CU#4) the product has covered many miles and has seriously grown up. So SCOM R2 CU#4 is still a good and solid product, even with it’s successor being on public beta tour. This is not just me, being Microsoft minded, but it’s also backed up by Gartner.
   
   
4. And last, but not least: Page 4 of the document OM12_Beta.docx (found in the download package containing all OM12 Beta related documents) tells it all actually:
   

Having said this, there are certain things you can do to prepare the environment for a future upgrade to OM12.

Prepare yourself…
There are two situations you can find yourself in:

1. You haven’t SCOM R2 in place yet but are about to install it since you want to monitor your environment pro-actively.
2. You already have SCOM R2 in place, fully functional.

Good News
No matter you’re in Situation 1 or 2 there is good news. The RTM version of OM12 will support an upgrade from SCOM R2 (and a certain CU level) to OM12. So that’s good news.

Bye RMS
Another similarity is the RMS. That server role, the SPoF (Single Point of Failure) in any SCOM environment (unless when the RMS is clustered, yikes!), will be gone in OM12. The RMS specific roles will be divided among all OM12 Management Servers. Like moving from the NT4 PDC/BDC era to the W2K0x DC era :).

In an upgrade scenario from SCOM R2 to OM12 it will mean that somewhere along the road, the RMS will be set aside. When running a clustered RMS or an environment with no secondary Management Servers, it can be a challenge.

The supported platforms and architecture
OM12 Management Servers require Windows Server 2008 R2.  The databases requires SQL Server 2008 SP1 or SQL Server 2008 R2.
And as we all know, Windows Server 2008 R2 comes only in one architectural flavor: 64 bits. So SQL Server needs to be x64 as well since OM12 doesn’t (same goes for SCOM) support a 32-bits database on a 64-bits platform.

Situation 1 in more detail
So when you’re in Situation 1, it’s rather simple: install your new SCOM R2 environment on W2K08 R2 servers and run SQL Server 2008 SP1 (with the latest CU applied) or SQL Server 2008 R2 (with the latest CU applied).

Think TWICE about how to run your RMS: as a single server or as a cluster. Personally, I wouldn’t choose for a clustered RMS anymore, but provide an additional MS – on top of the other MS servers – instead.

And you’re new SCOM R2 environment is upgrade ready as it can be based on the information available today.

Situation 2 in more detail
This can be a bit more of a challenge. Suppose you’re running SCOM R2 on Windows 2003 server. Now what? Can you upgrade those servers to W2K08 R2? No, you can’t.

When you want to start such an upgrade path the server OS MUST be 64 bits already (as stated before W2K08 R2 is only available as 64-bits architecture and there is no upgrade from any 32-bits architecture to 64-bits architecture) AND you need an additional step: W2K03 x64 > W2K08 x64 > W2K08 R2.

It takes a lot of time and can be prone to error. It’s better to facilitate new servers running a clean install of W2K08 R2 SP1 and use those servers as new SCOM R2 Management Servers. When those new MS servers are in place and fully functional WITHOUT any issues (check the event logs!!!), you can phase out the old SCOM R2 MS servers, one by one.

What about the RMS? Actually, it’s easy. Leave it as it is. Since OM12 RTM will render the RMS useless. So no upgrade is required here. When you run a SCOM R2 environment with only a RMS and not a single MS server, it’s time to install one, based on W2K08 R2. Or even better TWO since the RMS will be gone in OM12 and it’s a bad thing to run just ONE MS server. This is also valid in SCOM R2 actually…

How about SQL? When you’re running SQL server 2005 it’s time to run the upgrade to SQL Server 2008, as mentioned here. When the SQL server is also W2K03 based, it’s perhaps a better idea to provision a NEW SQL 2008 server, based on W2K08 R2 SP1 and move the SCOM databases to that server. When you do that there are certain things to reckon with. Perhaps I’ll blog about them later on.

Wrapping Up
As you can see, there is much to reckon with when you want to upgrade SCOM R2 to OM12. The good thing is that it will take some months before OM12 goes RTM.

While it’s beta you’ll have time to get acquainted with it, to see what’s it has to offer compared to SCOM R2 (many many things!!!), persuade your management to upgrade to OM12 AND time to prepare you’re environment for it.

This way it won’t be a Big Bang scenario but a well prepared move to the NEXT GENERATION of monitoring.