Windows service Process.Start not working under network service account

Edit For anyone having an issue, it turns out to be, as usual, a simple problem to solve. The keys need to be installed under the service account. Log on to the workstation under the service account, install the keys, and then it can be run from any session that would be launching it under the service account context. Problem solved.

Edit: Service OS is Win 2003 Edit: Works when launching notepad.exe. Leading me to believe it's somewhere in the console app calling GnuPG.

I have a windows service that acts as a mechanism to transfer files in/out of the network. For some of these processes, I would like to execute a console app prior to the transfer occurring, or, after it occurs.

I am having some issues getting the console applications to run correctly under a network service account.

Here is a layout of the problem:

Windows service runs under a network service account, let's call it Company\ServiceAccount Company\ServiceAccount wants to run Transfer A. Transfer A needs to have Console App A run before any files are moved. Console App A also shells to a third-party console app program. (Reason being -- we wanted to embed more business logic in Console A rather than putting that code in the service itself)

Console App A calls a free command line PGP program (GnuPG for anyone wondering). Console App A waits for GnuPG to finish and moves some files to a drop point so that Transfer A can pick them up and move them.

The application code runs just fine on my workstation running under the local system account. When the Windows service runs, I don't get any feedback from the Console application. I don't get any access denied errors or anything else, which isn't helping trying to debug this.

Questions:

1. Are there any obvious problems? The service account is indeed valid and has no problem connecting to the network.
2. Does Console App A need to also use username/domain/password in it's Process.Start() command when calling the 3rd party program?
3. Obviously there could be alternatives to the way I am doing this but -- should I abandon this completely? I have a feeling it should work.

Code:

      System.Diagnostics.Process process = null;
        System.Diagnostics.ProcessStartInfo psi = new System.Diagnostics.ProcessStartInfo(executable, args);

        string pwd = "mypassword"; //edited for security
        System.Security.SecureString securePwd = new System.Security.SecureString();

        foreach (char c in pwd)
            securePwd.AppendChar(c);

        try
        {
            psi.UseShellExecute = false;
            psi.WindowStyle = ProcessWindowStyle.Hidden;
            psi.CreateNoWindow = true;
            psi.ErrorDialog = false;
            psi.Password = securePwd;
            psi.UserName = "myserviceaccount"; //edited for security
            psi.Domain = "MyCompanyDomain"; //edited for security
            process = System.Diagnostics.Process.Start(psi);
            //Wait for the process to finish
            process.WaitForExit();
            process.Close();
        }
        catch (System.InvalidOperationException iox) 开发者_StackOverflow社区{ } //handle
        catch (System.ArgumentException ax) { } //handle
        catch (System.ComponentModel.Win32Exception wx) { } //handle 
        catch (System.IO.FileNotFoundException fnfx) { } //handle

For anyone having an issue, it turns out to be, as usual, a simple problem to solve. The keys need to be installed under the service account. Log on to the workstation under the service account, install the keys, and then it can be run from any session that would be launching it under the service account context. Problem solved.

Starting with Windows Vista services are explicitly forbidden to interact with the user session, even when marked as interactive. See Interactive Services:

Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.

If any of your 'console app* are doing any sort of user interaction, it will fail. Can this be the case? If yes, then you cannot have your 'console apps' run from a service, they will have to be launched from a user session.