Monday, May 21, 2012

Migrating from SCOM R2 CU#5 to OM12. Part VI: Wrapping up

----------------------------------------------------------------------------------
Postings in the same series:
Part I - The environment
Part II - Prepare yourself
Part IIIPre Upgrade Tasks for Operations Manager
Part IV – Upgrade Tasks for Operations Manager
Part VUpgrade Tasks for Operations Manager, continued
----------------------------------------------------------------------------------

In the final posting of this series I’ll write about the final steps. Yes, I know. We successfully migrated a distributed SCOM R2 CU#5 environment to OM12. So what’s more to share? As stated before, any migration has three phases:

  1. Preparation;
  2. Actual Migration;
  3. Cleaning and wrapping up.

The second phase costs most times about 30% of all the required resources and time where as the preparation itself takes about 40 to 50% and the wrapping up about 10 to 20%. So that last phase is important as well. Besides the regular technical stuff (like importing and configuring ported MPs like the OpsLogix Ping MP for instance) there is also such a thing as DOCUMENTATION.

Much has changed so make sure the documentation, all about your OM12 environment is up to specs as well. When you don’t have that much documentation of your previous SCOM R2 environment, it’s time to do it now. Check this posting of mine, all about what good documentation of any SCOM/OM12 Management Group should contain…

