Just ran into this same issue with CUCM 10.5.2 and discovered that RDP's were being left in the database, connected to an end user but not appearing in the CUCM web administration page.  If you have this issue, you could try the following to see if it corrects the problem: - Log into the CUCM CLI and issue the following query: run sql SELECT d.pkid, d.name FROM device d INNER JOIN enduser eu on d.fkenduser_mobility = eu.pkid WHERE eu.userid = "YourUserID" AND d.tkmodel = 134 - Locate the 'extra' RDP pkid's from SQL output. - Navigate to the CCMAdmin RDP pages (Device->Device Settings->Remote Destination Profiles) and search for the RDP that you want to keep . - Click the RDP to enter the device details page - In the URL bar, replace the 'key' value for the RDP (it's database pkid) with one of the 'extra' RDP pkid's.  The address will look something like this: https://10.1.10.1/ccmadmin/gendeviceEdit.do?key=1462fefe-6e43-421d-9d7e-9cbca5dd3af1 - Once the value is replaced, press enter and be taken to the details page for the 'extra' RDP.  At this point you can delete the extra RDP (I just moved mine to another user while I investigate further) Replace each key= value for every extra RDP assigned to the user.  I only had one extra.  The extra RDP did not show up when searching the Remote Destination Profile menu and was not listed as an RDP under the user profile. I'm using the following query to find out which end users have multiple Remote Destination Profiles to see if there are any other issues.  Here is the query: run sql SELECT eu.userid, count(*) FROM device d INNER JOIN enduser eu ON d.fkenduser_mobility = eu.pkid WHERE d.tkmodel = 134 GROUP BY eu.userid HAVING count(*) > 1 Marty ... View more

Thuy, Thank you for the assistance.  I've done a little more troubleshooting and have discovered a little 'quirk' in this API. We're preparing to move our clusters to a 'Location and Link Management Cluster' Inter-Cluster ELCAC design with SME and need to update a few hundred location relationships, mainly with Hub_None.  What I've discovered is that when using the API and passing in the empty <betweenLocations/> tag, it only produces updates based on a 'forward' lookup of the locationmatrix table.  For instance: Given location123 and location789 in the locationmatrix table as fklocation_a = location123 and fklocation_b = location789, if I call updateLocation on location789 with an empty <betweenLocations/> tag, the relationship will persist because the API updates the relationship only from location_a to location_b ('forward') and not in 'reverse'.  So, the locations I was trying to update were most likely assigned from the Hub_None page, with Hub_None as fklocation_a and so the update were not applied.  FWIW, here's the API call that does work when making an update in the 'forward' direction. <ns1:updateLocation>   <name>location123</name>   <withinAudioBandwidth>0</withinAudioBandwidth>   <withinVideoBandwidth>0</withinVideoBandwidth>   <withinImmersiveKbits>0</withinImmersiveKbits>   <betweenLocations/> </ns1:updateLocation> I wonder if this was intentional or a glitch, since you can update the relationship from either side in the GUI? Marty ... View more

Thanks.  Got me running with Perl and 10.5 ... View more