Reputation: 6554
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:
Console App A
need to also use username/domain/password in it's Process.Start()
command when calling the 3rd party program?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) { } //handle
catch (System.ArgumentException ax) { } //handle
catch (System.ComponentModel.Win32Exception wx) { } //handle
catch (System.IO.FileNotFoundException fnfx) { } //handle
Upvotes: 1
Views: 6599
Reputation: 6554
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.
Upvotes: 4
Reputation: 294307
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.
Upvotes: 0