Most Important Steps and Things to Reckon with
In any SCOM R2 to OM12 migration there are certain steps which are crucial for success and delivering a solid OM12 environment which is future ready and robust. So make sure you get them right from the start. It will save a lot of work not only for now but also in the future. Even though some items might sound too stupid to be mentioned, I still put them here in the list.

  1. Think About The Future – Windows Server 2012
    Any OM12 Management Server (or Gateway Server) for that matter, will be present in your IT environment for the first two to three years to come. So whenever possible, used the latest version of the Server OS which is RTM at that moment. Even though Windows Server 2012 isn’t supported now by OM12, changes are that it will be with the release of SP1 for System Center 2012. Which makes sense.   

    When you aren’t in the process of migrating to OM12 with in the next few months, consider Windows Server 2012 as a serious option for the Server OS for your OM12 Management Servers and SQL Server(s) used for hosting for your OM12 databases and SSRS functionality as well.

  2. Think About The Future – SQL Server 2012
    Same thing goes for the SQL Server version. Even though SQL Server 2012 isn’t supported yet by OM12, my guess is it will be supported when SP1 comes out.

    Even when your organization isn’t ready for this latest version of SQL Server, please consider that the mainstream support for SQL Server 2008 (R2) will end on the 14th of January 2014, as stated on this webpage of Microsoft. And many times a OM12 environment isn’t installed for just two years.

    Of course, there will be upgrade scenario’s in order to move from SQL Server 2008 (R2) to SQL Server 2012 but it will take a lot of time (again) and it won’t be a low care move as well. So it’s better to invest more in the beginning, resulting in a low maintenance OM12 infrastructure then to investing over and over again.

  3. In-place  Upgrade or Along-side?
    Even though SCOM R2 CU#5 can be upgraded to OM12, it doesn’t mean it’s the best way to go about it. Sometimes a SCOM R2 environment contains so many customizations, third party MPs, add-ons like ACS with SVT (Secure Vantage) and a past (installed fresh when SCOM was RTM, SP1 installed, upgraded to SCOM R2, every CU installed…), that’s better to start fresh again with OM12.

    But wait! This particular SCOM R2 environment has so many customizations that it will take a lot of time to rebuild it! So therefore an in-place upgrade is the way to go! Even though you might be right here, the same arguments you use in order to run an in-place upgrade might be the same ones to be used for choosing for an along-side approach:

    Many customizations
    :
    OK. But is every customization a good one? I mean much has changed under the hood when comparing SCOM R2 with SCOM RTM. Also your level of knowledge and experience has changed for the better in the last years. My bet is many things you did back then won’t make it today…

    Third Party MPs, add-ons:
    Yes, the licenses can become costly. Therefore keep the support contracts in good order by renewing them. It will create the necessary space for negotiations for the new licenses in your OM12 MG.  My bet is the vendor would like to sell you the OM12 product as well… Sometimes an in-place upgrade might be too costly in time and required resources. Suppose you have a SVT environment in place, based on ACS. Changes are it isn’t based on the latest version of SVT which supports OM12 out of the box. So you have an additional challenge to be dealt with. In cases like these it’s better to start fresh.

    The Past
    When your SCOM R2 environment came a long way, from like SCOM RTM and went through the upgrade paths SCOM RTM > SCOM SP1 > SCOM R2, changes are many SCOM R2 Management Servers are still running Windows Server 2003 and perhaps even SQL Server 2005. So you have to upgrade those components first before moving to OM12. Which can be done of course. But it will take time ALSO for the required preparations. Many times SCOM R2 Management Servers do way much more than only having monitored Windows Servers reporting to them, so those servers must be looked into very well, before replacing them by SCOM R2 Management Servers based on Windows Server 2008 R2 (or Windows Server 2012).

    On top of it all, changes are that the requirements for the availability of the monitoring solution have been changed over the years. First when SCOM RTM was installed, monitoring wasn’t looked upon as really crucial. Much has changed. So the organization might require a HA OM12 environment. Lucky you, the OM12 Managements Servers are HA out of the box. But what about your SQL Server for OM12? Another item on the list which might push you to choose for the along-side scenario.

    GiGo
    Garbage In, Garbage Out. Seriously, is your current SCOM R2 environment 100% OK? Never having doubt about it? Never ever had moments like ‘ouch’ and ‘oops’? Never made a MP which almost wrecked your environment? Really feeling happy about it? Not a single shred of doubt? Never thinking: ‘By what I do know now, I would have done TONS of things differently…’?

    Forgive me for making you doubt, but this one (GiGo) deserves really attention. First of all an upgrade WON’T FIX ANY ISSUES. So when you have issues now, you’ll find them back in OM12. Period. Secondly, perhaps you current monitoring environment doesn’t fit the bill anymore. Simply upgrading it won’t help you either.

    In cases like these it’s good to consider an along-side approach as a serious option as well. Of course, good planning and designing is required here as well. That way you have two well founded options to choose from.

  4. Prepare Thy Self!
    Sometimes I bump into environments where upgrades to newer versions of SCOM/OM12 went wrong. Seriously wrong. Only restores of the old situation before the upgrade started, will help. However, the backups aren’t there (anymore) or can’t be used since the backups aren’t good. This is really bad for any organization and doesn’t bring them anything good. In situations like these only a total rebuild remains to be done.

    When looking back at what caused the upgrade to go bad like that it turns out that a certain set of these ‘events’ took place:
    - Not enough preparation;
    - Not enough testing;
    - Not enough time (sometimes schedules which are too tight);
    - Not enough knowledge of the newer product;
    - Not enough knowledge what’s in place and will be touched by the upgrade as well;
    - Not enough RTFM;
    - Current environment was already flawed (SNAFU) and upgrade was expected to ‘fix’ it;
    - Requirements for upgrade weren’t met but the upgrade was started none the less;
    - People performing the upgrade had to perform other tasks during the upgrade as well;
    - Servers were switched off while performing the upgrade by the hardware team because they didn’t know it;
    - Upgrade was performed in the wrong order since the documentation wasn’t completely read or properly understood;
    - No backups or partial backups of faulty ones.

    And please don’t laugh! This could happen to you as well! So be careful and PREPARE yourself, like (BUT NOT LIMITED TO!) reading this series of postings all about upgrading to OM12 in conjunction with reading all the documentation Microsoft provides. And when it’s too much, just tell your boss. It’s better to communicate fair and square by telling what’s missing and how it could be addressed instead of pushing along and BREAKING it…

Again, upgrading isn’t to be taken too lightly. But is most certainly possible. Only prepare yourself and think about the other approach as well: along-side, where a new OM12 MG is freshly installed and step by step replacing your current SCOM R2 environment. I can’t (and won’t!) tell you what’s best to do. You’re in charge of your MG so you know best. Don’t hesitate to communicate with your team and managers. Involve them and you’ll be surprised!

No comments: