cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
331
Views
0
Helpful
2
Replies

CUCM 11.0(1A) upgrade timing question

Hi All

We/I are planning to upgrade our CUCM from 11.0(1A)SU1 to 11.5(1)SU2 to address notified security vulnerabilities and system limitations/bug fixes.The latest device pack and IP telephone  firmware (9-4-2SR3-1S) has already been sucessfully applied.

I plan to undertake the work over a weekend and the pre-upgrade checks indicate the cluster is in pretty good shape. With reference to http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/upgrade/11_5_1/cucm_b_upgrade-guide-cucm-115/cucm_b_upgrade-guide-cucm-115_chapter_010010.html#reference_2632FB7CCFD4452475D8DBD73069E128 table 9, I see that the estimated minimum time to upgrade is stated as between a hefty 12- 15 hours. I plan to adopt the OS Admin approach and sequence that causes least end user impact over least installation time.

I have a theory that it should be possible to mitigate the time taken on the day by installing the software on all inactive partitions the evening before and then switching partitions the following morning. Obviously the main impact will be that when I do  switch over, any changes to the configuration of the cluster (EM status changes, PIN changes etc) between the time I install the software and the time I restart from the inactive partitions will be lost. Given that the number of changes that happen overnight will be minimal, I don’t see this as a big issue. I'm guessing Unity Connection would be the exception to minimise the loss of voice mails?

Does anyone have any views or advise as to why I shoiln't adopt this approach? We have circa 3500 users, the platform is two BE7000M (UCS 240C) 1 Publisher, 3 Subscribers, 1 TFTP, 2 IM&P and 2 Unity Connection servers.

Any advice is geatly appreciated.

Thanks in advance

Rich

1 Accepted Solution

Accepted Solutions

Hi,

I followed the same approach when I upgraded to version 11.5 which worked pretty well. Unfortunately my upgrade didn't go straight forward as I hit this bug.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux78390/?reffering_site=dumpcr

Although the targeted version says 10.5, this wasn't accurate as I was running 9.1(2) and the TAC engineer told me that he say this will 11.0 as well. The only resolution is to contact TAC for them to login to the root and clear the files manually. This was targeting the publisher. 

Other than that, once thing which I didn't see in the checklist and need to be done is changing the VM settings to match the requirement for 11.5 such as NIC type (from E1000 to VMXNET) etc. Here is the link

http://www.cisco.com/web/software/283088407/133457/cucm.ova.README_11.5_Rev2.pdf

View solution in original post

2 Replies 2

Hi,

I followed the same approach when I upgraded to version 11.5 which worked pretty well. Unfortunately my upgrade didn't go straight forward as I hit this bug.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux78390/?reffering_site=dumpcr

Although the targeted version says 10.5, this wasn't accurate as I was running 9.1(2) and the TAC engineer told me that he say this will 11.0 as well. The only resolution is to contact TAC for them to login to the root and clear the files manually. This was targeting the publisher. 

Other than that, once thing which I didn't see in the checklist and need to be done is changing the VM settings to match the requirement for 11.5 such as NIC type (from E1000 to VMXNET) etc. Here is the link

http://www.cisco.com/web/software/283088407/133457/cucm.ova.README_11.5_Rev2.pdf

Hi Mohammed

Thanks very much for the response and for the pointers to potential issues that we may encounter.

I'd missed the steps outlined in http://www.cisco.com/web/software/283088407/133457/cucm.ova.README_11.5_Rev2.pdf  but having gone through it now, the NICs are already set as VMXNET and the VMWare version set as 8, so one less thing to worry about.

Thanks once again, your response is very much appreciated.

Best

Rich