Here's a tip:     Switch Version Failure Another way data often gets lost is when customers lose patience with the switch-version section of a UCCX 8.x or 9.x upgrade: the switch-version process does not show a progress update and all too often, customers reboot the server because they think the process “hung”. During a switch-version, all data from the old version is copied across to the new version. Interrupting this process will result in the data becoming corrupt, and unusable. Switching version to UCCX 8.5(1)SU3 and above includes an option to recover from this. However, it is simply better to prevent; you can read the logs instead of wondering whether the process hung. Use the CLI command   The key word in that post is 'often'.  So, a way data often gets lost is via known deficiencies in the update process, yet here we are five years later and Cisco still hasn't fixed this.  It's compounded by the fact that other software in the unified communications suite has the same upgrade process, yet doesn't have the horrid delay when switching versions.  We're taught by CUCM that it should go quickly, then find UCCX goes slowly, with no apparent CPU or disk activity while it is actually doing something, then a reboot is issued.   If the web interface can't be fixed, customers should be forced to upgrade via CLI.  It would have saved me hours of wasted time today, and downtime.  I would have been perfectly content to switch versions via CLI had I been given even the most simple of warnings via web interface that hey, this may take a VERY LONG time and you should use CLI instead if you want to know what's going on.  Even that isn't good enough though, CLI will appear to hang forever too, so why not incorporate the tail command output into the switch command so you know it is actually doing something? ... View more

This ridiculously stupid software also blocks you from switching versions if you gave the VM more memory than the OVF specified.  I had to take it from 8 to 10 for an 11.6 upgrade, so figured I'll just bump it from 8 to 12 instead, version switch at the end errors with error.switch.uccx.ovfmismatch until I set it back to 10.  ... View more

Same thing just happened to me going from 10.6 to 11.6, so even after a year they still haven't figured out how to fix this.  It took 90 minutes to get to:   10/12/2018 10:54:39 upgrade_install.sh|release_upgrade_lock: Releasing lock (pid: 32103)|<LVL::Debug>   then sat there for hours.  I gave up and reboot.  The subscriber did the same exact thing. ... View more

Unfortunately UCS doesn't accept GMT or UTC as a valid timezone.  The CLI is basically just a mirror for what you can pick in the Time Zone Management area of the Admin tab:   ucs10-B /system/services # set timezone Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. 1) Africa 4) Arctic Ocean 7) Australia 10) Pacific Ocean 2) Americas 5) Asia 8) Europe 3) Antarctica 6) Atlantic Ocean 9) Indian Ocean #?   You then further drill down to specific countries and cities.  Oh, you did help guide me to what I think will work though.  As I dug around, I found that Atlantic/Reykjavik is available under Atlantic Ocean, and they are matched to UTC without daylight savings adjustment, so that should work. ... View more

Sorry, I think I was confusing with the back story; these two systems are parallel and the service profiles, etc. are all being set up independently; no copying of configs, etc.  I'm just trying to figure out the difference, and consequences, of what was ten similarly named NICs presented to ESXi by older UCS and now seems to be five MLOM NICs and five "Chassis" NICs. ... View more

I updated a 2504 and it took bootloader to 1.0.20 but left firmware as PIC 16.0.  I put 8.3.122.0 on but it still has PIC 16.0.  Is this a symptom of an incomplete FUS update?  I was under the impression my 8.3.122 install should have failed, so now I'm really confused. ... View more