On-Screen Directory

[Jonathan Beardsley]

Does anyone know where the on-screen directory pulls from in CUCM 8.6? Some of the newer extensions I've setup are not showing in the on-screen directory.

I have no clue why anyone is using this feature, given the other much easier ways to call people......but they are.

[Rob Huffman]

Hi Jonathan,

If you using the local directory (not ldap) go to;

User managment > End User > Add

Cheers!

Rob

[Jonathan Beardsley]

Thanks Rob!

I'm syncing with LDAP. We did just make a lot of changes in LDAP for a signature manager, but the existing users still show up in the corporate directory.

Since I'm syncing with LDAP, all my users are already setup in User Management -> End Users. I associate each end user with a phone and permissions groups, naturally.

....and yay, my sub cpu is pegging! woohoo.....

[William Bell · Accepted solution]

Subscriber CPU peg isn't fun. Though, I don't think it is related to LDAP sync. Though, the Informix db will replicate after the publisher refreshes the user list via DirSync. So, there would be an increase in processing during that sync interval. Though, it shouldn't be too heavy nor should it last an extended period of time.

I am guessing you got the answer you were looking for, but just in case. "On Screen" could mean CCMUser portal, webdialer, or the corporate directory XML app on the phone.  In all cases, the information comes from the "enduser" table in the Informix DB. This table (and those it is linked with) are the same tables that present data to the "User Management>End User" UI.

The fact you are synchronizing with LDAP is transparent to all of these UIs. The DirSync process pulls data, it gets written into the "enduser" table and then DBLHelper does its thing to trigger realtime and non-realtime sync of the data. In Corporate Directory (and the CCMUser directory/web dialer UIs) the phone number that people see is actually the telephonenumber attribute of the user object as it is stored in the enduser table. It is not the extension programmed on a physical (or software) device.

Since you are LDAP enabled, the telephoneNumber attribute in CUCM comes from the LDAP attribute you have mapped to it. So, in AD you can use telephoneNumber or ipPhone (for example). So, if your phone number info is wrong or missing then you need to look at the LDAP object for the user(s). If the issue is systemic and you have validated the LDAP object then take a look at the LDAP sync config in CUCM, paying particular attention to the attribute mapping.

If you still don't ID the source of the issue, then you need to take a look at syslog (or local app logs) and do some tracing on the DirSync process.

HTH.

Regards,
Bill

[Jonathan Beardsley]

No, the CPU pegging is a different problem all together.....CUCM 8.6 running on old H3 servers......

Thanks for your detailed response. Very helpful. Yes, the LDAP object was the first thing I checked. I'll check on my LDAP sync config.

Thanks,

Jonathan

Taking my CCNA Exam tomorrow....been very afraid of this for years.

[Jonathan Beardsley]

Ok, so the problem was that my LDAP was set to sync every 6 days and the Next Re-sync Time (YYYY-MM-DD hh:mm) was a date in the past. Since it is a required field I just changed it to a date in the future. How can I prevent this from happening after Nov 30, as this is the newly set date. Is this date supposed to change when it does the auto sync on Nov 30? (See current setttings below)

Thanks!

Jonathan