I have a question about the Data Import module on Servicedesk. When we run an import from AD, there will be times when fields are not filled in within AD that we later fill in on Landesk Servicedesk. A good example of this would be Telephone number. Telephone number changes rapidly and sometimes users will have a temporary number for a month or two where updating AD is not practical or necessary. Or the average end user doesn't have an e-mail address/telephone number and we manually add-in the details of their manager for example to use as contact details. Where the field in AD is blank and we have manually added details in a field or fields is the data import supposed to leave the fields with the manually-entered data or does it overwrite and clear the field as it is in AD?
If the latter is true, is anyone aware of a method by which this can be changed so that if the field is blank within AD it will leave any data in the field alone?
You have to either:
A) Back-fill the ServiceDesk fields into Active Directory at night BEFORE the next import, or
B) Populate the additional fields directly into Active Directory INSTEAD of into ServiceDesk.
Both of the choices involve writing something custom to populate your data source (Active Directory) BEFORE the next import. In our case we created a database table and a database view (called "The Hub") to act as the data source/staging location for data moving between Active Directory and ServiceDesk. Then we wrote a program which:
1. FIRST adds new analyst info from ServiceDesk into The Hub
2. SECOND scans Active Directory objects for changed properties and new users, and adds/updates The Hub
Finally, the user import runs which pulls from The Hub and just overwrites everything in ServiceDesk with all fields, but only for user rows in the Hub which contain changes-- this "changes-only" import is the reason for the using the view, rather than importing directly from the table. It takes too long for us to do a full import/overwrite for all users when most users don't even have a single field changed.
This is a complex setup, but it was necessary for us because Active Directory is not the singular source of user information. We needed a place to consolidate user data before importing into ServiceDesk. But implementing this involved both programming and SQL design work.
Today I noticed this thread, where he explains that you could use filters to avoid importing rows where a particular field is NULL, which could work for you in some cases, but might exclude too much-- i.e. probably would end up excluding new users who don't yet have a phone number.
So as I thought about your question and how his answer applies, I realized that you could work around it by adding an additional phone attribute on the user object in ServiceDesk, such as "Temporary contact number" and don't map anything to that field with your user import. Then the value keyed in by the SD analyst would stay there even if the AD import keeps overwriting the main contact phone attribute with 'empty'. Not the best, but maybe a viable workaround.
this may have been the posting that mhz was referring to - http://community.landesk.com/support/message/55143#55143 - good solution actually. basically unmap fields where you consider this an issue and create new mappings with the primary key from your data source along with the field that you want brought in but excluding (using filters) those with a null value. the second mapping (or a third etc.) would need to follow the original so that end users are created initially and then their phone numbers (for example) are updated consequently but only those with values.
Yes! Good explanation. That is the correct link, which I did link under the word "this", but it's not very visible. Sorry. Thx for clarification.