We just ran into the behavior with some agent username changes last week, and it was not even LDAP related - the technician was just trying to be helpful and update some local end user id's for consistency and didn't think that change needed any pre-testing. When he noticed it, he changed all the names back but their skills such were still cleared out. Luckily it was a small number of accounts and we were able to get skills re-assigned quickly, but I think it will still have a minor impact on the agent reporting.
On Tue, May 3, 2016 at 4:41 PM, Justin Steinberg <[email protected]> wrote: > CUCM doesn't delete the users when they are marked inactive. you can fix > the LDAP agreement, resync and get them back if you get it fixed before the > garbage cycle clears them out. > > this is really an issue for the UCCX team, they should handle user changes > in CUCM more gracefully. This is also the case for situations where the > username changes. If the account changes in the LDAP directory, CUCM will > usually see the change and update the username. however, UCCX doesn't > track the same way and will delete the agent's old account and create a new > account for the new username. the new UCCX account will have no skills, no > team, no associated historical data, etc. I haven't tested this with > UCCX 11, but this is how it has been on UCCX when I last tested it. > > On Tue, May 3, 2016 at 3:04 PM, Anthony Holloway < > [email protected]> wrote: > >> This is related to my post I just made on UCCX and LDAP via CUCM. >> >> I also just found out that a CUCM with an already synced user database >> behaves in the following two ways: >> >> 1. If you modify the filter such that it matches 0 records, the sync >> doesn't happen at all. No users are marked as Inactive, no users are >> pulled in, and no users are updated >> >> You will see this in the DirSync log >> Dirsync synched zero users. Please verify the custom LDAP filter >> configured for this agreement >> >> 2. However, if you modify the filter such that it matches a single >> record, the sync does happen. All of the non-matched users will become >> Inactive. >> >> You will see this in the DirSync log (the value 1660 will vary by >> scenario) >> DSDBInterface.setUserInactive Found 1660 users in database needing >> update >> >> For #1, it seems like this might be a protection mechanism, preventing >> you from destroying your entire corporate directory. Because, recall that >> EM, Jabber, Finesse, etc., all require your account to be Active Synced in >> order to authenticate you; therefore, making 1660 people go Inactive will >> have a large impact. Or perhaps it was a coding error, and they should >> have made all users go Inactive? >> >> For #2, if we're thinking #1 could be a protective mode, then wouldn't >> 100% user loss be just as bad as 99%? Perhaps the protection mechanism >> should look for a smaller percentage drop in Active users and prohibit an >> LDAP update at that time and display a warning on the page (I.e., Like the >> last known good backup now shows up on the About page). >> >> What do you think? Have you seen this before? Has it bit you? Am I >> missing something obvious? Let me know. Thanks. >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > -- Ed Leatherman
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
