cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
408
Views
4
Helpful
5
Replies

CUCM 11.5.1 SU11 to 14 - Question about upgrade > Switch later

voip7372
Level 4
Level 4

We're on version 11.5.1.23900-30 right now and I'm all ready to upgrade to version 14 SU3. I have VMware updated to a supported release on all the UCS servers and also updated the specs on the virtual machines related to all the servers I'm upgrading (vRAM, CPU, OS type, etc). I also took the opportunity to update CIMC on all the UCS servers.

Since I normally upgrade CUCM and switch to the new version immediately after the upgrade I'm not as familiar with the 'upgrade and switch later' method. It sounds straight forward, but I just wanted to make sure there's no caveats I'm missing. What I'd LIKE to do is upgrade the publisher this week, then all the subscribers (maybe a couple a day, just to manage my time) but NOT switch to the new version immediately. I'd like to upgrade all of them so they are ready to be switched to the new version on the weekend. Does anyone see any issue with this plan?...upgrade but not switch and then several days later, switch to the new version. No issues with that? 

1 Accepted Solution

Accepted Solutions

From a technical standpoint there is nothing that would stop you from doing what you outlined. However you should be aware of that it’s not just administrative changes that would be necessary to keep track of, it’s also any user facing change, like call forwards done from a hard or software phone. With this it’s my personal opinion based on experience it’s a bad idea to do what you plan. Just my 2 cents, it’s up to you if you think it’s a manageable risk.



Response Signature


View solution in original post

5 Replies 5

The biggest problem with this is that you’ll loose all the data, like configuration changes, from the time you’ll initiate the upgrade to the time you complete the switch version. I don’t recommend you to use this approach.



Response Signature


Good point. Although we don't have a lot of changes happening lately. Most of them are just people leaving the company due to a package the company offered to older employees 61 and over (and most of our people are using Teams for calls these days, but those do pass through CUCM on the way t/from the PSTN since it's a Direct Routing/SBC setup with Teams, not Microsoft's calling plans). Let's say I keep track of any changes (shouldn't be many) and I start this two days before the weekend to limit the number of changes I'd have to keep track of (my guess would be less than 30 and they're simple changes)....other than that, is there any technical reason why I couldn't upgrade the Pub, then a Sub and then a few more Subs and if I'm not done before Saturday comes, I go ahead and finish the remaining Sub servers and then go ahead with the switch (Publisher first of course)?

 

From a technical standpoint there is nothing that would stop you from doing what you outlined. However you should be aware of that it’s not just administrative changes that would be necessary to keep track of, it’s also any user facing change, like call forwards done from a hard or software phone. With this it’s my personal opinion based on experience it’s a bad idea to do what you plan. Just my 2 cents, it’s up to you if you think it’s a manageable risk.



Response Signature


Hi,

Technically you could do it ( I had a couple of same situation in the past) but as @Roger Kallberg  mentioned you have to pay attention to configuration changes and files added such as background images ringtones or dedicated phones firmware. Also.. as the upgrade process freezes the cluster situation , you also have to consider services such as Extension Mobility or Mobile remote access with Oauth tokens that will be restored to the date you started the upgrade and you could find Eg. logged in phones with wrong EM profiles or revoked tokens become valid again.

Thanks 

 

Regards

 

Carlo

Please rate all helpful posts "The more you help the more you learn"

Thanks. Good points also and something to keep in mind.  

I should share a bit more info though, just so people are aware of the situation with this particular cluster. We have 15 or so clusters around the world and some of those regions have more physical phones than others. Some regions have more people in the office than others tend to have. This cluster I'm dealing with is one of two in the US and things have changed quite a bit ever since the 'lockdowns' a few years ago. More and more, our clusters are becoming more of a call routing hub than a set of servers the devices for people and room devices register to. Some of them have always been heavy on the call routing, especially the ones that route calls to Teams and our inContact call center. Out of a little over 3,000 numbers in use on this cluster, there are only 370 physical phones and of those, 206 are common area phones like conference rooms, 54  out of the 370 are unregistered for various reasons (office remodels, etc) and just 110 actually registered and with a person's name assigned to it. Out of those 110, I would bet most of them rarely come to the office anymore. Everyone that has a phone has a remote dest profile with a remote destination setup to ring MS Teams simultaneously. Hardly anyone would have access to actually make changes to their phone, like changing forwarding or speed dials. We have Extension Mobility enabled, but only a handful used it in the past (those people no longer have phones). We don't have Expressway anymore, so no devices are registered offsite. These are all in-office phones I'm talking about. We only have a few special cases using IP Communicator and we've already decommissioned Jabber (like I said, MS Teams is the primary telephony tool for our users now (especially in the US), so there's just not much user activity on CUCM related to anything a user could possibly change. We had CMS (Cisco Meeting Server - video conf), but that was also decommissioned in favor or Teams/Microsoft Teams Room devices in conf rooms. Most of any type of changes made on CUCM are only made by us, the admins...things like adding a new CTI Port for a new user that's permanently forwarded to Teams or removing something like that for a terminated employee.

So, with that being said, maybe you can see why I'm not too concerned about losing any changes people make because hardly anyone has the ability to change anything (speed dials, forwarding, etc) and of the small amount of physical phones left, most people would never forward their number because they have a remote dest profile that's already ringing their Teams client.

Thanks for the advice and notes about those things I didn't think of. Mostly I just wanted to be sure there was no technical reason why I couldn't upgrade and then switch a few days later (just to make my weekend work shorter and leave more weekend time to troubleshoot problems, if I find any).  So, if I'm understanding correctly, there's no technical reason why I couldn't do it this was, but yes...I'd have to keep in mind the things you mentioned which could happen in a few cases, but I think those would be rare cases, given how we use our cluster and with how few people/users have access to actually change something on their end.