Re: [cisco-voip] UC Apps on Unsupported ESXi Versions
Thanks for the reply Ryan, I value your input. On the topic of the UC App, UCCX or otherwise, being able to detect your version of ESXi: do you think that happens, or is the check more shallow and just looking for VMWare under the hood? On Mon, Nov 3, 2014 at 3:42 PM, Ryan Ratliff (rratliff) rratl...@cisco.com wrote: UCCX tends to be a few releases behind UCM in the OS that they run on so it's likely the vNIC issue UCM hit just hasn't affected UCCX (yet). On the pre vs post upgrade, it's just how the teams tested it and decided to write it up. IMO as long as the changes are done before going back into production that's all that matters. The benefit to doing them pre is that a reboot will give the VM a chance to upgrade vmtools automatically. -Ryan On Nov 3, 2014, at 2:23 PM, Anthony Holloway avholloway+cisco-v...@gmail.com wrote: Thanks Brian. That's exactly the kind of information I'm after. I'm hoping someone can validate it with empirical evidence. It worth mentioning the following, which I replied to another list user who direct messaged me, in regards to OVA settings during the upgrade. According to the CUCM and CUC upgrade guides, you can change the OS before or after the upgrade. Se the CUCM guide here where it states OS changes are a pre-upgrade task: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/upgrade/10_0_1/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100_chapter_011.html#CUCM_TK_C9AFC8CC_00 And here in the CUC guide where it's a post upgrade task: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/upgrade/guide/10xcucrugx/10xcucrug010.html#pgfId-1145799 Interestingly enough, UCCX documentation has no mention of changing OS or Network Adapter. Not in the Upgrade Guide, Release Notes, nor the OVA Read Me. I have opened a request to have this reviewed, it might be a miss or it might be the way it is. Upgrade Guide http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_5/install/guide/UCCX_BK_C2650101_00_cisco-unified-contact-center-express.html Release Notes http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_5/release/docs/UCCX_BK_UBDB029E_00_uccx-release-notes-105.html http://www.cisco.com/web/software/280840578/117186/UCCX_RN_10.5su1.pdf OVA Read Me http://www.cisco.com/web/software/283733053/114894/UCCX_v2.6_vmv8.ova_README.txt On Mon, Nov 3, 2014 at 12:54 PM, Brian Meade bmead...@vt.edu wrote: I just got through updating our internal UCCX to 9.0.2(SU2) to get ESXi 5.5 support prior to migrating to our 5.5 infrastructure. I'm not sure if anything really changed to support 5.5 though outside of the BU just finally testing it. On Mon, Nov 3, 2014 at 12:25 PM, Anthony Holloway avholloway+cisco-v...@gmail.com wrote: All, I'm planning an upgrade to UCCX 8.5(1)SU3 to 10.5(1)SU1 by way of 8.5(1)SU4. My ESXi is on 4.1 and I am planning to upgrade it to 5.5. The virtualization guide does not list ESXi 5.5 as supported for UCCX 8x. http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CCX#Version_8.5.28x.29 And, the virtualization guide also does not list ESXi 4.1 as supported for UCCX 10x. http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CCX#Version_10.5.28x.29 I am wondering if anyone has experience with this and if it really matters what order I do the upgrades in, considering that at the end of the maintenance window, I will be on UCCX 10.5(1)SU1 and ESXi 5.5; which is supported. My biggest concern is with the UCCX upgrade to 8.5(1)SU4 halting because of a hardware/software compatibility check while on ESXi 5.5, or likewise, UCCX 10.5(1)SU1 halting because of ESXi 4.1. This is also why the subject of this email says UC Apps and not UCCX. I would suspect all UC Apps (VOS based ones anyway) upgrade in the same manner, when it comes to hardware/software checks. Actually, do UC Apps even check your version of ESXi? Or do they just see VMware and the hardware resources allocated? Thank you. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] UC Apps on Unsupported ESXi Versions
The check is done by the vmtools at boot and if the version on the guest is mismatched with the one the host tells it to run it will get updated. The UC app doesn't check (to my knowledge) the hypervisor version. -Ryan On Nov 4, 2014, at 10:33 AM, Anthony Holloway avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote: Thanks for the reply Ryan, I value your input. On the topic of the UC App, UCCX or otherwise, being able to detect your version of ESXi: do you think that happens, or is the check more shallow and just looking for VMWare under the hood? On Mon, Nov 3, 2014 at 3:42 PM, Ryan Ratliff (rratliff) rratl...@cisco.commailto:rratl...@cisco.com wrote: UCCX tends to be a few releases behind UCM in the OS that they run on so it's likely the vNIC issue UCM hit just hasn't affected UCCX (yet). On the pre vs post upgrade, it's just how the teams tested it and decided to write it up. IMO as long as the changes are done before going back into production that's all that matters. The benefit to doing them pre is that a reboot will give the VM a chance to upgrade vmtools automatically. -Ryan On Nov 3, 2014, at 2:23 PM, Anthony Holloway avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote: Thanks Brian. That's exactly the kind of information I'm after. I'm hoping someone can validate it with empirical evidence. It worth mentioning the following, which I replied to another list user who direct messaged me, in regards to OVA settings during the upgrade. According to the CUCM and CUC upgrade guides, you can change the OS before or after the upgrade. Se the CUCM guide here where it states OS changes are a pre-upgrade task: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/upgrade/10_0_1/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100_chapter_011.html#CUCM_TK_C9AFC8CC_00 And here in the CUC guide where it's a post upgrade task: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/upgrade/guide/10xcucrugx/10xcucrug010.html#pgfId-1145799 Interestingly enough, UCCX documentation has no mention of changing OS or Network Adapter. Not in the Upgrade Guide, Release Notes, nor the OVA Read Me. I have opened a request to have this reviewed, it might be a miss or it might be the way it is. Upgrade Guide http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_5/install/guide/UCCX_BK_C2650101_00_cisco-unified-contact-center-express.html Release Notes http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_5/release/docs/UCCX_BK_UBDB029E_00_uccx-release-notes-105.html http://www.cisco.com/web/software/280840578/117186/UCCX_RN_10.5su1.pdf OVA Read Me http://www.cisco.com/web/software/283733053/114894/UCCX_v2.6_vmv8.ova_README.txt On Mon, Nov 3, 2014 at 12:54 PM, Brian Meade bmead...@vt.edumailto:bmead...@vt.edu wrote: I just got through updating our internal UCCX to 9.0.2(SU2) to get ESXi 5.5 support prior to migrating to our 5.5 infrastructure. I'm not sure if anything really changed to support 5.5 though outside of the BU just finally testing it. On Mon, Nov 3, 2014 at 12:25 PM, Anthony Holloway avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote: All, I'm planning an upgrade to UCCX 8.5(1)SU3 to 10.5(1)SU1 by way of 8.5(1)SU4. My ESXi is on 4.1 and I am planning to upgrade it to 5.5. The virtualization guide does not list ESXi 5.5 as supported for UCCX 8x. http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CCX#Version_8.5.28x.29 And, the virtualization guide also does not list ESXi 4.1 as supported for UCCX 10x. http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CCX#Version_10.5.28x.29 I am wondering if anyone has experience with this and if it really matters what order I do the upgrades in, considering that at the end of the maintenance window, I will be on UCCX 10.5(1)SU1 and ESXi 5.5; which is supported. My biggest concern is with the UCCX upgrade to 8.5(1)SU4 halting because of a hardware/software compatibility check while on ESXi 5.5, or likewise, UCCX 10.5(1)SU1 halting because of ESXi 4.1. This is also why the subject of this email says UC Apps and not UCCX. I would suspect all UC Apps (VOS based ones anyway) upgrade in the same manner, when it comes to hardware/software checks. Actually, do UC Apps even check your version of ESXi? Or do they just see VMware and the hardware resources allocated? Thank you. ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip
[cisco-voip] PCD CUCM Migration Upgrades with UCCX
Anyone have any thoughts on using PCD to upgrade CUCM in environments with UCCX ? Assuming customer is running v8 CUCM UCCX on MCS hardware and wants to upgrade to 10.5. PCD can take CUCM from v8 MCS direct to ESXi and 10.5. But, UCCX isn't supported for PCD migrations. CUCM 10.5 isn't supported with UCCX v8 and likewise, UCCX 10.5 isn't supported with CUCM v8. So I was thinking of using the process below: Maintenance Window 1 1) Virtualize UCCX v8 on ESXi Maintenance Window 2 1) Install RU upgrade on UCCX to 10.5 on inactive partitions 2) PCD Upgrade/Migration CUCM to 10.5 (same IP/hostnames) 3) Once CUCM is complete, initiate switch-version on UCCX to 10.5. Does anyone see any issues with temporarily having CUCM at 10.5 before the switch-version begins on UCCX?Does UCCX check the switch-version to see if the CUCM is compatible? I haven't found this documented anywhere yet, so I've stayed away from PCD for the time being but curious if anyone has found a good way to handle PCD in environments with UCCX. Justin ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM 8.6 promotion of new pub
Hi Charles, I'm not promoting a sub into pub, rather moving phones to the other cluster. If you meant segregated planned controlled outages, then that can't be done as ALL phones take a hit by cert combination regardless of which sub they are registered to. My only ask was to see if that reset could be prohibited so phones could be manually reset in a controlled and clean manner. Comparing this with firmware upgrade, the process itself doesn't initiate a reset to 'ALL ones in one shot so you have control over how you want to bulk that activity, either server level or DP level etc. Thanks, TG On Nov 3, 2014 10:53 PM, Charles Goldsmith wo...@justfamily.org mailto:wo...@justfamily.org wrote: TG, you state that you aren't trying to promote a sub, but your subject line indicates that you are. When talking about combining certs and TVS restarts, thats for a migration, moving phones from one cluster to another. This is not a way to promote a sub to a pub, which you cannot do. If you are upgrading while rebuilding a new cluster, that is one thing, but we don't do this often, and most customers do not ever do this. What I mean by this is if you are building a fresh, new cluster with the latest version and then moving phones to this new setup. Rebuilding to resolve dial plan best practices or splitting a company are the only reasons I've seen the need of a migration, but perhaps moving a group of phones from one cluster to another in a very large deployment could be a practical use of it. Pushing new certs down (by combining them) is going to cause some restarts of phones, plan for that with your outages. It's really no different than planned outages around upgrading firmware in prep for a software upgrade, which causes another round of resets as they re-register with subs. Good luck and ask your questions, but please clarify your plan and intents. On Mon, Nov 3, 2014 at 5:53 PM, TG techguy...@gmail.com mailto:techguy...@gmail.com wrote: Brian, Thanks for your input. It's unfortunate we have to live with it. Need to know the significance and purpose of TVS restart on subs, as results are seen without doing it as well. Also does that cause another reset on the phones? Ryan, Maybe you misunderstood it, it is about bulk cert, and not pub recovery. Do you know of a way to stop phones from resetting just by combining the cert? We see this being fixed in 9.5 but not everyone is willing to jump to 9.5 for this gap. Cisco should consider addressing this on 8.6 and 9.1 as well as many customers are using these releases. If your 30k phones have to take a hit because of cert combining, then that's a big drawback to this whole procedure of cluster replacements. Thanks, TG On 2014-11-03 4:39 PM, Ryan Ratliff (rratliff) wrote: I'm not aware of the specifics of the doc bug Brian referenced but the original question sounds less like bulk cert import and more like a publisher recovery. Can you provide a bit more details on what you mean by promote a new publisher to existing phones? -Ryan ___ cisco-voip mailing list cisco-voip@puck.nether.net mailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM 8.6 promotion of new pub
Still trying to look into this some more but it's worth noting that phones are restarted (simply a re-registration), not reset. This process should be extremely fast and most users won't even notice. -Ryan On Nov 4, 2014, at 12:34 PM, TG techguy...@gmail.commailto:techguy...@gmail.com wrote: Hi Charles, I'm not promoting a sub into pub, rather moving phones to the other cluster. If you meant segregated planned controlled outages, then that can't be done as ALL phones take a hit by cert combination regardless of which sub they are registered to. My only ask was to see if that reset could be prohibited so phones could be manually reset in a controlled and clean manner. Comparing this with firmware upgrade, the process itself doesn't initiate a reset to 'ALL ones in one shot so you have control over how you want to bulk that activity, either server level or DP level etc. Thanks, TG On Nov 3, 2014 10:53 PM, Charles Goldsmith wo...@justfamily.orgmailto:wo...@justfamily.org wrote: TG, you state that you aren't trying to promote a sub, but your subject line indicates that you are. When talking about combining certs and TVS restarts, thats for a migration, moving phones from one cluster to another. This is not a way to promote a sub to a pub, which you cannot do. If you are upgrading while rebuilding a new cluster, that is one thing, but we don't do this often, and most customers do not ever do this. What I mean by this is if you are building a fresh, new cluster with the latest version and then moving phones to this new setup. Rebuilding to resolve dial plan best practices or splitting a company are the only reasons I've seen the need of a migration, but perhaps moving a group of phones from one cluster to another in a very large deployment could be a practical use of it. Pushing new certs down (by combining them) is going to cause some restarts of phones, plan for that with your outages. It's really no different than planned outages around upgrading firmware in prep for a software upgrade, which causes another round of resets as they re-register with subs. Good luck and ask your questions, but please clarify your plan and intents. On Mon, Nov 3, 2014 at 5:53 PM, TG techguy...@gmail.commailto:techguy...@gmail.com wrote: Brian, Thanks for your input. It's unfortunate we have to live with it. Need to know the significance and purpose of TVS restart on subs, as results are seen without doing it as well. Also does that cause another reset on the phones? Ryan, Maybe you misunderstood it, it is about bulk cert, and not pub recovery. Do you know of a way to stop phones from resetting just by combining the cert? We see this being fixed in 9.5 but not everyone is willing to jump to 9.5 for this gap. Cisco should consider addressing this on 8.6 and 9.1 as well as many customers are using these releases. If your 30k phones have to take a hit because of cert combining, then that's a big drawback to this whole procedure of cluster replacements. Thanks, TG On 2014-11-03 4:39 PM, Ryan Ratliff (rratliff) wrote: I'm not aware of the specifics of the doc bug Brian referenced but the original question sounds less like bulk cert import and more like a publisher recovery. Can you provide a bit more details on what you mean by promote a new publisher to existing phones? -Ryan ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] PCD CUCM Migration Upgrades with UCCX
Hi Justin, During any CUCM upgrade with UCCX (regardless of whether you’re using PCD or not) there is some time where CUCM will probably be on a higher and incompatible version with UCCX. This is expected, we just recommend you reduce the amount of time the two are incompatible, or at least plan for calls to fail until UCCX is upgraded to become compatible. The UCCX upgrade or switch-version process does not check the compatibility with CUCM or the CUCM version. I think the CCX piece of your upgrade / migration plan below looks good. Thank you, Ryan LaFountain Unified Contact Center Cisco Services Direct: +1 919 392 9898 Hours: M - F 9:00am - 5:00pm Eastern Time On Nov 4, 2014, at 11:29 AM, Justin Steinberg jsteinb...@gmail.com wrote: Anyone have any thoughts on using PCD to upgrade CUCM in environments with UCCX ? Assuming customer is running v8 CUCM UCCX on MCS hardware and wants to upgrade to 10.5. PCD can take CUCM from v8 MCS direct to ESXi and 10.5. But, UCCX isn't supported for PCD migrations. CUCM 10.5 isn't supported with UCCX v8 and likewise, UCCX 10.5 isn't supported with CUCM v8. So I was thinking of using the process below: Maintenance Window 1 1) Virtualize UCCX v8 on ESXi Maintenance Window 2 1) Install RU upgrade on UCCX to 10.5 on inactive partitions 2) PCD Upgrade/Migration CUCM to 10.5 (same IP/hostnames) 3) Once CUCM is complete, initiate switch-version on UCCX to 10.5. Does anyone see any issues with temporarily having CUCM at 10.5 before the switch-version begins on UCCX?Does UCCX check the switch-version to see if the CUCM is compatible? I haven't found this documented anywhere yet, so I've stayed away from PCD for the time being but curious if anyone has found a good way to handle PCD in environments with UCCX. Justin ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] UCCX 8.5.1sr3 to sr4 to Refresh Upgrade 10.5.1
Wow. Are you going MCS to UCS too? If not, I'm doing that exact upgrade very soon and no documentation I have reviewed indicated how long upgrades would take, let alone 5 hours. Right now my plan has a time budget of 3 hours for the same, which does not include moving ISOs to the datastore (I like doing local upgrades) nor upgrading clients. Which portion is taking 5 hours? Could you break it down by task for us? E.g., L2 to SU4, Switch Version to SU4, RU COP, RU to 10.5, Switch Version to 10.5. Did you disable IO Throttling first? Based on my research here are the summary steps to this exact upgrade (sans client upgrades): 1. Upload ISOs to DataStore 2. Disable IO Throttle on Publisher 3. Mount 8.5(1)SU4 ISO 4. Upgrade Publisher to 8.5(1)SU4 5. Switch Version to 8.5(1)SU4 6. Patch Publisher with RU COP 7. Shutdown Publisher 8. Modify VM Settings: RAM from 4GB to 8GB 9. Power On Publisher 10. Mount 10.5(1)SU1 ISO 11. Upgrade Publisher to 10.5(1)SU1 12. Switch Version to 10.5(1)SU1 On Tue Nov 04 2014 at 11:04:24 PM Jason Aarons (AM) jason.aar...@dimensiondata.com wrote: One UCCX node in ha pair 5 hours doing upgrades...it would be more enjoyable watching paint dry...there has got to be a better method in the future for L2 upgrades than this.. Sent from my Verizon Wireless 4G LTE Smartphone ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
