Thursday, March 28, 2013

Multi-Step Upgrade: DRS Tip

I am in the process of doing a multi-step upgrade from 6.1 to 8.6 and I figured that while my DRS restore was chugging along I'd take a quick moment to post a tip to the ol' blog. On this particular project we are pulling a DRS backup from the production system and taking it off site to one of our labs. From there, I am doing a restore to a MCS host I have in the lab and stepping the UCM publisher through the upgrade process. 

There is a teeny weeny hurdle you could run into during this process. Particularly when you are creating a DRS backup device to take the newly upgrade image back to the production environment. 

If you are doing something like what I describe above and are seeing an error message on the DRS Backup Device page that says something like <spicolivoice> "Duuude, I'd like to help ya out brah but the Local Agent has bailed on us...." </spicolivoice> then I may have the fix you need.
Background

So, the process I am following (at a very high level) to get from 6.1(3) to 8.6(2) is as follows:


  • DRS Backup from 6.1(3) system
  • DRS Restore on one of my lab MCS systems
  • Upgrade lab MCS system to 7.1(3)
  • DRS Backup 7.1(3)
  • DRS Restore on UCS VM image
  • Upgrade to 8.6(2)
  • DRS Backup 8.6(2)
  • Do a restore on staged Publisher for production
As a side bar, I am using the MCS server vs. going right to a 6.1(3) VM because our testing has shown that upgrades to 6.1(3) take much longer in VM than on MCS. We have found that upgrades to 7.1(3) perform about the same in VM vs. MCS. Why I am moving the DRS to VM post 7.1(3) is because my MCS server is a tad old and doesn't meet the memory specs. So, in my particular lab, moving the 7.1(3) to VM and doing the upgrade is a better proposition.

The Issue

When you do a DRS restore you are restoring more than just the Informix DB. You are also restoring things like the certificate store. In my testing I have found that this will create some minor annoyances for the would-be-upgrader. Specifically, you could see the following error message when creating or modifying the DRS backup device:  "Local Agent is not responding. This may be due to  Master or Local Agent being down." (no Spicoli this time)

When would you see this message? Well, I have seen it in one of two instances:


  1. During DRS Restore if the UCM host you are restoring to already had a previous Restore applied. In my case, I had done a dry run of the upgrade process (I am a boy scout that way) and I rolled back to the 6.1(3) (pre-7.1 upgrade) image. Which was previously restored from production. 
  2. During DRS Backup after you have restored and upgraded UCM. This is true whether you have reached your final version destination OR (as in my case) you are doing an interim hop and move the DRS to another system to complete the upgrade.


The Fix

The fix to this issue is actually quite simple. Just do the following:

Step 1.  Go to the OS admin portal on your CUCM node (https://PublisherNodeIP/cmplatform)

Step 2. Navigate to Security>Certificate Management and click "Find" to show all certificates.



Step 3. Click on the "ipsec_cert.pem" certificate to view the cert.

Step 4.  Click "Regenerate".


Step 5.  Repeat Steps 3 and 4 for the "tomcat_cert.pem" certificate.


Now, you can go back to DRS and add (or edit) the Backup Device. Restore and Backup and will.


Thanks for reading. If you have time, post a comment!

7 comments:

  1. Great tips as always! Do you also DRS restore the subscribers, or just install them from scratch and get the publisher to replicate the data?

    ReplyDelete
    Replies
    1. Thanks for the feedback. I prefer to Install the subscribers from scratch and replicate from the publisher.

      - Bill (@ucguerrilla)

      Delete
    2. Hi Bill,

      If let say i want to install subscriber from scratch, but unfortunately i don't have the security password to join the publisher. what should i do? can we retrieve the security password from the pub?

      Delete
    3. Marzuki,

      That is a tough one. If you don't have the cluster password phrase then you are usually stuck. I have seen a process someone put on Cisco Support Community that talks about how you can get to the hashed password and recover the security password. The process posted was incomplete and it looked like it would require you to boot into recovery mode and get into the underlying file system (i.e. you can't do it without special access).

      I haven't tried this out myself yet and I hope to not find myself in that position. That said, if there is a method to recover the password then it is logical to assume that Cisco Tac has a method to do this. So, I would contact Tac.

      HTH.

      -Bill

      PS: sorry for the delay, your comment landed in my spam filter for some reason.



      Delete
  2. Hi William, i'm on upgrading and migrate current system from 6.1.1.3000-2 inside MCS7825H3 to 8.6.2 to MCS7835-I3
    I check on the compatibility, my new server can support to install 6.1.5.
    So i have another spare MCS7825H3 to use and install same version 6.1.1.3000-2
    - From there, i DRS restore from current system
    - I upgraded to 6.1.5 and DRS backup then
    - On new server i install 6.1.5 and DRS restore and continue path upgrade till 8.6.2

    As i understand once i DRS restore at first stage into another MCS7825H3, am i able to upgrade to 6.1.5 ... will the license grace period applied to not allow me to upgrade?

    ReplyDelete
    Replies
    1. Marzuki,

      From a licensing perspective, you should be fine.

      -Bill (@ucguerrilla)

      Delete