There is no way to write to LDAP. The integration only is 1 direction.
Don......It's good idea to make it 2 direction with LDAP and Dynamic SQL .
1 of 1 people found this helpful
Now on version 12.1.08.001
I don't need to update LDAP, but rather the FP address book database. I just set up again from scratch and am still having the same issue.
1. Added a field to the Contact record type called 'Building' - this is not mapped to LDAP.
2. Verified that the newly created field 'building' was added to the FP address book database table.
3. Created a data link field in my ticket form to the FP address book table on the new 'building' field.
Now if I manually update the 'building' field directly on the database and then create a ticket, that value successfully pulls from the db to the ticket, so I know the link is working. Also, when saving the ticket, the associated contact successfully links to the ticket as expected.
The only issue is upon saving the ticket. The linked Contact is not updated from the ticket with a new value for 'building'. If a new ticket is opened for the same Contact, even though the 'building' was changed in a previous ticket, the new ticket still pulls in the old value because the Contact was never updated.
Am I missing something in the configuration or is this an issue with the application? Maybe I need an address book that is not linked to LDAP, and just run an import of users every once in a while?
From my experience and understanding from BMC, the address book you have is configured as an LDAP/AD address book; not a FP address book.That is the main issue you are having; since its considered an LDAP address book and its one direction only, you cannot write back into the address book - even if you have a field created there that is not 'mapped' to an AD attribute.
I think I understand what you're trying to do.. Basically have a field in your address book not tied to LDAP correct? I don't believe this is supported.
Yes, a field separate from LDAP is what I wanted to create.
I ended up creating a new address book and imported the contacts from a csv that was generated with an LDAP query (Powershell). Since it's an internal address book, I am able to edit the contacts and update any field I need.
Has anybody else done it this way, or is there a better way to go about it?
Sounds like the goal is to track or change data without touching LDAP right?
Yup. Our AD doesn't have information on the contacts' location, so I wanted to be able to track that separately in Footprints. Down the road there may be additional fields we'll want to add to the contacts as well.
You could create an item in a container called 'Location', create a record for each location, then link contacts to that location record. If locations are generic enough. Such as city, building, etc. But if there's going to be hundreds of possible locations that might not be worth it.
Long shot but any chance your AD team can put it in AD?
Thanks for that idea, that might be possible since we don't really have many locations. We probably won't be adding any fields to AD if it can be helped, even though I think a location attribute would be helpful.
Anthony Guthrie wrote:
[...]We probably won't be adding any fields to AD if it can be helped[...]
This is something I hear far too often, and usually without any, what I call, valid, reason.
Some of what I've heard so far:
1) Microsoft wont support us if we have custom attributes. Really? I highly doubt that. Kind of a lame reason either way.
2) Our AD guys don't know how to create custom attributes. They can learn. Heck I learned how just watching Youtube videos.
3) We don't want to manage this information in AD, it's too time consuming. Really? You think it'll be less time consuming to manage it in another system like FootPrints? If it's too time consuming for AD, it's too time consuming for anything else really.
4) We don't want to manage this information in AD, it's not relevant to AD. Well if AD is your single source of truth then the info belongs there! Or not at all.
5) We don't want AD to be our single source of truth. Why? Fair enough.. then don't integrate your ITSM tool with AD!