CUCM uprade to 8.6.2

[miket]

I have a CUCM cluster that is running 6.1.4, I need to upgrade on new hardware. The bridged upgrade asks you to upgarde all nodes, the do a DRS on the pub , once pub is done you can DRS the subscribers.  IThe customer will not let me upgrade the existing hardware so I need to restore the 6.1.4 on new hardware, I was hoping to only have to DRS the 6.1.4 pub, restore on new hardware and then do upgrade. after upgrade is complete on 8.6.2 , I would add the sub onto the hardware.

Do I have to DRS all servers onto new hardware at 6.1.4 then upgrade all servers to 8.6.2 or anybody any other ideas. 

Yes I do have the COP file on the 6.1.4  

[Jonathan Schulenberg]

A DRS backup pulls files from each node in the cluster. Your backup will fail if any of the nodes are offline. Sorry.

Please remember to rate helpful responses and identify helpful or correct answers.

[chrysostomos1980 · Accepted solution]

Hi Mike

Note:

In order the backup to complete succesfully then PUB ans SUB must be online.Take a backup (DRS will backup both) but restore to the new hardware only the pub.I assume that you have TWO new hardwares

1) Take a backup from the existing cluster

2) install in the new server(must be out of the current network but you have to install the same as the current cucm,Ip,hostname,etc) cucm version 6.1.4(same as the online cucm)

3) Restore ONLY the Pub from the DRS,Perform your upgrade to 8.6.2 (check the doc for the correct upgrade path)

4) Once you done then install the new SUB into the new hardware with the new version (8.6.2) same with the new PUB

5) Then PUB will replicate the database to the SUB.

6) check that the replication is good with  utils dbreplication runtimestate.must be something  like that

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING

Cluster Replication State: Only available on the PUB

DB Version: ccm7_1_5_31900_3

Number of replicated tables: 427

Cluster Detailed View from SUB (2 Servers):

                                PING            REPLICATION     REPL.   DBver&  REPL.   REPLICATION SETUP

SERVER-NAME     IP ADDRESS      (msec)  RPC?    STATUS          QUEUE   TABLES  LOOP?   (RTMT)

-----------     ------------    ------  ----    -----------     -----   ------- -----   -----------------

ccm1    192.168.1.242   0.462   Yes     Connected       0       match   N/A     (2)

cmprimary       192.168.1.241   0.070   Yes     Connected       0       match   N/A     (2)

7) Create a maintenance window and put out the old cluster and put the new cluster online

8) Done and happy

Regards

chrysostomos

[Jonathan Schulenberg]

4) Once you done then install the new SUB into the new hardware with the new version (8.6.2) same with the new PUB
5) Then PUB will replicate the database to the SUB.

The step missing here is a DRS restore on the subscriber which you can't do because the subscriber was not present when you took a DRS backup of the 8.6.2 version on MCS hardware. Without this step you have added a new subscriber to the cluster. So, if you had a PUB and a SUB before, now the cluster thinks you have a PUB, SUB (now missing/down), and a new SUB. You'll get errors that there is a node down among other things.

Please remember to rate helpful responses and identify helpful or correct answers.

[chrysostomos1980]

Hi Jonathan

I dont believe that its need it a drs restore for the sub

If he create a new PUB (and restore from the backup) then he can proceed with the installation of the new sub with the same ip , etc of the old

So he will proceed with what i mentioned

i missed something?>Its not need it the drs backup for 8.6.2 until he create the new sub into 8.6.2 version

Regards

cc

[Jonathan Schulenberg]

There is a lot of magic behind the curtain, both in how Cisco has abstracted all GNU/Linux administration (read: lots of automation and shell scripts) and several of the Cisco processes that run on the platform. The restore procedure for either an entire cluster or a subscriber node is clearly documented and the process should not be ignored.

From the Disaster Recovery System Administration Guide for Release 8.6(1):

Restoring subscribers in a cluster is important, as many components (for example, SERVM and TCT) do not get configuration data from the database.

[Jeremy Combs]

I parrot what Jonathan states.  It is imperative to follow the Cisco documentation for backup and restoration of a CUCM environment even for a bridged upgrade.  While yes you can get away with (on the back end) just restoring the CUCM Publisher when you rebuild the Subscriber and elect to build Subscriber nodes and not restore from DRS backup ,the consequence is all of the custom TFTP files (custom firmware loads, Jabber config files, ring tones, etc.), Service Parameter settings, etc. are not restored.  Not to mention the ever important certificates for TVS.  If you don't do a restore of the Subscriber from DRS backup your phones will not register to the Publisher because the certificates will be different than what is in their trust list.  Nothing like learning this the hard way and electing to not restore the Subscriber nodes from DRS and having thoursands of phones not register.

[miket]

