I wanted to create a new call control group, but unfortunately the network connection was lost and after login to appadmin again I have some strange CCGs configured with the same IDs.
Anybody who can tell me the the command to delete the CCG and all associations via sql CLI. It's a lab environment and I have no service contract for TAC... :-(
You can run the Data resync (UCCX Admin->Subsystem->CM Telephony->Data Resync), and can select any specific CCG which you feel are not in good shape.
I referred the CLI guide (link given below), but didn't figure out any commands regarding CCG.
Hope it helps,
Please rate helpful posts, by clicking on the stars below the right answer !!
already tried to resync, said everything is ok. The ports were even recreated on CUCM, but I cannot use or edit them as they have duplicate IDs, see:
So I think the only way is to delete them directly via sql?!
You are hitting the below defect.
UCCX has multiple CCGs with same ID resulting in CCG becoming unusable
The above defect also gives reference to another defect -CSCtw80577- with the same issue.
Fixed in UCCX 8.5.1SU3.
As yours is a lab environment, request you to please delete all the CCG's which have duplicate ID's and recrete the new ones and also upgrade to UCCX 8.5.1SU3, so that you wont hit this again.
Hope it helps,
Please rate helpful posts !!
my problem is that I can't delete them, received an error on appadmin because of duplicate IDs.
btw it wasn't a real defect, it's because my network connection and browser sessoin was broken... ;-)
By any chance o you have a valid backup (without this duplicate CCG's) of this UCCX system, if so try restoring it.
...just have a look into db schema guide and I can see the same result on CLI as well:
admin:run uccx sql db_cra select recordid,grouptype,groupid from crsgroup where active = 't' and grouptype = 'Cisco CTI Port'
RECORDID GROUPTYPE GROUPID
6 Cisco CTI Port 1
22 Cisco CTI Port 1
24 Cisco CTI Port 2
25 Cisco CTI Port 2
28 Cisco CTI Port 0
Would it help to set the duplicates to inactive? As far as I know there are no sql updates allowed?!
indeed, no SQL updates are allowed, unfortunately (unless you are an Informix SQL guru and find out the way how to use a SELECT statement to update rows).
Have you tried
utils uccx database dbserver integrity
"Completed DB config integrity check no errors were found"
Any other ideas or maybe there is that informix guru out there I am locking for?! ;-)
Unfortunaltey there is no backup of the system, was working this week on a fresh install for new customer showcase... :-(
Please try the below tip,
select * from configseed;
//see whetehr there are duplicates
if yes u can delete one of them
delete the one with lesser configsed value
or one of them if both are same
you can unload to a txt file
delete it and load it back
or u can delete using the query
if u se query both will get deleted
so unload and lod it back
dbaccess db_cra -
unload to configseed.csv delimiter ',' select * from configseed;
delete it manually by opening the csv file
after that load it back using
load from configseed.csv delimiter ',' insert into configseed;
Note: For this you need to have root access.
Hope it helps,
Please rate helpful posts !!
unfortunately I don't have root access without TAC...
(even the well known jailbreaking method is not workoing with this ucos as the file dump command is restricted ;-))
@G., I have read some Informix communities and I think it might work with "select ... for update of..." but the CLI is restricted to enter the ";" seperator and u always need more than one line... :-S
It seems I have to setup a new system... Any other ideas...?
well, you can go and create a backup, dissect the backup file, do some modifications, but again, I guess it would kill more time than just throw the whole thing away and create a new instance.
yes, G., you're absolutely right. I don't spend really much for that discussion in here and the next step is to setup a new system. Even TAC session would waste to much time for that as I can access the system save my data and reinstall it.
But I was also interested in solving that situation because it might come up at the customers as well and because I am just technically interested in ;-)
I am sorry to say but I do not know of a way to resolve this issue without TAC, already a known. However, I see alot of information that seems a little bit hazy and just wanted to clear this up for you and future viewers of this issue.
When you create a new call control group, the new ID that is used is pulled out of what is called the configseed table. UCCX will get the entry for the call control group entry, add 1 to it, then make that the group ID.
What happens during some upgrades (due to known defects that are being worked on) is the entry in the config seed table gets reset back to 0. This is why you have duplicate IDs starting with 1 and counting up.
One of the workarounds that is applied to customers systems through TAC is to give the duplicate call control groups uniqueue IDs as well as update the configseed table to what it should be depending on the current IDs that exist in the call control group. This way you can make edits to all of the call control groups existing as well as create new call control groups with unique IDs and not have this issue anymore.
I know this doesn't help your situation but I hope this helps you with explaining this to customers as well as your technical interests
ive got same problem on uccx 22.214.171.12402-22. What does it means for me now? I´ve tried to add a new call control group on uccx and it doesn´t work. Ive got now 2 call control groups which each the same ID. How is the solution for this?
I cannot use the new call control groups and also not the old ones. That means the cti ports for old call control groups with the same ID as the new ones are unregistered on cucm. If i try to delete them i get this message Error while performing the operation.Please look into logs for more information.
Please help, many thanks. Can i do something via CLI?!
many thanks in advance,
Please read my above post. Long story short open a TAC case and we should be able to straighten this out for you.
many thanks for quick answering. This is a test system is the no other posibiblity to solve this?! Thanks again.
The only way that I know of fixing this is by manually correcting the configseed table as well as the table that the call control lies in. As im sure you have read above this can only be done by TAC through root.