06-03-2010 12:34 AM
Currently evaluating use of TRIM DS tool to create/update TRIM users from Active Directory, but so far having very mixed results.
Seems to be very inconsistent in its actions - some instances the creation/updates appear to happen as expected while in others they don't - with log file not showing any problems.
Also appears to be an issue with re-setting 'Accept Logins' - can remove from a user , but then we can't set back on.
Is anyone else using this tool and experiencing issues?
06-05-2010 07:23 AM
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.
06-07-2010 12:39 AM
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 ?
06-07-2010 06:54 AM
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.
10-05-2010 05:22 PM
I'm having a problem running the TRIM DS tool with the LDAP, Oracle Directory Server Enterprise Edition.
The log file says: "An Error occurred while checking for unsynchronized Locations. Localtion Name: <location name> Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)"
Any ideas what this value could be? The user guide states for OpenLDAP it is the entryUUID, but we don't seem to have a matching value in our schema.
Any help or advice would be greatly appreciated.
10-06-2010 10:22 AM
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).
10-06-2010 04:48 PM
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 do not constitute a formal commitment on behalf of HP.
(Please state the version of TRIM/HPRM you're using in all posts)
HP Software Support Online (SSO): http://support.openview.hp.com
10-06-2010 05:57 PM
Righto thanks for that.
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.