cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2676
Views
35
Helpful
12
Replies

UCCX Users Deleted during a CUCM LDAP Change

m.dibben
Level 1
Level 1

Hi All,

I'm hoping someone can help here.

I recently migrated a CUCM cluster from an AD connection with multiple forests, to a single AD-LDS server as I needed to enable authentication.  This mostly went ok but during testing, I found that the users in my UCCX server had been deleted and then re-added meaning that they had all lost their configuration, Skills, Teams etc.  We were able to rectify the situation quite quickly but I'm unsure why this happened and if it had been a more complex solution, we could have been in more trouble.

 

The process I followed was this:

- Delete the multiple LDAP Directory entries to the old AD servers, which is mandatory to change the LDAP System type. (at this point users became inactive in CUCM)

- Change the LDAP System from Microsoft Active Directory to Microsoft ADAM or LDS

- Add the new directory pointing to the AD-LDS servers

- Run a manual Sync to activate all users again

 

This took no more than 5 minutes and in that time the users in CUCM became inactive then active again (as expected) but the UCCX users were deleted and re-added (without their skills configuration).

 

If anyone knows why this happened I would appreciate your input.

 

Cheers

Martin

12 Replies 12

cnuche
Cisco Employee
Cisco Employee

Hi,

 

This is actually expected.

 

Christian.

@cnuche 

Hello Christian,

That behavior is written in an official document of cisco?

I'm looking for an official document from cisco about the relationship between UCCX and the cucm LDAP directory.

Do know have one?

 

Thanks

 

Its the inactive piece that removes them from UCCX. As soon as an account becomes inactive, it removes any app sync in place. I am not sure if there is a way to disable CUCM sync to the UCCX server while you made this change, but even that might not work.

From my testing, you simply do not load the RmCm page, but now with APIs around, I'd imagine any action which causes UCCX to load a list of Agents is going to cause this to happen. Therefore, you might want to stop Tomcat on UCCX while you have an LDAP outage on CUCM. Yes, it will impact UCCX and Agents, but it's probably better than spending the next 4-6 hours rebuilding and restoring the whole of UCCX from a backup.

Hi,

 

I opened this documentation enhancement request some time ago to track this down:

 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvm22621

 

HTH

Please rate if helpful

 

Christian Nuche,

Designated Service Manager.

Cisco Systems.

 

 

This is such a vulnerable condition to be left with & I'm surprised Cisco decided to do things this way around.

I was recently involved in a high-severity case where the LDAP structure in the environment we manage had an outage &, as "luck" would have it, CUCM had a scheduled synch. shortly after the LDAP servers went unavailable.

We had about 17K users marked as "Disabled" in CUCM (which isn't so bad if the condition is remediated and new synch triggered) and around 250 were UCCX agents which simply got completely removed from UCCX because of this thing.

Would it not make more sense to have UCCX trigger a countdown like CUCM does?

Instead of purging those agent profiles immediately from the CCX database, keep them lingering for at least 24 hours?

I was baffled when I read that bug bulletin; imagine trying to explain that to the business you're looking after when they pay top money for what should be one of the best on-prem. contact center solutions out there.

That's how UCCX used to work. Then it changed to this immediate deletion method.

Anthony Holloway
Cisco Employee
Cisco Employee
I wrote about this 4 years ago. It also bit me and I had to rebuild UCCX from a DRS backup in the middle of the day.

https://cisco-voip.markmail.org/search/?q=holloway%20uccx%20ldap#query:holloway%20uccx%20ldap+page:1+mid:4hprlnnjkrky7o74+state:results

UCCX used to just hold the Agents as Inactive, allowing you to restore the user latter, or manually purge them yourself. I'm not sure why they chose to change the behavior, but it's worse now in my opinion.

This one hit me hard smack in the middle of the day for the customer I look after / almost midnight where I live. 

Had to pull an "all nighter" to restore a very sensitive CCX cluster do to a hiccup that was out of our control :| 

Talk about the 13th lol

davisjaron
Level 1
Level 1

Just from my experience, this is actually why it's not suggested to use a CUCM LDAP account as the end user for UCCX.  A local account is less likely to be deleted by accident.

What you're saying works in smaller environments but when you deal with multiple users that *must* have a unified user/pass to access a slew of enterprise apps. this is going to get you nowhere fast.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: