Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- :
- About Brett Hanson
09-21-2018
Brett Hanson
Member since
02-03-2011
Beginner
03-31-2014
11:29 PM
Well, good news. After changing the IP to 10.33.159.105 255.255.255.0, restarting the sub, changing the IP back to 10.33.159.100, restarting the sub again - the upgrade worked. Bizarre. PS. show network eth0 still shows a mask ending in .000 but I didn't encounter the same problems and everything is looking peachy. admin:show network eth0 Ethernet 0 DHCP : disabled Status : up IP Address : 10.33.159.100 IP Mask : 255.255.255.000 Version looks good: Command Line Interface is starting up, please wait ... Welcome to the Platform Command Line Interface VMware Installation: 2 vCPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz Disk 1: 80GB, Partitions aligned 4096 Mbytes RAM admin:show version active Active Master Version: 9.1.2.10000-28 Active Version Installed Software Options: cmterm-7937-1-4-4-SCCP.cop cmterm-7936-sccp.3-3-21.cop cm-locale-combined_network-8.0.1.1000-2.cop cmterm-7945_7965-sccp.9-3-1SR2-1.cop ciscocm.refresh_upgrade_v1.3.cop dp-ffr.3-1-9.AU.cop cmterm-7941_7961-sccp.9-3-1SR2-1.cop
... View more
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
03-31-2014
09:41 PM
03-31-2014
09:41 PM
Hi, Hope someone can shed some light and help us with an issue. We're upgrading CUCM cluster from 8.0.2.40000-1 to 9.1.2.10000-28 Systems were on MCS hardware - migrated 8.0(2) successfully to VM infrastructure. Appeared to successfully upgrade Publisher. During upgrade to Sub (after Pub upgrade was completed and server restarted) - it fails with an error message "Refresh Upgrade Failed - Error detected in post-install phase. Trying to restore the system to the active version. Please wait..." It then restarted. I was watching the console output and noted that when it went to enable Eth0 it produced the following output: "Brining up interface eth0: ipcalc: bad netwmask: 255.255.255.000 ipcalc: bad netwmask: 255.255.255.000 ipcalc: bad netwmask: 255.255.255.000 Cannot get current device settings: Operation not supported. not setting autoneg Error: an inet prefix is expected rather than "10.33.159.100/". Error adding address 10.33.159.100 for eth0. bind: Cannot assign requested address RTNETLINK answers: No such device [ OK ]" It then continued to boot up and went back into the original version. I ran a check of the inactive version and there's nothing there "No Inactive side available". I tried to change the IP to change the subnet mask from 255.255.255.000 to 255.255.255.0 but after it changed and restarted, the output of "show network eth0" still shows subnet mask with the 3 x 0 (255.255.255.000). I thought maybe it had just kept the same mask due to same IP being configured so I changed the address to something different (10.33.159.105 255.255.255.0). After restart it also shows netmask of 255.255.255.000 I didn't encounter this issue on the Publisher - but our subnet mask on the Publisher is 255.255.255.128 I'm going to try again now that I've "changed" the IP and will update with outcome if favourable (won't bother if the result is the same). Sub output that may help in your thoughts: VMware Installation: 2 vCPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz Disk 1: 80GB 4096 Mbytes RAM admin:show version active Active Master Version: 8.0.2.40000-1 Active Version Installed Software Options: cmterm-7937-1-4-4-SCCP.cop cmterm-7936-sccp.3-3-21.cop cm-locale-combined_network-8.0.1.1000-2.cop cmterm-7945_7965-sccp.9-3-1SR2-1.cop ciscocm.refresh_upgrade_v1.3.cop dp-ffr.3-1-9.AU.cop localeinstaller cmterm-7941_7961-sccp.9-3-1SR2-1.cop admin:show version inactive Executed command unsuccessfully No Inactive side availabl Pub output of the same: admin:show version active Active Master Version: 9.1.2.10000-28 Active Version Installed Software Options: cmterm-7941_7961-sccp.9-3-1SR2-1.cop cmterm-7936-sccp.3-3-21.cop cm-locale-combined_network-8.0.1.1000-2.cop dp-ffr.3-1-9.AU.cop ciscocm.refresh_upgrade_v1.3.cop cmterm-7937-1-4-4-SCCP.cop cmterm-7945_7965-sccp.9-3-1SR2-1.cop admin:show version inactive Inactive Master Version: 8.0.2.40000-1 Inactive Version Installed Software Options: cmterm-7941_7961-sccp.9-3-1SR2-1.cop cmterm-7936-sccp.3-3-21.cop cm-locale-combined_network-8.0.1.1000-2.cop dp-ffr.3-1-9.AU.cop ciscocm.refresh_upgrade_v1.3.cop cmterm-7937-1-4-4-SCCP.cop cmterm-7945_7965-sccp.9-3-1SR2-1.cop
... View more
Labels:
03-10-2014
12:25 AM
I had this same error when attempting to install firmware cop files. Resolved - details here: https://supportforums.cisco.com/discussion/12132291/error-encountered-error-final-installdb-run-unsuccessful-during-firmware-cop
... View more
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
03-06-2014
09:24 AM
03-06-2014
09:24 AM
Hi all, Just a heads up to anyone else who encounters this error when installing device firmware cop files onto CUCM. We were upgrading the firmware on our CUCM cluster (small - consists of 1 x Publisher and 1 x Subscriber) - running 8.0.2.40000-1 I was installing: cmterm-7936-sccp.3-3-21.cop.sgn cmterm-7937-1-4-4-SCCP.cop.sgn cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn When doing so on the publisher server - it was throwing the following error output (note that the files actually ended up on the TFTP server but devices were not picking up the new firmware): Installation Status File cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn Start Time Thu Mar 06 19:34:24 WST 2014 Status Error encountered: ERROR: Final installdb run unsuccessful 03/06/2014 19:33:42 file_list.sh|Starting file_list.sh|<LVL::Info> 03/06/2014 19:33:42 file_list.sh|Parse argument method=sftp|<LVL::Debug> 03/06/2014 19:33:42 file_list.sh|Parse argument source_dir=/|<LVL::Debug> 03/06/2014 19:33:42 file_list.sh|Parse argument dest_file=/var/log/install/downloaded_versions|<LVL::Debug> 03/06/2014 19:33:42 file_list.sh|Parse argument remote_host=10.133.1.240|<LVL::Debug> 03/06/2014 19:33:42 file_list.sh|Parse argument user_name=ccmadministrator|<LVL::Debug> 03/06/2014 19:33:42 file_list.sh|Calling SFTP command with metering off|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|SFTP command complete (0)|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|List file (pre-filtered):|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) RSA|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) UC|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) WIRELESS|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) asa914-k8.bin|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) cmterm-7936-sccp.3-3-21.cop.sgn|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) cmterm-7937-1-4-4-SCCP.cop.sgn|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|(CAPTURE) cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn|<LVL::Debug> 03/06/2014 19:33:43 file_list.sh|/usr/local/bin/base_scripts/filter.sh file=/var/log/install/downloaded_versions|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Parse argument file=/var/log/install/downloaded_versions|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|No patch type specified. Optional.|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|No upgrade mode specifed. Optional.|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Current version is 8.0.2.40000-1|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Processing token "RSA"|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|INorOUT=OUT RSA: Not a signed patch file|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Processing token "UC"|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|INorOUT=OUT UC: Not a signed patch file|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Processing token "WIRELESS"|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|INorOUT=OUT WIRELESS: Not a signed patch file|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Processing token "asa914-k8.bin"|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|INorOUT=OUT asa914-k8.bin: Not a signed patch file|<LVL::Debug> 03/06/2014 19:33:43 filter.sh|Processing token "cmterm-7936-sccp.3-3-21.cop.sgn"|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|INorOUT=IN cmterm-7936-sccp.3-3-21.cop.sgn: filter passed|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|Processing token "cmterm-7937-1-4-4-SCCP.cop.sgn"|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|INorOUT=IN cmterm-7937-1-4-4-SCCP.cop.sgn: filter passed|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|Processing token "cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn"|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|INorOUT=IN cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn: filter passed|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|Processing token "cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn"|<LVL::Debug> 03/06/2014 19:33:44 filter.sh|INorOUT=IN cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn: filter passed|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|List file (post-filtered):|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) RSA:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) UC:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) WIRELESS:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) asa914-k8.bin:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7936-sccp.3-3-21.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7937-1-4-4-SCCP.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|List file (pre-structured):|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) RSA:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) UC:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) WIRELESS:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) asa914-k8.bin:1|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7936-sccp.3-3-21.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7937-1-4-4-SCCP.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:44 file_list.sh|(CAPTURE) cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn:0|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|List file (post-structured):|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <InstallList>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <FilteredItem type="" file="RSA" result="1"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <FilteredItem type="" file="UC" result="1"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <FilteredItem type="" file="WIRELESS" result="1"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <FilteredItem type="" file="asa914-k8.bin" result="1"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <InstallItem type="copfile" secure-file="cmterm-7936-sccp.3-3-21.cop.sgn" version="" file="cmterm-7936-sccp.3-3-21.cop" reboot="no"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <InstallItem type="copfile" secure-file="cmterm-7937-1-4-4-SCCP.cop.sgn" version="" file="cmterm-7937-1-4-4-SCCP.cop" reboot="no"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <InstallItem type="copfile" secure-file="cmterm-7941_7961-sccp.9-3-1SR2-1.cop.sgn" version="" file="cmterm-7941_7961-sccp.9-3-1SR2-1.cop" reboot="no"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) <InstallItem type="copfile" secure-file="cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn" version="" file="cmterm-7945_7965-sccp.9-3-1SR2-1.cop" reboot="no"/>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|(CAPTURE) </InstallList>|<LVL::Debug> 03/06/2014 19:33:46 file_list.sh|success|<LVL::Info> 03/06/2014 19:33:46 file_list.sh|file_list.sh complete (rc=0)|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|Starting upgrade_validate_file.sh|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|Parse argument method=sftp|<LVL::Debug> 03/06/2014 19:34:19 upgrade_validate_file.sh|Parse argument source_dir=/|<LVL::Debug> 03/06/2014 19:34:19 upgrade_validate_file.sh|Parse argument file_name=cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn|<LVL::Debug> 03/06/2014 19:34:19 upgrade_validate_file.sh|Parse argument remote_host=10.133.1.240|<LVL::Debug> 03/06/2014 19:34:19 upgrade_validate_file.sh|Parse argument user_name=ccmadministrator|<LVL::Debug> 03/06/2014 19:34:19 upgrade_validate_file.sh|Getting patch size via sftp for cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|Size of patch file = 6018125|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|Total space needs = 12036250|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh| Free space : 126461788160|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|Space needed : 24072500|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|There is enough space on device to proceed.|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|success|<LVL::Info> 03/06/2014 19:34:19 upgrade_validate_file.sh|upgrade_validate_file.sh complete (rc=0)|<LVL::Info> 03/06/2014 19:34:19 upgrade_get_file.sh|Starting upgrade_get_file.sh|<LVL::Info> 03/06/2014 19:34:19 upgrade_get_file.sh|Parse argument method=sftp|<LVL::Debug> 03/06/2014 19:34:19 upgrade_get_file.sh|Parse argument source_dir=/|<LVL::Debug> 03/06/2014 19:34:19 upgrade_get_file.sh|Parse argument file_name=cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn|<LVL::Debug> 03/06/2014 19:34:19 upgrade_get_file.sh|Parse argument dest_dir=/common/download/|<LVL::Debug> 03/06/2014 19:34:19 upgrade_get_file.sh|Parse argument remote_host=10.133.1.240|<LVL::Debug> 03/06/2014 19:34:19 upgrade_get_file.sh|Parse argument user_name=ccmadministrator|<LVL::Debug> 03/06/2014 19:34:20 upgrade_get_file.sh|Starting SFTP of cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn|<LVL::Info> 03/06/2014 19:34:21 upgrade_get_file.sh|SFTP command complete (0)|<LVL::Info> 03/06/2014 19:34:21 upgrade_get_file.sh|Download of iso file RTMTStart|<LVL::Notice> 03/06/2014 19:34:21 upgrade_get_file.sh|Create md5 "/common/download/cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn.md5"|<LVL::Info> 03/06/2014 19:34:21 upgrade_get_file.sh|MD5(/common/download/cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn)= e3:02:d3:e1:89:ff:a1:eb:0a:71:52:03:ad:d7:e2:85|<LVL::Debug> 03/06/2014 19:34:21 upgrade_get_file.sh|Create md5 complete|<LVL::Info> 03/06/2014 19:34:21 upgrade_get_file.sh|Authenticate file "/common/download/cmterm-7945_7965-sccp.9-3-1SR2-1.cop.sgn"|<LVL::Info> 03/06/2014 19:34:21 upgrade_get_file.sh|File authentication complete|<LVL::Debug> 03/06/2014 19:34:21 upgrade_get_file.sh|Download of iso file RTMTFinish|<LVL::Notice> 03/06/2014 19:34:22 upgrade_get_file.sh|success|<LVL::Info> 03/06/2014 19:34:22 upgrade_get_file.sh|upgrade_get_file.sh complete (rc=0)|<LVL::Info> 03/06/2014 19:34:24 Terminating active side processes 03/06/2014 19:34:24 Terminating active side processes done 03/06/2014 19:34:24 Terminating inactive side processes 03/06/2014 19:34:24 Calling /usr/local/bin/base_scripts/sd_killPartitionB_PIDs.sh / 03/06/2014 19:34:24 Terminating inactive side processes done (13953) Thu Mar 6 19:34:30 WST 2014 install option (13953) Thu Mar 6 19:34:30 WST 2014 Successful untarring of option /common/download//cmterm-7945_7965-sccp.9-3-1SR2-1.cop. (13953) Thu Mar 6 19:34:36 WST 2014 Publisher: Starting installdb... /bin/su -l informix -s /bin/sh -c "source /usr/local/cm/db/dblenv.bash /usr/local/cm ; source /usr/local/cm/db/informix/local/ids.env ; nice /usr/local/cm/bin/installdb -x /usr/local/cm/db/xml/xml" disablenotify rc[0] xml DSN=ccm_super /usr/local/cm/db/xml/xml installXml rc[1] enablenotify dsn[DSN=ccm_super] enablenotify rc[0] installdb Failure [-x] 1 (13953) Thu Mar 6 19:34:47 WST 2014 ERROR: Final installdb run unsuccessful I'd read in various places to perform a CLI command "run loadxml" - which we did but it produced the following output: admin:run loadxml This command is processor intensive, and may take a few minutes to run. It should only be run on the publisher. Some services may require a restart afterwards. This is a CPU intensive command and will take a considerable amount of time to complete. Do you want to continue (y/n)? Starting loadxml disablenotify dsn[DSN=ccm_super] disablenotify rc[0] xml DSN=ccm_super /usr/local/cm/db/xml/xml installXml rc[1] enablenotify dsn[DSN=ccm_super] enablenotify rc[0] installdb Failure [-x] 1 loadxml function complete Failure essentially. Note that the installation went ahead without issues on the Subscriber servers after we tried on the publisher. I believe this is due to it only copying the files to the TFTP server and not updating the database. I also noted that the following features vanished from the CUCM Administration GUI (the menus were there but the pages came up blank): "Enterprise Paramaters" "Enterprise Phone Configuration" "Service Parameters" (after selecting "server" & "service" drop down options, nothing was displayed) Within individual "Phone Configuration" - the entire "Product Specific Configuration Layout" was missing from all devices. I was also unable to export the 'Cisco Database Installation Service' logs from RTMT - it threw an error to the status bar at the bottom stating "Collection cancelled for node <publisher> due to the error" (and there was no error info output...joy!). I called in TAC and Roman Kramarski assisted me via WebEx to full resolution of the issue - thanks Roman After running "run loadxml" We ran the following command which showed us (after much wizzing by of entries) the list of log files, the 5th or so last file in the list being the log output from the "run loadxml" output - The command: "file list activelog /cm/trace/dbl/sdi detail date" Our file in question happened to be called "installdb20140306-230735.log" (like I said, was about 5th from the bottom of the list) Next we viewed the file: "file view activelog /cm/trace/dbl/sdi/installdb20140306-230735.log" In the file, fairly close to the top, it showed the following error message: "23:07:35.047 | DOMErrorReporter::fatalError *ERROR* Fatal Error at file /usr/local/cm/db/xml/xml/366X_display_instance-fxo_port_gs.xml, line 56, column 22" This, along with the output of the run loadxml command, indicated that "/usr/local/cm/db/xml/xml/366X_display_instance-fxo_port_gs.xml" file was corrupted or incomplete. Roman (TAC) then used the Cisco access to root in order to look at the actual file. It was incomplete - it ended mid closure of a tag: "<name>OutputAttenuation</n#" (Instead of "<name>OutputAttenuation</name>" plus a whole bucketload more output. Luckily I had a fresh install of the exact same version of CUCM just installed on in a dev environment - so Roman was able to get into that one, TFTP the file out, and then TFTP the new file in. We moved the old corrupt file into another folder (as we renamed it initially and then ran "run loadxml" which produced the error again) - copied the new complete file into the folder - then "run loadxml" ran successfully. admin:run loadxml This command is processor intensive, and may take a few minutes to run. It should only be run on the publisher. Some services may require a restart afterwards. This is a CPU intensive command and will take a considerable amount of time to complete. Do you want to continue (y/n)? Starting loadxml disablenotify dsn[DSN=ccm_super] disablenotify rc[0] xml DSN=ccm_super /usr/local/cm/db/xml/xml installXml rc[0] enablenotify dsn[DSN=ccm_super] enablenotify rc[0] installdb Success[-x] loadxml function complete NOTE that the running of run loadxml did not take that long and didn't cause any outages to my system. After we did this - the installations went ahead successfully. After a restart of the TFTP service on each server - firmware upgrades went ahead successfully. Basically - you can do the initial troubleshooting of checking logs of run loadxml and then pass that detail to Cisco TAC to get them to use root access to copy a fresh version of the file across. Hope this helps.
... View more
- Tags:
- 7900_ip_phone
- cop
- cucm
- encountered
- enterprise_paramaters_missing
- error
- firmware
- installdb
- rtmt
- tac
- unsuccessful
Labels:
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
02-23-2014
09:31 PM
02-23-2014
09:31 PM
Thanks DJOHNSON. Had this issue afer migrating to VM's and upgrading from 8.0(2) to 9.1 - regenerated the certs per your information, restarted all servers in cluster, worked a treat. For those who are less knowlegeable and want a little more detail... Login to OS Administration GUI (Cisco Unified OS administration) for all servers in the cluster (in our case 1 x Publisher & 1 x Subscriber), Select "Security" > "Certificate Management" > click "Find" which returns a bunch of certificates. Clickon each of the following in turn, then click "Regenerate" when taken to the certificate configuration screen, once it updates, click on "Go" to go back to the list and then move onto the next one in the list. tomcat.pem ipsec.pem CallManager.pem CAPF.pem TVS.pem Once you have done this for all servers in the cluster - restart them (I didn't do it in any particular order) - from CLI (or VM console) "utils system restart". After all were back up and running - connectivity was back again.
... View more
Created by
Brett Hanson
in Other Network Architecture Subjects
in Other Network Architecture Subjects
02-17-2014
09:15 PM
02-17-2014
09:15 PM
Had this same issue. Resolved by powering it off, opening it up, removing and re-seating all cards/RAM/etc. in the whole device, putting it back together, powering it back up. HTH
... View more
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
11-28-2013
08:06 PM
11-28-2013
08:06 PM
Thanks David, rating given.
... View more
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
11-28-2013
08:06 PM
11-28-2013
08:06 PM
Thanks Chris, rating given.
... View more
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
11-27-2013
08:04 PM
11-27-2013
08:04 PM
Hi folks, I've been trying to find out what the expected behaviour is for CUCM NTP in the event that the Publisher goes down and am not having any luck. As the Publisher looks to the NTP server for time and the Sub looks to the Publisher for time, what happens when the Publisher is unavailable? Does the Subscriber pick up the role of the Publisher and then look to the external source for NTP? Cheers, Brett
... View more
Labels:
Created by
Brett Hanson
in IP Telephony and Phones
in IP Telephony and Phones
09-05-2013
06:07 PM
09-05-2013
06:07 PM
In the end it just went away - I'm still going to put it down to carrier. Interestingly - the issue has cropped up again but this time at another site on the other side of the country (Brisbane). A look at the logs shows it happened a couple of times on Sunday, a couple of times on Wednesday, and a shedload of times yesterday. Nothing yet today. This just makes me believe the carrier has an issue - advice - keep pushing back on the carrier or migrate to SIP trunks and do away with ISDN altogether. We're, co-incidentally, replacing this router as part of a refresh in the next 2 to 3 weeks - if the problem persists over the next couple of days, we'll likely expedite this in order to rule out hardware on our side for this instance. But yeah - basically I haven't found anything on our side from past experience that indicates anything other than issue at carrier. zcat bri-rtr00-2013-09-0* | egrep -i 'clk|layer2|lof|rai|ais' bri-rtr00 Sep 1 11:46:02 2013 83367: Sep 1 13:46:02 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (LOF detected) bri-rtr00 Sep 1 11:46:02 2013 83368: Sep 1 13:46:02 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 1 11:46:03 2013 83369: Sep 1 13:46:02 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 1 11:46:04 2013 83371: Sep 1 13:46:03 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 1 11:46:06 2013 83372: Sep 1 13:46:05 AET: %MARS_NETCLK-3-HOLDOVER: Exiting Holdover for Controller E1 0/3/0 bri-rtr00 Sep 3 04:04:07 2013 83511: Sep 3 06:04:07 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (LOF detected) bri-rtr00 Sep 3 04:04:07 2013 83512: Sep 3 06:04:07 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 3 04:04:08 2013 83513: Sep 3 06:04:07 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 3 04:04:09 2013 83515: Sep 3 06:04:08 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 3 04:04:12 2013 83516: Sep 3 06:04:10 AET: %MARS_NETCLK-3-HOLDOVER: Exiting Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 09:45:54 2013 84097: .Sep 5 11:45:53 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 09:45:54 2013 84098: .Sep 5 11:45:53 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 09:45:55 2013 84099: .Sep 5 11:45:53 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 09:46:05 2013 84101: .Sep 5 11:46:03 AET: %MARS_NETCLK-3-HOLDOVER_TRANS: Holdover timer exceeded for Controller E1 0/3/0 bri-rtr00 Sep 5 09:46:05 2013 84102: .Sep 5 11:46:03 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 bri-rtr00 Sep 5 09:46:40 2013 84104: .Sep 5 11:46:38 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 09:46:40 2013 84105: .Sep 5 11:46:38 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 09:46:45 2013 84107: .Sep 5 11:46:43 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 09:46:48 2013 84108: .Sep 5 11:46:47 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 09:46:49 2013 84109: .Sep 5 11:46:47 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 09:47:32 2013 84113: .Sep 5 11:47:30 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1 bri-rtr00 Sep 5 09:47:33 2013 84114: .Sep 5 11:47:31 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 09:49:53 2013 84115: .Sep 5 11:49:52 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 09:49:53 2013 84116: .Sep 5 11:49:52 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 09:49:54 2013 84117: .Sep 5 11:49:52 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 09:50:04 2013 84119: .Sep 5 11:50:02 AET: %MARS_NETCLK-3-HOLDOVER_TRANS: Holdover timer exceeded for Controller E1 0/3/0 bri-rtr00 Sep 5 09:50:04 2013 84120: .Sep 5 11:50:02 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 bri-rtr00 Sep 5 09:50:39 2013 84122: .Sep 5 11:50:37 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 09:50:49 2013 84124: .Sep 5 11:50:47 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1 bri-rtr00 Sep 5 13:57:42 2013 84259: .Sep 5 15:57:41 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 13:57:42 2013 84260: .Sep 5 15:57:41 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 13:57:43 2013 84261: .Sep 5 15:57:41 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 13:57:53 2013 84263: .Sep 5 15:57:52 AET: %MARS_NETCLK-3-HOLDOVER_TRANS: Holdover timer exceeded for Controller E1 0/3/0 bri-rtr00 Sep 5 13:57:53 2013 84264: .Sep 5 15:57:52 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 bri-rtr00 Sep 5 13:59:32 2013 84266: .Sep 5 15:59:30 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 13:59:42 2013 84268: .Sep 5 15:59:41 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1 bri-rtr00 Sep 5 14:10:22 2013 84269: .Sep 5 16:10:21 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 14:10:22 2013 84270: .Sep 5 16:10:21 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 14:10:23 2013 84271: .Sep 5 16:10:21 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 14:10:33 2013 84273: .Sep 5 16:10:32 AET: %MARS_NETCLK-3-HOLDOVER_TRANS: Holdover timer exceeded for Controller E1 0/3/0 bri-rtr00 Sep 5 14:10:33 2013 84274: .Sep 5 16:10:32 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 bri-rtr00 Sep 5 14:11:09 2013 84276: .Sep 5 16:11:07 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 14:11:18 2013 84278: .Sep 5 16:11:17 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1 bri-rtr00 Sep 5 14:12:55 2013 84279: .Sep 5 16:12:54 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 14:12:55 2013 84280: .Sep 5 16:12:54 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 14:12:56 2013 84281: .Sep 5 16:12:54 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 14:13:06 2013 84283: .Sep 5 16:13:05 AET: %MARS_NETCLK-3-HOLDOVER_TRANS: Holdover timer exceeded for Controller E1 0/3/0 bri-rtr00 Sep 5 14:13:06 2013 84284: .Sep 5 16:13:05 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 bri-rtr00 Sep 5 14:18:08 2013 84286: .Sep 5 16:18:06 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (RAI detected) bri-rtr00 Sep 5 14:18:11 2013 84290: .Sep 5 16:18:10 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (LOF detected) bri-rtr00 Sep 5 14:18:54 2013 84294: .Sep 5 16:18:52 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 14:19:04 2013 84296: .Sep 5 16:19:03 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1 bri-rtr00 Sep 5 14:20:09 2013 84297: .Sep 5 16:20:08 AET: %CONTROLLER-5-UPDOWN: Controller E1 0/3/0, changed state to down (LOF detected) bri-rtr00 Sep 5 14:20:09 2013 84298: .Sep 5 16:20:08 AET: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to down bri-rtr00 Sep 5 14:20:10 2013 84299: .Sep 5 16:20:08 AET: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller E1 0/3/0 bri-rtr00 Sep 5 14:20:20 2013 84301: .Sep 5 16:20:19 AET: %MARS_NETCLK-3-HOLDOVER_TRANS: Holdover timer exceeded for Controller E1 0/3/0 bri-rtr00 Sep 5 14:20:20 2013 84302: .Sep 5 16:20:19 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 bri-rtr00 Sep 5 14:21:25 2013 84304: .Sep 5 16:21:23 AET: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:15, TEI 0 changed to up bri-rtr00 Sep 5 14:21:35 2013 84306: .Sep 5 16:21:34 AET: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1
... View more
Created by
Brett Hanson
in Contact Center
in Contact Center
08-13-2013
04:10 AM
08-13-2013
04:10 AM
Thanks Julien, I used the Set Enterprise Call Info step in the Place Call step as you suggested - worked a treat for me. Thanks!
... View more
WLC 5508 management port is not pingabl...
in Wireless and Mobility
07-18-2013
12:30 AM
07-18-2013
12:30 AM
Thanks Scott, This resolved the issue for me (had it too). Have rated. Cheers, Brett
... View more
Created by
Brett Hanson
in Contact Center
in Contact Center
06-24-2013
06:48 PM
06-24-2013
06:48 PM
Ditto here. Version 8.0.2.11005-20 Also was due to folders created accidentally in CCX Editor (using the current CCX Editor installed from the existing UCCX system's plug-ins page) - running 64bit Win 7 and 64bit Win 8. It annoys me no end as there's 5 or so of them sitting there when navigating to Script Management. Is there a Cisco rep on here that can offer maybe some CLI solution or create a bug? Has anyone logged this issue with TAC? I haven't yet but will do so eventually. If so, what was the outcome? Bump
... View more
Created by
Brett Hanson
in VPN and AnyConnect
in VPN and AnyConnect
05-13-2013
10:03 PM
05-13-2013
10:03 PM
Hi Jouni, Thanks for that. Yeah - for my purposes a second link would be purely for a L2L VPN so would be easy for the routing side of things. I'll have to do some research and determine if we have support staff connecting to the customer RA VPN on the same IP or not. Anyway, cheers for the heads up. Cheers, Brett
... View more
Created by
Brett Hanson
in VPN and AnyConnect
in VPN and AnyConnect
05-13-2013
02:24 AM
05-13-2013
02:24 AM
How'd you go with this? Were you able to run VPN's on the 2 outside interfaces in the end? If so - what did you do? Were you able to attach the crypto map to multiple interfaces?
... View more
03-31-2014 11:29 PM
Well, good news.After changing the IP to 10.33.159.105 255.255.255.0,
restarting the sub, changing t...
Created by
Brett Hanson
in IP Telephony and Phones
03-31-2014 09:41 PM
03-31-2014 09:41 PM
Hi,Hope someone can shed some light and help us with an issue.We're
upgrading CUCM cluster from 8.0....
03-10-2014 12:25 AM
I had this same error when attempting to install firmware cop
files.Resolved - details here:
https:/...
Created by
Brett Hanson
in IP Telephony and Phones
03-06-2014 09:24 AM
03-06-2014 09:24 AM
Hi all, Just a heads up to anyone else who encounters this error when
installing device firmware cop...
Created by
Brett Hanson
in IP Telephony and Phones
02-23-2014 09:31 PM
02-23-2014 09:31 PM
Thanks DJOHNSON.Had this issue afer migrating to VM's and upgrading from
8.0(2) to 9.1 - regenerated...
Created by
Brett Hanson
in Other Network Architecture Subjects
02-17-2014 09:15 PM
02-17-2014 09:15 PM
Had this same issue.Resolved by powering it off, opening it up, removing
and re-seating all cards/RA...
Created by
Brett Hanson
in IP Telephony and Phones
11-28-2013 08:06 PM
11-28-2013 08:06 PM
Thanks David, rating given.
Created by
Brett Hanson
in IP Telephony and Phones
11-28-2013 08:06 PM
11-28-2013 08:06 PM
Thanks Chris, rating given.
Created by
Brett Hanson
in IP Telephony and Phones
11-27-2013 08:04 PM
11-27-2013 08:04 PM
Hi folks,I've been trying to find out what the expected behaviour is for
CUCM NTP in the event that ...
Created by
Brett Hanson
in IP Telephony and Phones
09-05-2013 06:07 PM
09-05-2013 06:07 PM
In the end it just went away - I'm still going to put it down to
carrier.Interestingly - the issue h...
Created by
Brett Hanson
in Unified Communications Infrastructure
08-20-2013 04:05 AM
08-20-2013 04:05 AM
Another question if you have a moment Barry, with resepect to the point
"After the restore, check th...
Created by
Brett Hanson
in Contact Center
08-13-2013 04:10 AM
08-13-2013 04:10 AM
Thanks Julien, I used the Set Enterprise Call Info step in the Place
Call step as you suggested - wo...
Created by
Brett Hanson
in Unified Communications Infrastructure
08-04-2013 08:55 PM
08-04-2013 08:55 PM
Hi,We're looking to upgrade our Unified Communications servers and
applications (CUCM, CUC, UCCX) fr...
Created by
Brett Hanson
in Wireless and Mobility
07-18-2013 12:30 AM
07-18-2013 12:30 AM
Thanks Scott,This resolved the issue for me (had it too).Have
rated.Cheers,Brett
Created by
Brett Hanson
in Unified Communications Infrastructure
07-10-2013 08:46 PM
07-10-2013 08:46 PM
Hi,I've had a bit of a search and not found even a mention of this
anywhere - nevermind even someone...
Public Statistics
| Date Registered | 02-03-2011 11:36 PM |
| Date Last Visited | 09-21-2018 06:53 AM |
| Total Messages Posted | 117 |
| Total Helpful Votes Received | 41 |
Helpful Votes Given To
| User | Helpful Count |
|---|---|
| 5 | |
| 5 | |
| 5 | |
| 5 | |
| 5 |
Helpful Votes From
| User | Helpful Count |
|---|---|
| 2 | |
| 5 | |
| 5 | |
| 5 | |
| 5 |
