4

I have written a C# console application that uses the Interop.domino.dll assembly to interact with domino / notes to create, update and delete documents. The application runs successfully when running it manually through a cmd prompt or through Visual Studio. However, when we try to set the application up as a scheduled task (running under a domain service account) it fails with the following error:

  • System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).

The error occurs as soon as we try to use an object from the Interop.domino.dll, specifically when try to create an instance of the NotesSession object as per the following:

  • ISession notesSession = new NotesSession();

After some investigation I found that the interop assembly requires a desktop to interact with and that if we ran the scheduled task with the service account logged into the machine that the scheduled was running on the scheduled task would run successfully. While logged in as the service account you could see that the application would bring up a svchost.exe window while the application was running and that is the reason it requires the desktop.

However, having the service account logged into the machine all the time is not an acceptable solution as it means that the account has to be logged in again each time the server restarts. There are also some security concerns around having about allowing a service account to login to machines.

So, I was wondering if anyone had any suggestions on how to get around this issue? Is there a way to suppress any UI that the assembly tries to show? Alternatively, can anyone suggest an alternate to a scheduled task which would achieve a similar result. What we need to do is:

  • Have the application run at a set interval (IE - once a day / once an hour)
  • Ideally, have it run under a domain service account (as opposed to a local system account)
  • Run without requiring the service account to be logged into the machine / UI elements from the Interop.domino.dll suppressed

We have thought about writing a similar application making use of the notes web services rather than the Interop assmebly and will go down that path if we can't get the console app running as a scheduled task. However, we would like to make use of what I have already written if possible.

Update 01/05/12

I have tried etting the NOTESNTSERVICE OS environment variable as per @dna-man solution. However, this did not solve the issue.

For now we have set the application up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account, but the application does work so we will go with this approach for now.

There was an answer that suggested this approach, but it seems to have been removed so I can't mark it as correct. I might leave the question open a bit to see if anyone else has any suggestions.

b_dialog
  • 41
  • 1
  • 5
  • 1
    Why not run a native Notes Agent, if you got a Domino Server? – leyrer Apr 20 '12 at 13:23
  • 1
    This doesn't have anything to do with the interop assembly, it just contains declarations and no code. Contact IBM for support. – Hans Passant Apr 20 '12 at 21:48
  • @leyrer - We might end up gong down the path of writing a notes agent to perform the task if we can't get the C# app to work. However, having only discovered this issue late in the development of the app we would like to make use of what we have already written if possible. – b_dialog Apr 26 '12 at 04:05
  • Are you geting prompted for the Notes password if you are running it (for the first time) manually through a cmd prompt? – leyrer Apr 27 '12 at 12:30
  • @leyrer - Nah, we aren't getting that prompt when we run it manually. However, we are providing the username and password to the Initialize (just the password in this case) / InitializeUsingNotesUserName method. – b_dialog May 01 '12 at 03:44
  • @HansPassant - I missed your comment when first looking at this. You are correct that the interop assembly does not contain any code. It is really the Lotus Domino Objects (domobj.tlb) that is causing the issue, the interop assembly is just a wrapper for that. At least, that is my understanding. – b_dialog May 01 '12 at 03:58

3 Answers3

1

If your code is running on a Domino server you must make sure the OS environment variable NOTESNTSERVICE=1 is set. You can find out more abou this environment variable in the Lotus C API documentation, but it applies to the COM API as well when running as a service. I had created way back in 2003 a VB.NET application that had to run as a service, and setting this environment variable was the key. If it wasn't set, the service would stop working as soon as I logged off the machine. To make sure somebody didn't forget to set this environment variable when installing the service in the future I simply had my service manager start code set this environment variable directly on startup using the VB.NET call to SetEnvironmentVariable. It had to be set before creation of the Domino session object.

dna-man
  • 11
  • 1
  • Thanks, I will look into this as a potential solution. We are using a scheduled task rather than a service but from how you explain it I am guessing that setting that environment variable might work for scheduled tasks as well. – b_dialog Apr 26 '12 at 04:01
  • I looked into this and setting this environment variable didn't solve the issue. It may be that it does need to be set, but it doesn't look like it suppresses the need to interact with the desktop. – b_dialog May 01 '12 at 03:34
0

It's hard to say exactly why, but I believe it's failing to read the registry information for the Lotus interop classes. Obviously the entries are there, otherwise it would not work while running manually. So let's consider other possibilities.

I don't even know if this is possible, but os your application running as 32 bit when run manually, but 64 bit when scheduled? IBM doesn't support the Domino COM classes on Win64, and I'm pretty sure that the first symptom of that is that the registry l

A more mundane possibility is that the service account just doesn't have access to read the registry entries for the Notes/Domino install on the machine, possibly because the software was installed under a specific user account.

Richard Schwartz
  • 14,463
  • 2
  • 23
  • 41
  • I haven't look into the registry permissions of the service account, but I am not sure that it explains why it runs correctly when the service account the scheduled task is running under is logged onto the machine. If the service account didn't have permissions to read the registry, then it would probably fail even if the service account is logged onto the machine. So, it seems unlikely it is a registry permissions issue. – b_dialog May 01 '12 at 03:49
  • In regards to the 32bit vs 64bit suggestion, the scheduled task does work when the service account is logged into the machine, it is not failing completely. If it was due to this, then it probably wouldn't work all the time. So, I think we can rule that out as possibility. – b_dialog May 01 '12 at 03:52
  • Well, I still believe it's a registry read error, and the best answer I can come up with is that for some reason, the domain service account does not have the permissions unless it is actually logged in. Is there any anti-malware/firewall/intrusion protection software installed on the machine? From googling the error code 0x80004005, I see that sort of thing implicated in a few cases. The only other suggestions I have are to re-install Domino using the Domain service account (if it was installed under a different account), or to call IBM if you have an active support contract. – Richard Schwartz May 01 '12 at 20:49
0

I ended up modifying the application slightly to set it up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account. However, this approach does allow the application to run without requiring an account to always be logged in and does allow for the interop UI elements to be shown (thus avoiding the error).

To schedule the windows service to perform the task at a set interval (which I set at once a day) I used the Timer solution proposed here.

Community
  • 1
  • 1
b_dialog
  • 41
  • 1
  • 5