till wouldn’t help though.
>
>
>
> It’s a drag. ☹
>
>
>
> But I’m still not defeated!
>
>
>
> From: Hunter Fuller
> Sent: Thursday, January 30, 2020 6:26 PM
> To: Lelio Fulgenzi
> Cc: Charles Goldsmith ; voyp list, cisco-voip
> (cisco-voip@puck.neth
voip
(cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything
else other than SN=* (non-empty) ?
Using the ipPhone field is an option. However, it’s a bit of a chicken and egg
thing. They don’t have an extension until we assign it. And we can’t im
-voip] CUCM requirements for AD account import - anything
else other than SN=* (non-empty) ?
On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi
mailto:le...@uoguelph.ca>> wrote:
We can’t filter on anything telephone number based. Sounds silly, but the
information in the directory doesn’t alway
On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi wrote:
> We can’t filter on anything telephone number based. Sounds silly, but the
> information in the directory doesn’t always jive with what someone wants,
> extension wise.
>
This was true for us. Our solution was to populate the ipPhone field
test unity server, which _was_ complaining.
From: Charles Goldsmith
Sent: Thursday, January 30, 2020 5:41 PM
To: Lelio Fulgenzi
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything
else other than SN=* (non-e
This is what I recommend to customers, users, not pc's and the ipPhone
field is populated.
(&(objectclass=user)(!(objectclass=Computer))(ipPhone=*))
On Thu, Jan 30, 2020 at 3:34 PM Lelio Fulgenzi wrote:
>
> OK - I'm trying to reconcile accounts being imported into CUCM before I
> modify the
: Thursday, January 30, 2020 5:08 PM
To: Lelio Fulgenzi
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything
else other than SN=* (non-empty) ?
I think you understand it correctly. Unless we're both wrong.
Are you
I think you understand it correctly. Unless we're both wrong.
Are you using the same filter in both CUCM as the LDAP browser (can you
share it?)? Same search base? Same user to BIND with? Same AD or GC
server? Same Port? Same TLS setting?
Do you know which user account is the anomaly?
On
OK - I'm trying to reconcile accounts being imported into CUCM before I modify
the filter we're using.
I've used the base filter suggested, plus I've added the (sn=*) to ensure we
get only accounts with non-empty last names.
However, my reconciliation is off by 1 (including taking into
