Redirect Process Input/Output with Windows API

Hey Chris,

Just to update you on my remote execution tool, I have sucessfully created a working application with a GUI interface that allows the creation of a remote processes on a Windows XP machine as either the currently logged in user, a domain user, or the SYSTEM account with console output re-direction through a named pipe from server to client. Also interactively on a Windows 7 machine, as the SYSTEM account on the seperate SYSTEM account's window station, and non-interactively for the domain account.

The issue with locating the security context of the currently logged in user was resolved by using API rather than using the security token of explorer.exe, to make a query on whether or not someone is currently using the console session or if it is a remote desktop session. This tool will NOT work if there are multiple active remote desktop sessions as currently it is targetting the first one available that is in use. I could potentially prompt the user with a list of active remote desktop sessions to make a choice, listing the userid's of each session for clarity, but I haven't gotten around to this yet.

If no one is logged into the machine then the option for an interactive process is disabled.

The tool also distinguishes which version of windows is running on the remote machine through the registry. Basically to use this tool you would need admin rights to the remote registry, access to create and modify services and write access to the Windows System32 folder on the remote machine.

Also, I did not implement any support for Windows 2000 OS.

There is no point in targeting the Current Users security context to make a process run interactively on Windows 7 OS unless you want to install some kind of service on every single machine that you want to have the process interact with the user for and make it start under the security context of the user when they log in using a policy or something. Our security policy at work doesn't permit us to run processes non-interactively as another user so I didn't implement that.

I also included an option to prompt the remote user to start the process with a default timeout that notifies the client application. This option can be specified when calling the function to remotely start the process from the DLL. Also you can specify custom prompt strings in case you want a different message for the user to see when accepting the request to start the process. I did this because I also created another executable that installs a print queue so I copy the executable to the remote machine, use the remote tool to start the process and provide queue information, and prompt the user to install the particular queue name onto the machine.

I've tested this remote execution with MSIExec, cscript, and wscript processes to install/un-install application on a remote machine or queue the install or removal in the SMS delivery client that our workstations have and receive back a return value from the process exiting.

This tool was implemented into a much larger network admin application that I have also created that is now being used by several hundred IT analysts in my place of work, that is under copy write protection, but the remote execution portion of the application is owned by myself.

As soon as I have time I am going to re-create the visual interface of the copy written code for use with the pre-compiled library that does all the real work and make a few modifications with some more testing and I will distribute a copy of both the application and library as a package for others to use.

So as a conclusion to the entire topic of creating an application that functions in the same way as the PSEXEC binary, it is 100% possible to make this work using either MS Visual C# or MS Visual Basic .NET programming languages.

I'm impressed :D and glad to see you got it all working in the end. Hope my contributions did help a little :) I would love to see your library if you get chance to release it too

You certainly did help very much with several aspects especially re-directing the standard output/input. It took a while to get it through the named pipe to the client machine but it works flawlessly now. I'm still debating on sharing any of the actual code because there is a LOT of money in having that type of source code secured but I'm definately willing to help anyone else out that needs some tips and release a copy of the binary when I have the time. It may be a few more months before I release it but it will definately be worth it because of the capabilities it has. I'll keep you up to date.