Just found the emails with the SQL commands, not all that clear looking back at them but did fix the issue -
From the CLI on both boxes, can we run these commands to check out which users exist in each database:
run sql select * from enduser where userid = 'coles'
Then with the output of the CUCM details, we should search on possible 'unique field' matches on the CUPS server to find the duplicate entry.
The unique field can be the PKID, userID, and sometimes mailid and ocsprimaryuseraddress.
If you send me over the output I can prepare some more commands - or if you're comfortable doing it yourself, we'll see something like this from the CUCM:
admin:run sql select * from enduser where userid = 'emtest'
pkid assocpc firstname middlename
lastname userid manager department telephonenumber tkuserlocale mailid status facsimiletelephonenumber mobile pager homephone title building site fkdirectorypluginconfig uniqueidentifier nickname deletedtimestamp
passwordreverse fkmatrix_presence tkuserprofile
fkcallingsearchspace_restrict allowcticontrolflag enablemobilevoice maxdeskpickupwaittime enablemobility remotedestinationlimit ocsprimaryuseraddress
50845cc0-6ffe-6e23-47d6-bda10240dd66 test
emtest NULL 1
NULL emtest@vnglab.local NULL
ad243d17-98b4-4118-8feb-5ff2e1b781ac 1 NULL
t f 10000 f
4
So:
PKID 50845cc0-6ffe-6e23-47d6-bda10240dd66
userID emtest
mailid emtest@vnglab.local
ocsprimaryuseraddress 4
We can then check out the CUPS database using these fields and see what's returned, so we use the commands:
run sql select * from enduser where PKID = '50845cc0-6ffe-6e23-47d6-bda10240dd66'
run sql select * from enduser where mailid = 'emtest@vnglab.local'
run sql select * from enduser where ocsprimaryuseraddress = '4'
And see if we come back with an entry. This could be our offending entry.
If we find this, we can delete via root and sync again.
The PKID should stay the same throughout here. So we have an old, orphaned entry that should be deleted on the CUPS server, then the sync should work.
As for the cause, it's my suspicion that during a sync or integration with LDAP, the user was deleted/recreated, with a new PKID and this didn't sync properly with CUPS.
Also we can be sure that there's no issue with the CUCM database because the query:
admin:run sql select * from enduser where userid = 'owens'
comes back only once.
So we should delete this entry from CUPS. We can use SQL for this:
run sql delete from enduser where pkid = '90c4a576-d9ba-eb39-767c-5ff3cc035c55'
But if this fails with a 403 error because of LDAP integration, we need to get root access.
So in the case of an error, please also provide remote support details:
admin:utils remote_account enable
admin:utils remote_account create ciscotac 30
We don't need root if the SQL DELETE statement works.
