Hi David. The procedure is not like it was in 4.x. To install a patch you simply navigate to the OS Administration page, choose the Software Upgrades menu --> Install/Upgrade and from here you will fill in the appropriate infomation. CD/DVD or Remote Filesystem for the Source is only where the upgrade you are going to install exists.
Once you install the upgrade you can choose to make it the Active partition which will restart node manager or you can choose to have it be inactive until a later date when you are ready to make that partition active.
Hope this is helpful.
IMPORTANT UPGRADE LESSON LEARNED
There will be a cancel button below the status window (if upgrading from the web interface), DO NOT click it!
I was running out of time on a maintenance window, and moving the massive 4GB SU1 was taking a very long time. So, I clicked the cancel button in order to stop the upgrade process, and revisit it at a later time. I am now in the process of rebuilding the server based on TAC's recommendation.
I'm still trying to figure out: a) why is there a cancel button, if pressing it destroys your server, and b) if we only install to the inactive partition, how'd the whole server break?
Interesting result Anthony. Is TAC continuing to investigate that? I recall back in CRS 5.0 there was a defect on doing a repair, if it got to the end of the repair cycle and failed at SQL initialization it would state that it failed and would roll back the changes, thus uninstalling the CRS environment components. I am wondering if this is something similar but with the inactive partition it should not have touched the active partition.
No, TAC is not. They simply said that I should not have pressed the cancel button.
Out of interest how long did the upgrade take?
Was it longer than a typical CUCM/Unity Connection upgrade?
Does it have a similar I/O throttling option to the other UC products?
I have yet to complete the SU1 upgrade. And yes, UCCX has an IO Throttle setting. That is more a function of UCOS than UCCX or CUCM, etc.
Anthony, I'll get to thebottom of your question about cancelling the upgrade when it is in process. Of course, I have not been involved in that case so I don't have the specifics of what may have happened but I can certainly find out if this is some kind of known no-no or maybe just a string of bad luck. I'll get back to you on what I find out later today.
Michael, thank you for going out of your way to help out. If you are ever in the twin cities, we should get together.
Likewise if you are ever in the Dallas area.
So the official word back is that the upgrade happens on the inactive parition and can be cancelled anytime during the upgrade. There are 2 steps in the upgrade process.
Upgrade - installs the binary on the inactive partition.
Switch Version - this has to be triggered manually after the upgrade (mentioned above) is complete.
So the question I have is, when was the upgrade cancelled? During the upgrade or during the switch?
Also, when you say the system was down, was it the services that were down or the box itself in a shutdown state?
Thanks for the responses everyone, particularly Michael. One more question if I may. My call Center is 24/7, and they would prefer little to no down time. If I have High Availability what would be the desired upgrade strategy to achieve my customers goals? Since the upgrade can happen on an inactive partition, I assume I can do the standby server in total while the first node is still churning away. At the point of switching Masters, I assume it will need to push some client fixes. Would it be a matter of a relogin for the agents and an install of the update ... then they should be able to start taking calls right awa? And then I would apply the patch to the frist node, etc?
Thanks again for the taking the time to post everyone.
Thanks for the follow-up Mike.
I cancelled the upgrade during the upgrade. You know, after it copies the upgrade file over, and you see the textarea field that scrolls the log file, that's when I clicked it. I cannot say what was currently in the window, or how long it was running, as I didn't think things would go this wrong.
To be more clear about the state of the server, it was unreachable via web, or CLI, but I could ping it. I had to manually reboot it by holding down the power button, at which point there were several errors and failures scrolling on the console.
At this point, I could connect via SSH, and issued a "show version active" and "show version inactive" which showed the current and previous versions respectively. So if the inactive partition was being upgraded, and I cancelled it, I should now be running in the untouched active partition.
However, the server is scrolling errors at the console, cannot be rebooted via CLI, and the web interface is not accessible.
I have a few questions around this. I'm planning to do an upgrade from 802(base) to 802SU3
a) there should only be 1 file (UCSInstall_UCCX_8_0_2_UCOS_220.127.116.1104-12.sgn.iso) in the CD/DVD/etc?
b) in HA mode, do i need to perform the upgrade both Pub & Sub before doing the switch version?
c) the system will still be running the 'old' version until the switch version is done?
c) how long does the typical upgrade takes?
1. There are 1 files. 1 of 2 and 2 of 2. You will need to follow the instructions in the readme file to combine the files into one and then check it to make sure it was combined correctly.
2. You need to perform the upgrade on both nodes. It will not migrate an upgrade from one node to the other.
3. At the end of the upgrade it will ask if you want to make that upgrade active now or later. If now it will reboot the box. If later it will set it to the inactive partition and you can change that later. Check the documentation on this.
4. The upgrade process can take a while. I would guess 60 to 90 minutes for each node probably.