CA Service Management

Expand all | Collapse all

SM 17.1 conventional to 17.1 AA restore

  • 1.  SM 17.1 conventional to 17.1 AA restore

    Posted 06-05-2018 10:48 PM

    Hi Experts,


    I have conventional 17.1 setup on one box and having primary and DB on same box, we want to move all customization to newly created 17.1 AA setup having background, standby , application and DB servers on different boxes.


    How i can restore all existing customization of conventional architecture to AA, please guide and provide documentation link if available.




  • 2.  Re: SM 17.1 conventional to 17.1 AA restore

    Posted 06-06-2018 02:03 AM

    Hello Rita,


    It helps to think of this as two items that need to be done.


    1) Move your SDM installation from one environment to another.


    Search for "Swing Box" on CA Communities, and look into this DocOps page specifically:

    Use the Swing Box Method to Upgrade to CA SDM 17.1 - CA Service Management - 17.1 - CA Technologies Documentation 


    2) Change from Conventional to Advanced Availability configuration.

    See DocOps here:

    Changing the Server Configuration from Conventional to Advanced Availability - CA Service Management - 17.1 - CA Technol… 


    If you take it methodically, you should be fine. There are a lot of steps - not kidding around there.

    But keeping the big picture goal in mind helps. (1) Move environments. (2) Reconfigure environment. Under no circumstances try to combine those two steps into one - too many moving parts.


    Specifically, your customisations are stored in two locations - files under site/mods, and extra tables and columns in the database. The Swing Box methodology will handle that move. Remember, you only need to move the SDM Primary server, because the secondary servers will no longer be used. (Assuming that you are using new boxes for the new AA environment. Otherwise, you can reuse them as additional App. servers in Step 2 after cleaning them up.)


    Then changing from Conventional to Advanced Availability allows you to expand the number of servers (BG, SS and extra App servers) at that stage.


    Thanks, Kyle_R.

  • 3.  Re: SM 17.1 conventional to 17.1 AA restore

    Posted 06-06-2018 03:50 AM

    Thanks Kyle_R,

    But i have still doubt because i am not much aware about AA configuration.

    1. as of now we have clean setup of AA which include BS,SS, AS and DB (17.1) on different systems.

    2. On another server we were having DB and Primary server of SD 12.9, which is now upgraded to 17.1 conventional.


    so my question is that,

    1. After promoting to conventional to background server, how i can restore AA background server to newly created AA background server, does it require swing box methodology only?

    2. and after restore of background server on newly created background server, i have to add all standby and app server once again through web console and run configuration on each server once again , is that understanding correct ?


    please help.




  • 4.  Re: SM 17.1 conventional to 17.1 AA restore

    Posted 06-06-2018 08:19 PM

    Hi Rita,


    You're a few steps ahead of where I would start, as you have got your 17.1 populated conventional setup on one set of servers, and the 17.1 blank AA on another set of servers.


    Whereas I probably would have split it out as above ("(1) Move environments. (2) Reconfigure environment. Under no circumstances try to combine those two steps into one"):


    1) Swing box the 17.1 populated convention setup over to the 17.1 new environment, keeping it as a conventional setup.

    2) Then once on the new hardware, switch it from conventional to AA.


    So you've got a choice at this point.


    A) Back out the new environment, and continue as above. 

    Not such a bad option. You'd just need to revert your new blank AA environment back to a conventional setup for a period.


    B) Look at what you need to do to do to swing box AND convert a from conventional to AA.

    This is possible, but you'll need to do your own sanity tests on this, as we don't document this particular scenario.


    But you would cover these steps:


    * Copy the database

    * Apply patches/options

    * Copy the customisation files

    * Copy the Attachments to their new Repository, and anything else which is file based not included in prior steps

    * Run configuration to convert to AA

    * Add on additional servers as needed


    But this needs more thinking about. Definitely possible, and some sites may be able to advise here what they think of doing this.


    It's not a horrible option, per se. If you do your testing, and run it through on a trial environment, I'm sure that it's not as bad as I may be worried about.


    And it's potentially a better option, once you understand the process and have a solid run sheet. Why? Because it means you skip some genuinely unnecessary steps in the whole process.


    Why is it not my preferred choice? Simply because both the "Swing Box" and the "Convert Conventional to AA" are two separate, well understood, well tested operations. They've each been run countless times by sites, and the kinks are mostly worked out, or known about.


    But if you mash the swing box and the conversion into one routine, the onus is much more heavily on you to make sure that you test thoroughly this process, and have a solid run sheet for when you do it live.


    Oh, and backups are your friend. If you have the opportunity to do this on virtual machines and take snapshots, it will make your testing a lot easier. And reversion from a failure is a 60 second event, rather than a two day panic.



    Anyone care to chip in with advice?
    Has anyone done a similar change?


    Thanks, Kyle_R.