CC I agree with everything you are saying. Customer wont let upgrade on existing hardware so that brings up this whole issue I will do in isolated lan. I know the TLS is not and Issue unless phone loads are on 9. We just broke a 25,000 seat cluster into three from 5.1 onto 8.6 and all new IP's and Hostnames difference here was we exported and imported data as well as modified extensions and we tested with ip phone loads at 9 and at 8.5 and long as we were below 9 TLS and all security on phones did not matter. If you do it on ip phone firmware 9 then you need to go into each phone and delete the security which on the 25000 phones would have been a mess unless you purchase a third party software to delete the stuff all at once but thats another conversation that has many posts as well. I also have done a few upgrades on new hardware and IP addresses and some change hostname and when you do the restore teh DRS pops a warning stating that you are not restoring same hostname and IP and do you want to change it.. I have seen this several times on 8.5 will check on 8.6 for me I am using same ip's etc I just need to but the 6.1.4 on new hardware.

I do know that docs are there for a resason but sometimes are overkill.  I have been doing this since 2000 and windows platforms seemed to be easier to backup and restore in some ways (can't believe I said that) but it is true and since all the security into CUCM it is that much harder..

Thanks for all the replies

Thansk for replies

[miket]

I have also done a DRS to a cluster using 8 and I didnt restore subscriber only pub. Same DRS warned me of changing IP and name and once resore completed database was fine no phone issues everything was perfect Once pub was done I started services, went into PUB, changed IP of subscriber and then did fresh install of sub and it sync'd right up no issues.  Just haven't seen too many 8.6 upgrades on new hardware.  Doing exports and imports  works when you are an excel guru.

It does work but if you never done it try it in a lab.. Build a cluster DRS restore on new ip and see it does work on code up to 8.5 just haven't done with 8.6 but I agree docs are bibles and outside them is a chance.

The problem lies when you have tough customers short windows sometimes you need shortcuts right or wrong

[chrysostomos1980]

Hi  Mike

Thank you for the nice rating

Regards

cc

[miket]

Mistake DRS has to be restored with same name and IP , DMA asks if you want to update.. Oh my brain going to mush;'

You are welcome for rating deserved

[Brian Houston]

Hi Mike

Did you put your method to the test and if so, was it successful?

I ask because I've opened a discussion of my own along the same lines and have seem some different opinions expressed - one from Jonathan as per your discussion. I'm planning an upgrade using the same method you've described. My scenario is upgrading an 8 node MCS cluster running UCM 6.x to a 7 node UCS cluster running 8.6.2. My plan is as follows:

Using spare lab MCS server, build Publisher with identical 6.x version as production MCS servers.

Take DRS backup of production 6.x Publisher.

Perform DRS restore (Publisher only) onto lab 6.x MCS server

Upgrade lab MCS to 8.6.2

Take DRS of lab MCS 8.6.2

Perform DRS restore to new UCS Publisher running 8.6.2

Add new subscribers to new UCS Publisher.

Install licenses.

I appreciate what Jonathan and others have stated with regards to following the DRS documentation to the letter but Cisco documentation does not always fit in with what customers want.

For me to follow Cisco guidelines exactly, I'll have to perform an upgrade from 6.x to 7.x then a bridged upgrade from 7.x to 8.6.2, both upgrades taking place on live servers serving 8500 users.

If you have any feedback from trying out your method, I'd be glad to hear it.

Regards

Brian

[miket]

Brian, sorry for delay. The whole thing got delayed. I will be doing in Jan if you still want to know.

My last upgrdae from 4.1 to 8.6  what I did was got DMA from 4.1. I built a 7.1 restored DMA.. NO subscribers built.

Then from 7.1 I went to 8.6 , once 8.6 was up I did a bu and restored on a UCS 210.

I did not have coplete cluster up when I did backup and al was fine. I built the subscribers after the restore was done.

Hope this helps

[Ayodeji Okanlawon]

Mike and all...

Just to add my 2 cents to this. One thing I have done in the past is to delete the subscriber after restoring the publisher. This way I have a publisher only without any subscriber in its database. Then once the publihser is fully installed, I then add the subscriber back to it.

I must say that I have also in the past done a restore/install as you guys have mentioned without the subscriber been restored. In hind sight now, I am not sure how this worked and is working because as Jonathan pointed out, The publisher already contain the subscriber in its database which was not restored and then it is added as a new subscriber. I have done this also a few times and it has worked.

I think a cleaner install will be to delete the subscriber from the publisher database before re-installing the subscriber into the cluster

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Jeremy Combs]

That is a bad idea. When you do that you are adding CTI Node IDs. Original Pub is Node 1, Sub 1 is Node 2, Sub 3 is Node 3, etc. When you delete Sub 1 and Sub 2 and re-add them the new entries will be Nodes 4 & 5. Not a good idea.

Sent from Cisco Technical Support iPhone App