Question: I have an MS Access application that can send Lotus Notes email via VBA macro. With Access 2003 it is no problem to get a Notes.NotesSession. With Access 2010 it gives a problem that says "\Automation -Embedding.nsf" does not exist. (I don't know what to do.) Another way is when I use Lotus.NotesSession and initializing the session. It works, the macro continues, but afterwards asks for Lotus Notes password (the user has to type in), but it is not quite handy to always type in this password.
From Dave Kern, Rich Schwartz, and Peter Rosenberg in a forum topic on this same question:
The ID file password is the password used to decrypt the ID file...so by definition can't be stored in the ID file.
The "Notes password" is used to generate an encryption key which is used to encrypt and decrypt the ID file, which contains the keys used to access servers and perform secure mail operations. There is no way to "extract" the password from the ID file, because the password isn't stored in the ID file.
But what you can do is change a setting in the Notes client. This setting has been available in Notes for at least 15 years, but the location and wording has changed in different versions. In Notes 8.5, the setting is located in the User Security dialog. It is a checkbox with the label "Don't prompt for password from other Notes-based programs (reduces security)".
If you turn on this setting, and your users are already running the Notes client, they will not have to enter the password again for your macro. But there is a good reason the setting has the warning "(reduces security)" in the label: it means that Notes will allow all programs that use the Notes API to gain access without re-typing the password. With this setting turned off, any virus that tries to use the Notes API to read data (for example, the email address of user's contacts) will get a password prompt -- and well-trained users should recognize that something bad is happening and have the opportunity to stop the virus. If the setting is turned on, users lose this protection. You will have to balance this risk against the benefit of avoiding having to type the password.
Another possible solution: Have you considered using SMTP mail instead? You probably found that your MS Access solution did sent mails showing your name as sender - which might be the intention. But if your'e running server-like solutions, this could easily be replaced by (I believe its native within MS Acces 2010) a component that allowed you to send SMTP mails.