User Profile marked Inactive continues retaining its DID and extension

[Dave_Jr]

Good Afternoon Cisco Community!

My client is running into an issue where an Inactive User in Webex Control Hub has retained ownership over a DID and an extension. I find that I am unable to re-assign neither the DID nor the extension at this time to its new owner.

We use Directory Sync to run user synchronizations from AD to Control Hub.

Has anyone found a way to open the DID and extension from an Inactive user so it can be assigned to another user? The device to which the DID and extension were attached have since been deleted, and the inactive user currently holds no existing licensing to allow for ownership of any number. However, no such device/workspace sharing the user's name currently exists, so it would appear the number is still believed to be attached to a user that no longer is active.

One attempt to remediate this issue was to make the user active again and assign a new license with a new number (to see if I could force an override over the previous setup), but upon saving the changes, it has no affect. In fact, the user's profile still acts as if no licensing is activated on their account.

Any thoughts on the matter would be greatly appreciated. I am opening a TAC case in the meantime and will relay what I learn from them here.

Thank you in advance.

[Dave_Jr]

I heard back from Cisco on this issue. They informed that after reviewing all available logs, it is not clear why this issue occurred in the first place. Since they have resolved the issue, however, this has not re-occurred. What I will say to those who read this article in the future is to remove the number from a user before making them Inactive.

It is entirely possible that this issue will not re-occur, however I recommend a change in the order of the off-boarding process to better ensure that a number is available for re-assignment.

I hope this article provides a form of assistance to anyone who may experience this issue Thank you for your time.

[Dave_Jr]

Good Morning @TechLvr, thank you for your update! It's all good, I would not have known that if TAC had not shown that to me previously. I appreciate your response.

[TechLvr]

@Dave_Jr When using Directory Connector, deleted/disabled users in AD continue to show inactive in the Control Hub for 7 days after which the system deletes them permanently. During these 7 days, the inactive users hold onto any assigned numbers/licenses, rendering them unusable for that time period. However, there is a way to delete inactive users immediately without waiting for 7 days. See steps below. 

From the Directory Connector, perform a Sync Dry Run. Once the Dry Run is completed, check the box next to each soft-deleted (meaning inactive) user, and click done. Next, run an Incremental Synchronization. After the sync job is finished, the selected inactive users should disappear from the Control Hub, and you can reassign the released numbers/licenses. 

Edit: Sorry. I missed one of your responses iwhere you mentioned you already tried these steps without success. But glad you found a different solution with TAC. 

[Dave_Jr · Accepted solution]

Hi Cisco Community! It is day 3 of the TAC case, and Cisco engineering has officially resolved the issue. It appears they went in behind the scenes and updated a database entry. Although without further confirmation, that is speculation on my side. The issue was actually resolved yesterday evening, however I wanted to hold off on a reply until they had time to provide a final verdict on the cause of the issue. Cisco TAC informed that the engineering team is still running root cause analysis on their end to understand what initiated the problem in the first place. They were interested primarily in the time that the Inactive user was fully deleted from the system.

Cisco TAC informed that if they are able to get the resolution info from Cisco engineering once it has been investigated further, they will let me know.

If I have not received word from Cisco by October 3, 2022, I will close out this post.

Thank you for your time.

EDIT on 10/04/22:
See my final post below. Cisco did not find a root cause for why this issue occurred, but I recommend a change in the order of operations to ensure that if a user entry does get locked up, it does not affect the re-assignment of a number.

[Dave_Jr]

I have an ongoing case with TAC to identify the root cause of the issue, but I do have some more information to provide.

TAC provided a method (for tenants that utilize Cisco Directory Connector) by which we could remove the user's entry early from the normal 7 day "soft delete" period by which an Inactive user is removed from the system. This requires Cisco Directory Connector to be at a minimum version of 3.7.3000. The latest software version (currently 3.7.5000) can be downloaded from Control Hub's Organization Settings and the setup file can be used as a method to update existing software if the "new update is available" button doesn't work for your server). From Cisco Directory Connector, during a Dry Run, a user can be marked for deletion so long as they are no longer able to sync with the Webex tenant (i.e. they no longer meet all of the criteria set in the Directory Connector's LDAP Filter). If a user is no longer meeting said criteria, they will be placed into the Soft-deleted Objects section in the Dry Run.

From there, check the box to mark them for early deletion. Directory Connector may ask for another dry run to queue up the deletion. Run that second dry run, and afterwards run a sync to Webex.

I will attach TAC's screenshot below to display where the Soft-deleted Objects section appears.

---

End result: The user was in fact deleted early and removed from the Control Hub Users section, however this did not effect the database in any meaningful way to open the DID and extension. Control Hub still acts as if the now-removed user is in ownership of the numbers.

Cisco informed this will likely involve Broadcloud and other Webex Calling Service Teams. I will continue to post as I hear more from TAC.