You can give them the rights to do that by giving them enough inventory privilidge. If they open the inventory window of a machine in the LANDesk console, they can use the buttons at the top to add a new number, date, or string. If they click that in the location where they want that data added they can enter the hint. The drawback of that is the potential for user error when manually adding this information.
I would suggest one of two things:
First, if possible, place the password hint in a location on the drive itself and have LANDesk scan that (e.g. a registry key in a secure location where a user would not normally be able to see it). That way the hint goes with the drive, is scannable, and user error is minimised.
Second, don't put it in LANDesk. put it somewhere in your service desk tool instead so that it is linked to the user's record in some way. Drawback here is that unless you assign assets to users, then you will have to link the hint to a user rather than an asset.
I prefer the REG key if you can do that.
Mark Star - MarXtar LANDesk Enhancements
Home of Power State Notifier & Wake-On-WAN for LANDesk
Oops. Forgot to say that if you can add the info to the drive itself (reg key if the OS is on it or a secured file if it i just a data drive) then the passwod hint goes with the drive rather than having to be manually updated in th database if the drive is moved or someone accidentally deleted the LANDesk database record.
Mark Star - MarXtar LANDesk Enhancements
Home of Power State Notifier & Wake-On-WAN for LANDesk
As an alternative approach, you could use Managed Planet's DTS to store this in a file or db and then pull the data in. This keeps all the data centrally stored and easy to administer. Depending on how the data is linked, you could have the hint linked via user, or device name or however it will work for your environment.
Oct 1, 2008 2:42 AM
To add on to this - on a more strategic level - with any kind of custom data, there's always only ever two possible places of data entry.
1 - The Console direct (thus directly throwing this data into the DB)
2 - The client somehow (and the information would be fed in via inventory as custom data).
Now, it's generally CONSIDERABLY preferable to come up with a process that works for you that holds this data on the client. Direct data-entry via Console while certainly possible is very much NOT preferred.
Why?
Simple - data resilience.
======
If your database should go down the pan, and you find out that the guy who's supposed to have been making backups wasn't (i.e. - "worst case scenario" ) - what do you do?
If your data is only ever directly entered in the DB, you'd be pretty much screwed. You'd have no access to your passwords, and thus would've locked yourself out.
=======
Compare this with having the data on the client (or the drive) and getting it to the Core. If the database should go up in flames - no problem - just set up a new DB, and the data will come in as custom data again.
If the client should go up in flames, again - no problem - you've got all the data in the database anyway.
=======
So whatever process you decide on, I would certainly recommend of holding the data on the client side for resilience ... it's not always possible (I know), but that's the more secure option.
Paul Hoffmann
LANDesk EMEA Technical Lead
