Ldap imported User deleted via CiscoUnityDb cannot be re-imported

[thomasleguen]

Hello,

We're deleting users using the csp_subscriberdelete stored procedure sent via soap to CiscoUnityDb

Given a user that has been imported from: Import Users > select LDAP server > list users, select and click import

If I delete it from Unity, the user will automatically reappear in the Import User from the LDAP list

If I delete it via SOAP, the user is deleted from Unity but it does not reappear in the list. No matter if I try a full sync and wait.

We're still investigating the issue, but I'm asking here in case we missed something.

Thank you !

[Elliot Dierksen]

That is quite odd. Have you looked at the logs from the LDAP sync process? FWIW, my process was always to convert an LDAP user to a local account and then delete the local account. That has worked for a long time. I am sure that was the result of a problem I was having, but I don't remember what that problem was.

[thomasleguen]

Thank you for your response @Elliot Dierksen , I'll dig into that

I'll keep you posted in case I find anything interesting.

[thomasleguen]

Hello again, after some investigation, I found out that using the stored procedure to delete users only cleans Cisco Unity DirDb.

I couldn't log db actions from Cisco Unity UI but using CUPI, I found out that changing LDAP integration type triggers an additional Delete on Cisco Unity "hidden" database (accessible via CLI using "run sql" queries).

10:50:07.809 |31430,,,VMREST,3,DEBUG [http-nio-1027-exec-7] com.cisco.connection.rest.RequestFilter - REQUEST PUT users/3cb49695-ce9d-41ff-8777-b3530f953b0d
[...]
10:50:07.848 |31430,,,VMREST,3,DEBUG [http-nio-1027-exec-7] com.cisco.connection.rest.impl.ext.UserRestImplExtension - LdapIntegrationStatus changed

10:50:07.884 |31430,,,CuService,16,DEBUG [http-nio-1027-exec-7] com.cisco.unity.bo.Dbl2CCMIntegrationBO - Delete EndUser Association: DELETE FROM EndUserAppServerMap WHERE fkappserver='77d23446-ca52-48ed-ae86-0d30a89d5600' AND content='3cb49695-ce9d-41ff-8777-b3530f953b0d'

On the enduser table in the same database, I found out that the users that cannot be imported again still existed.

And on the EndUserAppServerMap, there were still rows linking to those users.

I could run the delete query based on the enduserfk (= enduser.pkid) and my user could now be imported again via LDAP from Unity.

This is a way out, but cumbersome and kind of hard to scale (beside building a SQL query based on a diff between ldap export and a Bulk Administration Tool export of LDAP users)

Has anyone heard of something more accessible to clean this database ?

I tried deleting the configuration, recreating it, and several other combination of enabling/disabling users from Unity or LDAP and sync processes.

[Elliot Dierksen]

I don't know if this is exactly what you are asking for, but I have a query that locates accounts that were defined as LDAP integrated in Unity, but are no longer active in LDAP.

run cuc dbquery unitydirdb select alias, dtmfaccessid, ldaptype, ldapccmuserid from vw_user where ldaptype = '0' AND LDAPCCMUserId IS NOT NULL

[Maren Mahoney]

@Elliot Dierksen - I cannot tell you how helpful that query is in my current customer environment! Thank you! -- Maren

[thomasleguen]

Thank you for your feedback, not quite, it's actually the reverse: finding users that unity thinks are managed from LDAP but are not really in unity anymore.

My use case is based on using the old SOAP Cisco Unity API to call stored procedures on Cisco Unity DirDb.

Unity keeps a trace of the users managed by LDAP in a hidden table (EndUserAppServerMap). This table is not cleaned up after operation from SOAP API but it is after UI operation or REST API operation.