You need to signal to oxTrust to refresh all entries. The easiest way to do this is to remove all the snapshots in `/var/ox/identity/cr-snapshots` 1. Stop Cache Refresh 2. Remove snapshots 3. Start CR For your employeeID, adding a custom attribute is supported. Currently the docs are [here](https://gluu.org/docs/ce/admin-guide/oxtrust-ui/#attributes) but we're moving attributes to be its own section in the docs.

Thanks for the response. Just the inum-snapshot*.txt files or the inum_cache.dat and problem-inum-list.txt files as well?

Whack it all. They will be re-created.

Ok, I deleted everything and restarted Cache. After a few refresh cycles, I still don't show the birthdate on accounts. New snapshot files were created, though.

David, Can you please share screenshot for your current "source attribute to destination attribute mapping" from Cache Refresh? and, from logs it looks like CR didn't run successfully because of thi error, hence birthdate was not populated ``` ERROR [pool-2-thread-2] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:623) - Skipping target entries update. Destination server schema doesn't has next attributes: '[emplid]' ```

Yes remove emplid for now. Or map it to description for now...

Sorry, I have no way to share a screenshot, except via email. But I think you are right, the system appears to fail at the emplid and then doesn't bother with processing the rest. I removed the emplid and now I get a new error message (see below). Its mostly Greek to me, but I did notice that bit about **Caused by: com.unboundid.ldap.sdk.LDAPException: birthdate: value #0 invalid per syntax.** Not sure what syntax it is referring to. I thought maybe it was the data type, so I changed birthdate from Text to Date, but that didn't solve the issue. ``` 2017-03-29 09:17:58,077 ERROR [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:671) - Failed to 'update' person '@!2EA2.03B7.4E47.7F65!0001!6345.AFEB!0000!921A.5039' org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to update entry: inum=@!2EA2.03B7.4E47.7F65!0001!6345.AFEB!0000!921A.5039,ou=people,o=@!2EA2.03B7.4E47.7F65!0001!6345.AFEB,o=gluu at org.gluu.site.ldap.persistence.LdapEntryManager.merge(LdapEntryManager.java:183) ~[oxLdap-3.0.1.jar:?] at org.gluu.site.ldap.persistence.AbstractEntryManager.merge(AbstractEntryManager.java:268) ~[oxLdap-3.0.1.jar:?] at org.gluu.site.ldap.persistence.AbstractEntryManager.merge(AbstractEntryManager.java:283) ~[oxLdap-3.0.1.jar:?] at org.gluu.oxtrust.ldap.service.PersonService.updatePerson(PersonService.java:119) ~[classes/:?] at sun.reflect.GeneratedMethodAccessor1712.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_112] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_112] at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.gluu.oxtrust.ldap.service.PersonService_$$_javassist_seam_35.updatePerson(PersonService_$$_javassist_seam_35.java) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.updateTargetEntryViaCopy(CacheRefreshTimer.java:664) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.updateTargetEntriesViaCopy(CacheRefreshTimer.java:556) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.detectChangedEntries(CacheRefreshTimer.java:379) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processImpl(CacheRefreshTimer.java:270) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.process(CacheRefreshTimer.java:178) [classes/:?] at sun.reflect.GeneratedMethodAccessor256.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_112] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_112] at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.async.AsynchronousInterceptor.aroundInvoke(AsynchronousInterceptor.java:52) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer_$$_javassist_seam_31.process(CacheRefreshTimer_$$_javassist_seam_31.java) [classes/:?] at sun.reflect.GeneratedMethodAccessor255.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_112] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_112] at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.Component.callComponentMethod(Component.java:2313) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.core.Events.raiseEvent(Events.java:85) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.async.AsynchronousEvent$1.process(AsynchronousEvent.java:33) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.async.Asynchronous$ContextualAsynchronousRequest.run(Asynchronous.java:80) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.async.AsynchronousEvent.execute(AsynchronousEvent.java:27) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.async.ThreadPoolDispatcher$RunnableAsynchronous.run(ThreadPoolDispatcher.java:142) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_112] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_112] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_112] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_112] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_112] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_112] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_112] Caused by: com.unboundid.ldap.sdk.LDAPException: birthdate: value #0 invalid per syntax at com.unboundid.ldap.sdk.LDAPConnection.modify(LDAPConnection.java:2752) ~[unboundid-ldapsdk-3.1.1.jar:3.1.1] at com.unboundid.ldap.sdk.AbstractConnectionPool.modify(AbstractConnectionPool.java:1302) ~[unboundid-ldapsdk-3.1.1.jar:3.1.1] at org.gluu.site.ldap.OperationsFacade.modifyEntry(OperationsFacade.java:550) ~[oxLdap-3.0.1.jar:?] at org.gluu.site.ldap.OperationsFacade.updateEntry(OperationsFacade.java:536) ~[oxLdap-3.0.1.jar:?] at org.gluu.site.ldap.persistence.LdapEntryManager.merge(LdapEntryManager.java:177) ~[oxLdap-3.0.1.jar:?] ... 60 more 2017-03-29 09:17:58,080 INFO [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:382) - Updated '0' entries 2017-03-29 09:17:58,080 INFO [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:384) - Failed to update '3,046' entries 2017-03-29 09:17:58,090 INFO [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:424) - Removed '0' persons from target server 2017-03-29 09:17:58,090 INFO [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:439) - There are '3,079' entries before updating inum list 2017-03-29 09:17:58,091 INFO [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:443) - There are '3,079' entries after removal '0' entries 2017-03-29 09:17:58,091 INFO [pool-2-thread-3] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:447) - There are '3,079' entries after adding '0' entries ```

Syntax is: ``` attributeTypes: ( 1.3.6.1.4.1.33592.1.3.2 NAME 'birthDate' DESC 'birthday' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 USAGE userApplications SINGLE-VALUE ) ``` Format is: ``` yyyymmddhhmmss.ffffff (local time) yyyymmddhhmmss.ffffffZ (GMT) yyyymmddhhmmss.ffffff-hhmm (Time zone west) yyyymmddhhmmss.ffffff+hhmm (Time zone east) The seconds (ss) and microseconds (ffffff) can be omitted and defaults to 0. ``` You may need to use a custom cache refresh interception script to transform the value into the right syntax.

I'm sorry, I don't understand what you are implying. Where did your syntax and format data come from? I don't see it listed for the 'birthday' attribute. Not that I mind doing a custom interception script--I'm going to test that at some point anyway--but I don't understand how you came to the conclusion that one is needed. I checked with our LDAP admin and the birthdate attribute from the backend LDAP database is a text type, just like the Gluu birthdate data type. Even so, it is already in the format of YYYYMMDD, just like the description of birthdate states. Do I need to check the syntax and format of every attribute? If so, why did some just 'work,' like givenName and sn, but others do not when they're all just text types?

``` Caused by: com.unboundid.ldap.sdk.LDAPException: birthdate: value #0 invalid per syntax at com.unboundid.ldap.sdk.LDAPConnection.modify(LDAPConnection.java:2752) ~[unboundid-ldapsdk-3.1.1.jar:3.1.1] ``` If you check the LDAP server logs, you'll probably see an error there too (if I'm right...) The LDAP server determines the schema syntax.

Ok, awesome. I can work with the LDAP admin on that. In the meantime, is there a reason why attributes I add with no syntax issues don't show up when I view accounts in Manage People? Only the original attributes added when the server was setup are shown.

The view person feature in oxTrust is pretty limited. It's not meant to be a generic LDAP browser.

Thanks, good to know I haven't setup anything correctly.