Due to the many to many mapping nature of the TRIMDS tool, a lot of the success or failures around its use depend on the sequence of commitment of the mappings. One mapping can easily over right some settings made in the mapping committed prior.
I remember in the early days quickly setting no access to all users then setting access to all and running out of licenses in around 30 seconds. Its not an easy tool to set up, but is extremely powerful when configured correctly.
Attached is an old published document TOWER that helps explain how to set things up.
Thanks for that - the user guide definiately looks to explain the utility in a lot more detail ( no bad thing! ).
Other thing we were noticing was that time within log files was actually out by an hour ( looked to not be taking account of BST change ) although server time was as expected - couldn't see how/where it was getting different time from. Could that be confusing the utility with the 'Last Modified' setting possibly being out of sync ?
I have noticed the time stamp issue myself. I believe that the code doesnt take daylight savings into play, but I could be wrong on that. What I do know is that when you are not on daylight savings time in any zone, the time stamps are correct.
I get those for when TrimDS tries to synchronize licenses with non person locations. This was behavior introduced into TrimDS sometime after the 6.21 release. As long as your person locations are getting processed and allowed logon ability, it's probably fine to ignore these errors (at least that's what I was told by HP).
I think the DS tool expects an LDAP v3 compliant directory to use a Universally Unique Identifier (UUID) to ensure that all entries being synchronised can be uniquely identified. I don't know whether Oracle's directory actually is or claims to be LDAP v3 compliant but I would expect if it was, you'd find such an attribute against entries. A UUID is always in the same format that the error log is specifying. TRIM DS has only been tested against AD, eDirectory and OpenLDAP.
Note: Any posts I make on this forum are my own personal opinion and (unless explicitly stated) do not constitute a formal commitment on behalf of HPE.
(Please state the version of CM you're using in all posts.
HPE Software Support Online (SSO): https://softwaresupport.hpe.com/
Yes I know notice that these errors only appear for non-person locations.
For person locations however I notice this warning: "The login for the Location <location name>, has been disabled by TRIM Directory Synchronizer. Either this location has no unique Identifier or this location's unique Identifier was not found in the LDAP Directory."
Furthermore, the number of person locations that it attempted to sync with was only a small subset of the total available people in the LDAP directory. I couldn't find what was special about these people, and why the rest were ignored.