tags:

views:

174

answers:

3

I've created a Windows Service that accepts commands from remote machines via WCF. One of those commands is to run a specified executable (let's ignore the security implications of such functionality).

In my Service I am using Process.Start() to run the executable. All works well if the executable is local to the machine, but if it is on a remote file share it is failing with no error (or more accurately just hanging). I suspect the problem is that it is triggering the standard Windows 'Unverified Publisher' warning that one would see if they double click an exe on a remote system.

Is there any way I can bypass this from my service so that I can truly run any executable? As I said I understand the security implications of allowing it to run any executable, but this is really what I need. I would have thought this warning was only a user mode concept, but it really does seem to be getting in the way of my Service.

Ideas?

+1  A: 

You might want to check the permissions of the account that is running the service. You might need to use an account with more privileges to run files not located on the box. One easy way to test it is to have service run under an admin account. If it works, then you know where the issue is.

TskTsk
I am running the service under an account with admin privs. Thanks for the idea though.
BrettRobi
+2  A: 

I had the same issue. And you are right about the 'Unverified Publisher' warning.

My solution was to copy the EXE locally into the %TEMP% folder and kick it off from there. In my case, this was optimal because the EXE had no dependencies.

AngryHacker
I didn't want to resort to this but it works as long as there are no dependencies. There appear to be no other workarounds, so thanks angryhacker.
BrettRobi
After playing with this a bit more I discovered the true problem in my case. I needed to set StartInfo.UseShellExecute = false;Check out this question: http://stackoverflow.com/questions/2790071/starting-a-process-from-a-net-windows-service/2791053#2791053
BrettRobi
A: 

Perhaps you should check .net framework Runtime Security Policy and adjust zone security settings.

Daniel Dolz