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.
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
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.
How to complete the RMA order.
How to complete the RMA order initiated by Cisco TAC engineer.
Once the RMA is initiated by the TAC engineer.
Customer will receive an email with the link to complete the order.
Click on the link provided i...
How to complete the RMA order.
Introduction to Essential Utility for Optical Network Professionals
This utility will serve as ready-made handy calculator/c...
There are few interoperability issues between 2960x and other vendors. In this article we will go over the steps on how to debug these issues.
Check the phy id from “show controllers ethernet-controller phy” output.
<snip from show controllers ethe...