Sysinternals Tool Aids Incoming Remote Command Interaction With Vista Desktop

Resolving The Problem

Microsoft tightened up the security in Windows Vista/7/8.1 and 2008/2012 R2 Server to separate services from desktop sessions. The incoming remote command (IRC) portion of System i Access was designed to run as a Windows service and not as a desktop application. Therefore, incoming remote commands cannot really interact with the desktop as it did in older versions of Windows. See IBM Technote N1021806 Incoming Remote Command (RUNRMTCMD) with Windows Vista, 7, 8.x, and 10.

Microsoft has a tool available as one of the Sysinternals tools, which can be used on the PC running Windows Vista/7/8.x and 2008/2012 R2 Server to allow programs to be launched through the incoming remote command to work seamlessly with the desktop. The URL for these tools are prone to change, so we can only recommend that you search on the name of the tool, PSEXEC and SYSINTERNALS, and look for a hit that is on a Microsoft domain such as technet.microsoft.com. Once you have downloaded the PSTOOLs and restored/installed them on your target machine, it would be a good idea to add the directory to the path statement so that you do not have to provide the entire path to the PSEXEC tool when you execute it.

Because the PSEXEC tool has its own documentation, it will not be repeated here. The purpose of the tool is to allow a Windows user with this program to execute a program or start an interactive command shell to a remote Windows PC that also has the program installed on it. We can use it to tell the machine to connect to itself through an incoming remote command and have it start a program in the desktop session.

Testing this found that the properties for the incoming remote command (accessed through the System i Access for Windows properties) did not seem to influence the behavior; therefore, you should set those to whatever settings are convenient for you. You can check the options to allow generic security to save having to type the Windows password every time you recall RUNRMTCMD for another run. Testing with those features turned off also worked as expected. The properties for the incoming remote command service (accessed through the Windows services manager) do not require that the option Allow service to interact with desktop be checked. The reason for this is that RUNRMTCMD is going to run PSEXEC, and that program is going to make it's own connection to the PC and run the program that you want to run. That sounds confusing enough; however, an example should clear it up. After starting the System i Access for Windows Remote Command service, you can test running the following command on an IBM i command line to start the default Web browser to open up the i5/OS Information Center:

RUNRMTCMD CMD('psexec \\127.0.0.1 -s -d -i cmd /c start
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/welcome.html') RMTLOCNAME('mikswens-pc' *IP) RMTUSER(*NONE)

Note that the explicit path to the PSEXEC program was not provided. This location was added to the path prior to starting the IRC service. The -d option for PSEXEC can also be used so that it starts the program and exits, that way the command line is not input-inhibited so long as the program runs (this is not a very good example of that, because the 'cmd /c' really does the same sort of thing). One other thing being demonstrated here is how program extensions can be used to start the default program. Notice that the command passed to Windows did not specify any particular browser; it is starting a Windows command shell that will start a URL. This leaves Windows to invoke the correct program. In this case, the user's default Web browser. So, for one user that might be Internet Explorer, for another it might be Firefox, and another might use Safari. You do not need to know which one is the default, just trust that there is one. If there is not one, it would fail with an option to have the user find or select a default program.