Re: [cisco-voip] LDAP, Sync, Filters and CUCM

[Ed Leatherman]

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 
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 <
> avholloway+cisco-v...@gmail.com> 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
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
Ed Leatherman
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] LDAP, Sync, Filters and CUCM

[Justin Steinberg]

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 <
avholloway+cisco-v...@gmail.com> 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
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] LDAP, Sync, Filters and CUCM

[Anthony Holloway]

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
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip