Unity Connection 8.6(2) to 8.6(2a) upgrade failed

OK, so I upgraded from CUCM 8.6(2) to CUCM 8.6(2a) tonight.  No problems.  Tried doing the same thing with UCXN, but failed with the following entries in the log:


10/11/2011 19:32:43 upgrade_manager.sh|Check if the upgrade is allowed|
10/11/2011 19:32:43 upgrade_manager.sh|Validate hardware for the upgrade|
10/11/2011 19:32:43 upgrade_manager.sh|Hardware is supported for the upgrade|
10/11/2011 19:32:49 upgrade_manager.sh|Validate hardware for "connection" deployment|
10/11/2011 19:32:50 upgrade_manager.sh|File:/common/download/8.6.2.20000-2/upgrade_manager.sh:1048, Function: validate_upgrade_allowed(), This server is not supported for use with the version of "connection" that you are trying to install. For information on supported servers, see the applicable version of the "connection" Supported Platforms List at http://www.cisco.com/en/US/products/ps6509/products_data_sheets_list.html|

Seems weird that the hardware is supported for the upgrade, but not for the "connection" deployment.  Can someone explain that to me?

Also, I always use VMware Workstation 7 running on Windows 7 64-bit in my lab.  I tried bumping up the RAM for this VM from 2GB to 4GB, but got the same error.  I saw some NetPro posts about increasing the hard drive size, but I think that was on ESXi and you needed a rescue CD.  I remembered that after I installed 8.6(2), I had changed the number of cores per processor from 1 to 2.

I powered off the VM, then set the number of cores per processor to 1.  I powered the VM back up, ran the upgrade again and it worked just fine.

I know its not supported, but it is interesting that I want to give more CPU power to the VM, but in doing that, it is supported?  Oh well.  I'm running 8.6(2a) on both CUCM and UCXN now.

Contact is in Terminated/Connected State

I came across this error the other day on a new UCCX 8 install.  You call into any of the triggers, but disconnects immediately.  Doing a reactive debug shows that it fails on the Accept step in the script with the following error:

Contact ID:x, Channel ID:y, Contact is in Terminated/Connected state.

You will notice that x and y will change based on your call attempts.  I tried upgrading to 8.5(1)SU1 and 8.5(1)SU2, but didn't help.

Also, in the trace files that you can grab via RTMT, you will see the following entry:

4323: Oct 01 10:25:12.495 CDT %MIVR-SS_TEL-7-UNK:CallID:4 MediaId:5937/2 Task:17000000003, CallCtlConnFailed, Inbound call, callctl cause:107, [6612:PT_Internal:1/(P1-jtapi_1) GCID=(2,4323)->ACTIVE]->FAILED

Now, ask anyone else, any you will most likely be told that it is a codec issue 99% of the time with a callctl cause of 107.  That is true.  But, in this case, it is not.

The fix is to create a new Media Termination Dialog Group and apply it to your triggers.  TAC said it has something to do with the fact that if your licensing is messed up when you setup the initial Media Termination Dialog Group, it won't work and you have to recreate it once your licensing are setup correctly.

Thanks,

IPTBuzz

Network connectivity issues in VMware with UC products

If you are like me, then you probably have some type of home lab running the UC products such as CUCM, UCXN, CUPS, UCCX, etc, in either VMware Workstation or ESXi.  I have seen an issue on CUCM, but now almost everytime after I reboot UCCX 8.x and higher, I can't ping to or from the UCCX server.  From the CLI of the UCCX server, I can only ping it's eth0 address and can't ping anything else.  From other devices, I can't ping UCCX.  Rebooting doesn't help.  The only way I can get network connectivity is to run the set network status eth0 down command followed by the set network status eth0 up command.  After a few seconds, everything works just fine.

Anyone know how to get around this without having to take the eth0 interface down and up?

***ADDED ON 10/16/2011***
I had the same issue on CUPS when I upgraded to CUPS 8.6.1.10000-34.  I would lose network connectivity to the CUPS server in the VM.  From the console, I could the address I have on eth0, but can't ping it from the VMware host or gateway.  Unfortunately, the set network status eth0 down and up commands were unsuccessful to get it pinging again.  After reading through the CLI docs and typing a ? at the CLI and looking at the commands, this is what fixed it for me:


