I have seen similar failures when accessing the 7.1(x) upgrade files via SFTP. One thing I have tried and had success with is to ensure that the the file you are accessing is in a dedicated folder path with no other upgrade files in it...ask me why this works and I can't tell you but it's certainly worth a try. So, put the file in a folder such as:
With only the specific 7.1(3) upgrade file in this path, attempt to download the upgrade file again by starting the installation process.
Just to clarify - Do you mean only have 1 file in the directory where your SFTP server points to, so when you run the upgrade via Call Manager OS Administration web page, it only finds one file. Or do you mean ensure that only one file exists in the CUCM repository on the call manager where the uploaded file is copied to?
If it is the later, where are these files located?
The first...make sure only one file exists in the SFTP server directory that you point CUCM to for upgrade files via the OS administration page. Again, can't give you a great explanation as to why but when I've issues like this in the past I found that only having 1 file available to download via SFTP clears up the issue.
This indicates a problem loading your data from your existing version to the new version.
The DB logs are helpfully spread accross several locations. Best way to pull them is to run RTMT, and do a collect files twice:
1) Files from the publisher, for the 'Install and Upgrade Logs' and 'DB Logs' - do this for the time period covering the upgrade attempt, and specify the 'active' partition.
2) Repeat that for the same set of logs from the 'Inactive' partition.
One of the files from this second set of logs will be called 'something-or-other.err' - it contains any errors encountered when running the data transfer. This should clue you in to where the problem is, or at least what times to be looking at in the other logs. Normally the useful stuff is in this inactive partition log set...
Please rate helpful posts..
Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
Well - I've previously seen issues like this where a recording solution vendor had been on a 5.x system, and added a group called 'Standard Call Recording' or something. When we did an upgrade to 6.x, which introduces a group called 'Standard Call Recording'... well, it was very unhappy. Renamed the group we had on 5.x, and the upgrade went OK.
In your case, I'm guessing that the unique key being violoated is the 496 value - if Cisco have added a new row to this table, it may be using that ID. The other unique field in this table is the 'moniker' field, but as I've never heard of your custom device I'm guessing that is unique.
You may see earlier in the other DB install logs from the inactive partition that a row is inserted to that table with this ID; not sure if that level of detail will be shown, but I think it is. Try searching the files for the 496 value.
I would suggest that you look at changing that; however it's likely that as this is a 'type' table you will have other devices in the DB that refer to this value directly - e.g. other tables will have a column named tklicenseunit, which will refer to this table. You'll need to search the db definition for your version of CCM to find what those tables are, and update those as well.
A quick scan of the docs suggests these will include:
I guess you have developers on board, so you may want to back this off to them.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...