RemoteApp is defined in [MS-RDPERP]: Remote Desktop Protocol: Remote Programs Virtual Channel Extension
Windows 7 SP1 to Windows Server 2008 R2 (Firefox 4): mstsc_remoteapp.zip
Even though [MS-RDPERP] mentions a single virtual channel, “rail”, the packet capture shows the client registering “rail”, “rail_ri” and “rail_wi”.
More details about “rail_ri” and “rail_wi” can be found on this page.
RemoteApp support was introduced in FreeRDP 1.0, so you should get the latest sources from git.
./client/X11/xfreerdp -u <username> -p <password> --app --plugin rail --data "<exe_or_file>:<working_dir>:<arguments>" -- <hostname>
exe_or_file: usually a program alias prefixed with “||”, otherwise a full path to an executable file.
working_dir: the working directory to use for running the application
arguments: arguments to pass to the application when it is being launched (it has to be allowed on the server explicitly)
For instance, if you configure your server to export the command prompt, it will have the “cmd” alias by default. You could then get the windows command prompt with a command like this:
./client/X11/xfreerdp -u Administrator -p Password --app --plugin rail --data "||cmd" -- 192.168.1.200
If you haven’t installed FreeRDP globally on your system and you are running from the source tree, change —plugin rail.so to —plugin channels/rail/rail.so.
Alternatively, it is possible to use full paths to launch a program instead of an alias. Please note, however, that Windows Server 2008 R2 SP1 disallows this by default and you need to enable it in the group policies. In this case, the command would look like:
./client/X11/xfreerdp -u Administrator -p Password --app --plugin rail --data "%windir%\system32\cmd.exe" -- 192.168.1.200
You may also want to try newer syntax:
xfreerdp /u:user /d:domain /p:password /app:"||calc" /v:server
There is currently an issue where the usage of the colon ‘:’ conflicts with the —data argument separator, so paths like “C:\Windows\System32\cmd.exe” won’t work. If you are experiencing such issues, use environment variables like
%windir% to work around the problem until a more permanent solution is found.