set network restore eth0 10.10.10.15 255.255.255.0 10.10.10.1


Now, anytime I reboot the server, I lose connectivity and I always have to enter this command after the server comes back up in order to use it.

Thanks,

IPTBuzz

Bad RAID controller on UCS C210 M2 chassis

If you have a UCS chassis where the VMs go offline and you can't access the VMs with vSphere, you may have to reboot the chassis via the IMC web interface.  But, when you reboot it and watch it via the IP KVM console, this is what you don't want to see:

LSI MegaRAID SAS-MFI BIOS

Version 3.20.00 (Build November 19, 2010)

Copyright(c) 2010 LSI Corporation

HA -0 (Bus 14 Dev 0) LSI MegaRAID SAS 9261-8i

FW package: 12.12.0-0038

Multibit ECC errors were detected on the RAID controller.

The DIMM on the controller needs replacement.

Please contact technical support to resolve this issue.

If you continue, data corruption can occur.

Press 'X' to continue or else power off the system and replace the

DIMM module and reboot. If you have replaced the DIMM press 'X' to continue.

OK, so get TAC on the phone and have them send you the replacement controller.  Hopefully, you have 4 hour response.  Here is the link to replace the RAID controller in the UCS chassis:

http://www.cisco.com/en/US/docs/unified_computing/ucs/c/hw/C200M1/install/replace.html#wp1109809

After replacing the RAID controller, you will want to make sure to copy the drive configuration to the newly replaced controller.  This was not documented in the card replacement documentation.  Here is the link to do this.  Follow the instructions EXACTLY:

https://supportforums.cisco.com/docs/DOC-16321

Verify the virtual devices show up on the RAID controller during bootup.  Things still might go south.  The vSphere client may show CUCM and UCXN as missing.  This is because the datastores are not there.  TAC will need to re-add the datastores for you, possibly via CLI.  More than likely, the file system will have errors on the VMs.  It may be so bad that the won't boot, so you will need to mount the Recovery CD, boot to it, then choose the option to fix the file system errors.  After that, grab a beer. The servers should come up just fine.

Thanks,

IPTBuzz

Switch version doesn't switch

I ran into an issue recently running UCCX, although this has also happened to me on CUCM as well.  Let me make it known that these are running in VMware Workstation in a home lab.  In my recent attempt, I upgraded UCCX 8.5(1)SU1 to UCCX 8.5(1)SU2.  After the upgrade, I tried to perform a switch version from the OS Administration GUI.  But, watching from the CLI, nothing was happening.  So, I tried to switch it from the CLI with the utils system switch-version command, but got the following output:


admin: utils system switch-version


Active Master Version: 8.5.1.11001-35


Inactive Master Version: 8.5.1.11002-22




If you are switching to an earlier release, you must run:


utils dbreplication reset all


from the publisher after all the nodes are switched over.


Modified configurations will not be migrated in case you are
downgrading this server to an earlier release level




Do you really want to switch between versions ?


Enter (yes/no)? yes


 Switching Version and Restarting the Applicance ...


Switch version duration can vary depending on the database size
and platform configuration.  Please continue to monitor
the switchover process from here.




Waiting ................................


Operation failed


ERROR: Acquiring lock failed
admin:

Well, I couldn't find anything on Google, Netpro, or anywhere.  This resolution to fix this was simply rebooting normally with the utils system restart command.  Then, after the reboot, I was able to run the utils system switch-version command again, and this time it correctly switched to the other partition which made the upgraded 8.5(1)SU2 partition be the active one.  Not sure what happened, but this is what fixed it for me.  I think I had this one other time on CUCM when upgrading 8.6(1) to 8.6(2).

Another option for you if you can't switch versions is to boot to the Recovery CD for the application you are working with, then choose the option to switch version there.  I've typically used the Recovery CD to run the file system check if the server goes down hard and puts the file system in a read-only state.  But, you can also use it to switch between the active and inactive partitions.

Thanks!
IPTBuzz