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.