CSCtr59602 - visible in BTK but not BST

Rob Huffman · ‎03-09-2012

Hello all,

I'm trying to find out the "Customer Reported" info on the above listed bug which

is now available via BST searches, however this bug is shown as hidden via BST;

Information contained within bug ID CSCtr59602 is available only to Cisco employees.

This does not seen right as it is fully visible via BTK and even referenced in this link;

http://www.cisco.com/en/US/products/ps6509/products_tech_note09186a0080b9b100.shtml

A colleague of mine needs this information to judge the occurrence level of this issue

Thanks for all your help here!

Cheers!

Rob

sebberts · ‎03-12-2012

Hi Rob,

This bug is indeed released and should be visible in BST as it is in BTK. There is a bug in BST in which a null value field is being picked up and does not function as expected for specific bugs. This will be fixed with our GA release on April the 6th.

For what type of "Customer Reported" Information are you searching? Let me know and I will see if I can find you some answers.

Cheers,

Susann Ebberts

Rob Huffman · ‎03-12-2012

Hi Susann,

Thanks for getting back to me here at our "new" location

The customer reported information is how many customers have reported this issue to Cisco TAC

as in the example below (in RED);

CSCtn50405 - CUCM DRF Backup does not backup certificates

Description

Symptom:
DRF Backup does not backup certificate(s)
On a bridge upgrade restored server, the ITL file will not have a valid signer. Phones will not have https services if the publisher is the TFTP server. Since phones never had an ITL before this isn't as critical.
On a migration to UCS, or any new hardware where a backup and restore is performed, phones will not accept configuration files and changes from the new cluster without manually deleting the existing ITL from the phones.
When restoring from a disaster recovery situation, phones will no longer recognize their configuration or ITL files after the DRS restore if the restored server was the TFTP server. Phones may not recognize config changes or upgrades until their existing ITL is deleted and replaced with the newly generated ITL.
Conditions:
DRS backup and restore of the node responsible for providing the ITL file via TFTP.
Workaround:
After a disaster recovery or hardware micration situation:
1. Regenerate the CallManager.pem file (only on the restored server) to sync the CallManager.pem file on the file system to the one in the database.
2. Restart TVS and TFTP.
3A. Single node cluster (or only one TFTP server) - Delete the ITL file manually from all phones in the cluster.
3B. Multi node cluster - Phones should automatically use TVS of alternate CallManager Group Servers to authenticate the new ITL file. Alternatively phones could be pointed to another TFTP server in the cluster.
After a bridge upgrade complete the following steps:
1. Regenerate the CallManager.pem file (only on the restored server) to sync the CallManager.pem file on the file system to the one in the database.
2. Restart TVS and TFTP.
3. Phones will need to be reset to download the new ITL file, but should not need to have the ITL file deleted as they never would have had a valid ITL file to download so far.
Further Problem Details
To verify this defect please run "show itl" on the command line of all servers. The servers with this error will show:
This etoken was not used to sign the ITL file.
Verification of the ITL file failed.
Error parsing the ITL file!!
Further verification can be performed by running the SQL query
run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from certificate as c, certificatetrustrolemap as r, typetrustrole as t where c.pkid = r.fkcertificate and t.enum = r.tktrustrole
In the SQL query above, we're looking for the certificates that have a role of "Authentication and Authorization". The CallManager.pem certificate in the database query above that has the role of Authentication and Authorization should ALSO be present in the OS Administration Certificate Management web page. If the defect above is encountered, there will be a mismatch between the CallManager.pem certificates in the query and in the OS web page.

Rate this bug description

(Select Rating)

Current description rating:

(0)

Details

1st Found-in: (1)

8.5(1)

Status:

Fixed

Last Modified:

Mar 06,2012

Fixed-in: (17)

9.0(0.96000.1), 9.0(0.95070.39), 9.0(0.95070.38)

9.0(0.95010.1), 8.6(1.98000.99), 8.6(1.98000.43)

8.6(1.96000.16), 8.6(1.95050.1), 8.6(1.95020.80)

8.6(1.95020.1), 8.6(1.10000.43), 8.6(1.10000.1)

8.6(0.99981.2), 8.6(0.98000.8), 8.6(0.98000.26)

8.6(0.95180.9), 8.5(1.12010.1)

More

Product:

Cisco Unified Communications Manager (CallManager)

Platform:

Dependent

Severity:

1 - catastrophic

Customer Reported: (11)

Cheers!

Rob