locked
Upgrading from SCORCH 2012 to 2012 SP1 - Some advice please!.. RRS feed

  • Question

  • Hi, I have SCORCH 2012 RTM installed and an planning to upgrade to SP1 very soon.  After a quick skim at the upgrade process, it looks like its more of an uninstall/reinstall, but just reusing the SQL DB backend?. 

    In my case the current 2012 rtm build only has one 'active' runbook which is connecting to my SCOM 2007R2 infrastructure using the old 2007R2 IP.  I have several other build runbooks on which were used for one-off solutions/POC's which I would like to retain at least for reference so I can replicate in SCORCH 2012 SP1.

    A few queries/clarifications:

    1. Is there any benefit doing an upgrade as opposed to building a new SP1 environment - getting the additional servers (VMs) isnt an issue.  Can I not just export the runbooks from current SCORCH 2012 and import into SP1 - I assume the IP's for connecting to SCOM 2007R2 is the same for both 2012 and SP1 - this sould at least give me the runbook designs so I can at least easily replicate when

    2.  What is the advantage of doing an upgrade.

    3.  If I build SCORCH 2012 SP1 can I install IP's for both SCOM 2007R AND SCOM 2012 SP1 to create the maintenance mode runbook for the existing and new SCOM builds to run concurrently while the migration from old to new takes place (which is likely to be a few months).  PS I also think I stumbled across some details where Maint mode is implemented slightly different in SCORCH for SCOM 2012 over 2007 so the runbooks will be different, not just copied!

    Any advice much appreciated!...



    • Edited by new2scom Thursday, June 20, 2013 8:28 AM
    Thursday, June 20, 2013 8:26 AM

Answers

  • Thanks both for the feedback.  Based on your comments I think I'm leaning towards a clean side by side build - I forgot to mention that for any of my new builds I am implementing on server 2012 OS (which I've done for SCOM 2012 build) - so the heads up on the powershell issue and the Get Alert activity is very helpful.  Cheers.... :-)
    Thursday, June 20, 2013 9:38 AM

All replies

  • Hi,

    1) If you import the ois_export-file with the Activities from the IP of SCOM2007R2 you must have installed this IP (for SCOM2007R2) to see and use the Activities in the new environment. The Ids for the Activities in IP for SCOM2012SP1 and SCOM2007R2 are different. If yo do not install the old IPs you can't use the Activities after import.

    2) There are some fixes in SP1 (example: http://support.microsoft.com/kb/2768366) and you can use the SP1 IPs: http://technet.microsoft.com/en-us/library/jj614522.aspx

    3) Yes, you can use the IP for SCOM2012SP1 and SCOM2007R2 parallel. Install the Operator Console of SCOM 20012 SP1 on the Runbook Servers!

    Regards,

    Stefan


    www.sc-orchestrator.eu , Blog sc-orchestrator.eu

    Thursday, June 20, 2013 9:04 AM
    Answerer
  • Stefan, thanks for the reply, thats helpful.  Re Question 2 what I really meant to say is why do an upgrade or whats then benefit of doing an upgrade over and above just a side-by-side build of a new 2012SP1, leaving existing in place? Just seems to me it might be easier to build new environment so existing runbooks will continue to run and I can then take my time to reimplement them when I get 2012SP1 build - and by that stage I'll possibly be connecting to SCOM 2012 SP1?

    Cheers

    Thursday, June 20, 2013 9:24 AM
  • My 2 cents worth as far as my upgrade experience went....

    I went from a 2008 R2 OS to 2012 OS, which just added to the complexity. The Orchestrator upgrade went smoothly, and your plan of attack above sounds like you have actually thought about it which is great!!

    After my upgrade was complete, a large number of my runbooks no longer worked! Small oversight on my part in that Server 2012 uses powershell v3 by default, as opposed to Server 2008 R2 which uses v2. I had a lot of PS scripts and required some tweaking in order for them to continue to work. It wasn't just the fact that the Orchestrator OS was now different, but also some of the IP's for other System Center products (SCCM in particular) are expecting certain requirements for when trying to execute scripts. Orchestrator uses an x86 version of PS by default and the powershell module for SCCM wants to execute things in an x64 PS session.

    Needless to say there was a little 'extra' work that went on that I had failed to account for - but overall the process is pretty solid.

    Good luck!

    adrian

    Thursday, June 20, 2013 9:28 AM
  • Yes,

    As you I think building a new environment is easier. I experience problems with "Get Alert" after de-install before and install the IP for SCOM2007R2 after the upgrade at one customer: http://social.technet.microsoft.com/Forums/en-US/8247b6b8-d84b-46f5-a964-2d04568eb5cb/orchestrator-2012-with-ip-for-operations-manager-2007-r2

    Regards,

    Stefan


    www.sc-orchestrator.eu , Blog sc-orchestrator.eu

    Thursday, June 20, 2013 9:31 AM
    Answerer
  • Thanks both for the feedback.  Based on your comments I think I'm leaning towards a clean side by side build - I forgot to mention that for any of my new builds I am implementing on server 2012 OS (which I've done for SCOM 2012 build) - so the heads up on the powershell issue and the Get Alert activity is very helpful.  Cheers.... :-)
    Thursday, June 20, 2013 9:38 AM