<div dir="ltr">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.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 4:41 PM, Justin Steinberg <span dir="ltr"><<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, May 3, 2016 at 3:04 PM, Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">This is related to my post I just made on UCCX and LDAP via CUCM.<div><br></div><div>I also just found out that a CUCM with an already synced user database behaves in the following two ways:</div><div><ol><li>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<br><br>You will see this in the DirSync log<br><font face="monospace, monospace">Dirsync synched zero users. Please verify the custom LDAP filter configured for this agreement</font><br><br></li><li>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.<br><br>You will see this in the DirSync log (the value 1660 will vary by scenario)<br><font face="monospace, monospace">DSDBInterface.setUserInactive Found 1660 users in database needing update</font><br></li></ol><div><font face="arial, helvetica, sans-serif">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?</font></div></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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).</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">What do you think?  Have you seen this before?  Has it bit you?  Am I missing something obvious?  Let me know.  Thanks.</font></div></div>
<br></div></div>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ed Leatherman<br></div>
</div>