Have CUCM 7.1(3), configured to sync with Microsoft AD (2003)
When we first configued the LDAP sync, CUCM was able to pull in all the existing users in our OU's.
We recently added a new OU with a couple of users, gave the LDAP user "read-only" rights to the new OU (same as existing OU's), and set up the LDAP sync in CUCM.
We've run the "Full Sync Now" several times, which completes quickly, (we've waited for hours to make sure the process completed, only 90 users) and none of the "new" users are being pulled into CUCM.
We've also added some new users in existing OU's, those also are not being pulled into CUCM.
If we update information for existing users in AD, the information gets updated in CUCM, so the sync is working for existing users, but no new users are being imported.
I've stopped and started the DirSync process, that didn't help.
Any one have further suggestions?
this 1st thing I would check are the logfiles, use rtmt, or ssh to the server and list the files;
file list activelog cm/trace/dirsync/log4j/ det date
then you could tail the newest file, i.e.;
file tail activelog cm/trace/dirsync/log4j/dirsync00001.log
and perform a full sync while you watch the logfile you are following and look for errors
Have the same issue, and am stuck here
16 Jan,2017 21:51:33 64,762 dirsync00007.log
dir count = 0, file count = 20
admin:file tail activelog cm/trace/dirsync/log4j/dirsync00007.log
2017-01-16 21:51:33,056 ERROR [DSLDAPSyncImpl(a497380d-8b55-e169-ae40-e6efb19bf000)] ldapplugable.DSLDAPSyncImpl (DSLDAPSyncImpl.java:407) - LDAPSync(a497380d-8b55-e169-ae40-e6efb19bf000)[Run] com.cisco.ccm.dir.dirsync.common.DSException
2017-01-16 21:51:33,057 INFO [DSLDAPSyncImpl(a497380d-8b55-e169-ae40-e6efb19bf000)] ldapplugable.DSLDAPSyncImpl (DSLDAPSyncImpl.java:682) - LDAPSync(a497380d-8b55-e169-ae40-e6efb19bf000)[Run] Exit LDAPSync for agreement=a497380d-8b55-e169-ae40-e6efb19bf000
2017-01-16 21:51:33,165 INFO [Thread-7] common.DSNcsClient (DSNcsClient.java:54) - DSNcsClient.process xml=<msg><type>DBL</type><table>directorypluginconfig</table><tableid>101</tableid><action>U</action><time>1484603493</time><old><cdrserver>2</cdrserver><cdrtime>1484603468</cdrtime><pkid>a497380d-8b55-e169-ae40-e6efb19bf000</pkid><agreementstatus>1</agreementstatus><ldapdn>firstname.lastname@example.org</ldapdn><ldappassword>c3f95341d6b42836d2700325d1310120411439e06cc54cc6fdd27c8eb8212639</ldappassword><ldapsynchronizationbase>DC=EU,DC=AD,DC=SULTREX,DC=COM</ldapsynchronizationbase><incsyncstatus>0</incsyncstatus><highestcommittedusn>1005298618</highestcommittedusn><syncnow>0</syncnow><invocationid>a4c44bfcbc57f541bba0267fe51e5e34</invocationid><fullsyncstatus>1</fullsyncstatus><connectedldaphost>10.112.43.103</connectedldaphost><name>Sultrex Europe Users</name><fkldapfilter>fe1d84fb-0810-3ba9-c2f6-c14b94067a73</fkldapfilter><ifx_replcheck>6376323342588316649</ifx_replcheck></old><new><fullsyncstatus>-1</fullsyncstatus></new></msg>
2017-01-16 21:51:33,166 INFO [Thread-7] common.DSNcsClient (DSNcsClient.java:61) - DSNcsClient.process Process CN on directorypluginconfig with action=u
When you set up LDAP, you have to define the search base.
When you did set up the new OU, is the new OU reachable via the search base path provided when you set up LDAP integration? If not, you may need to move your search base setup so that it is. .
I guess I'd start by taking the search base info and copying it into notepad.
Then use the ADExplorer tool (it's a free tool you can download for Windows) to get the fully qualified name for the OU and make sure that it really is under the search base.
If it is, then you'll need to get a TAC case open to go deeper on this one. If not, you should be able to correct it yourself.
NOTICE OF CONFIDENTIALITY:
The information contained in this email transmission is confidential information which may contain information that is legally privileged and prohibited from disclosure under applicable law or by contractual agreement. The information is intended solely for the use of the individual or entity named above.
If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking of any action in reliance on the contents of this email transmission is strictly prohibited.
If you have received this email transmission in error, please notify us immediately by telephone to arrange for the return of the original transmission to us.
I think we have resolved this.
It turns out the AD admin didn't configure Last Names for the newly added users. Once we configured Last Names in AD, the users sync'd....so Last Names are required.
Thanks for all suggestions.