RemoteApp not working with XP-Mode about freerdp

[awakecoding]

Can you clarify a bit what the environment is? What do you mean exactly by XP-mode? Are you using the VirtualBox RDP server, or the guest OS RDP server? What is the guest OS?

[Falcon-1]

Hi awakecoding,

Thanks forf the quick response

As host I'm running Ubuntu 11.04 Maverick with VirtualBox OSE from the repository

As guest I'm running the Windows XP Mode from Windows 7, Windows XPM for short.

The XPM is a tailored Windows XP virtual machine (appliance) from MS for use with windows 7 to ensure backward compatibility. The XPM features a seamless integration with windows 7, obviously done via the remoteapp
source: http://www.freerdp.com/wiki/doku.php?id=remoteapp and http://social.msdn.microsoft.com/Forums/en-US/os_windowsprotocols/thread/d91b20a2-96af-406c-aa56-085058a0af44/

The report by Vincent to MS clearly states the two additional channels were found in the network. To which MS replied that these belong to XPM and should have been there. I assume therefore that XPM uses the remoteapp for Win7 intergration. Perhaps that the other two channels have some significance.

Also the wikipedia article on VirtualPC states RDP is used for desktop intergration. And that a regular Windows XP SP3 can be enanched with the RAIL channels / Desktop integration. http://en.wikipedia.org/wiki/Windows_Virtual_PC Search for the 'seamless' keyword.

Howto XPM in VirtualBox http://vdhout.nl/20110518/

However when trying to connect no window no error message.

Hope you can help.

[Falcon-1]

Info:

Enabling seamless for a regular windows XP SP3:
http://www.mydigitallife.info/enable-remoteapp-in-windows-xp-or-vista-to-publish-programs-to-windows-7-virtual-pc-host-with-kb961741-or-kb961742-rail-qfe/

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4465

[Falcon-1]

oops wrong button

[awakecoding]

Did you test your setup with mstsc.exe first to ensure it works properly? What's the command you're using for connecting with RemoteApp?

[Falcon-1]

Did not test with mstsc first.. mstsc doesn't run on ubuntu ;-) will test later with a second vm

./client/X11/xfreerdp -u Administrator -p '***_' --app --plugin channels/rail/rail.so --data 'C:\WINDOWS\system32\notepad.exe' -- *__._..

[awakecoding]

@Falcon-1: I think you might be the first person trying to use the full path to the executable instead of an alias like with regular exported programs in RemoteApp. That might not help. I suggest you get access to a windows box or second vm to attempt using RemoteApp from mstsc.exe first, since this is a special setup. If you can't get it to work with mstsc.exe, then FreeRDP probably won't be able do to much better :)

[Falcon-1]

I already tried aliases as well: '||notepad' '||cmd'.I'll test with a second vm and return the results.

[awakecoding]

@Falcon-1: aliases are only meaningful if the RemoteApp server exports such aliases. Since this is a special server, I have no idea how it works differently from Windows Server 2008 R2.

[awakecoding]

@Falcon-1: since it was a small thing to do and a lack in the implementation, I added a check that sets the proper flags in the case that the argument passed is not an alias. Aliases start with ||, while full paths are just full paths. There seems to be a problem with the colon in the arguments parsing, so use environment variables instead. On Windows Server 2008 R2 I had to set the following group policy first in order to allow execution of unlisted programs:

Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections/"Allow remote start of unlisted programs"

I could then launch the command prompt like this:

./client/X11/xfreerdp -u Administrator -p password --app --plugin channels/rail/rail.so --data "%WINDIR%\System32\cmd.exe" -- localhost:6000

[otavio]

@Falcon-1 please give a test. As @awakecoding said this seems to be fixed already so I am tagging it as waiting for testing.

[nfedera]

Here is more info:

RemoteApp is basically supported on the following Windows Workstation OSs:

1. Windows XP Professional SP3 (x86 only !).
   Requires Microsoft KB961742-v3 to be installed: http://support.microsoft.com/kb/961742

2. Windows Vista Enterprise or Windows Vista Ultimate SP1 or. SP2 (x86 only!)
   Requires Microsoft KB961741 to be installed: http://support.microsoft.com/kb/961741

3. Windows 7 Enterprise and Ultimate (x86 and x64)

For all of these you have to create the following registry value to allow unlisted remote programs:
Create the key HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services if it does not exist.
Add a DWORD-Value called fAllowUnlistedRemotePrograms and set it to 1

Using mstsc I was able to open a TSRemoteApp on all these operating systems.
However, for XP a little hack is required for the .rdp file.

You need to add the following lines:

DisableRemoteAppCapsCheck:i:1
Alternate Shell:s:rdpinit.exe
Prompt For Credentials On client:i:1

The setting DisableRemoteAppCapsCheck:i:1 is required because mstsc is not able to automatically detect that XP SP3 does support TS RemoteApp even with the appropriate KBs installed. Without this line mstsc brings up an error message "The remote computer does not support RemoteApp."
Alternate Shell:s:rdpinit.exe is probably needed to work around a problem with that detection failure.
The last line tells the RD Client to always prompt for the credentials on the client side which comes handy if your Terminal Server does not support NLA on the server side (which only true for Windows XP).

Now regarding xfreerdp:
RemoteApp worked out of the box with Windows 7 and Vista using the following command line:

./client/X11/xfreerdp -u username -p password --app --plugin channels/rail/rail.so --data "%WINDIR%\System32\notepad.exe" -- servername

It does not work for Windows XP.
The RAIL Handshake PDU is never received on the client side.

If you read http://blogs.technet.com/b/askperf/archive/2008/02/22/ws2008-terminal-services-remoteapps.aspx you'll see that rdpinit.exe and rdpshell.exe are the server-side part of the RAIL virtual channel.

I've inspected the user's processes on XP and noticed that rdpinit.exe does not get launched.
Next I've tried to simulate the XP solution ( Alternate Shell:s:rdpinit.exe) with xfreerdp by adding the "-s rdpinit.exe" parameter:

./client/X11/xfreerdp -s rdpinit.exe -u username -p password --app --plugin channels/rail/rail.so --data "%WINDIR%\System32\notepad.exe" -- servername

This looks very promising: On the server rdpinit.exe and rdpshell.exe are executed and xfreerdp now receives the RAIL Handshake and System Parameters Update PDUs, sends the Execute PDU but never receives the Execute Result PDU.

This is the rail debug when connecting to Windows Vista/7:

DBG_RAIL rail_order_recv (409): Received Handshake PDU, length:8
DBG_RAIL rail_send_pdu (115): Sending Handshake PDU, length:8
DBG_RAIL rail_send_pdu (115): Sending Client Status PDU, length:8
DBG_RAIL rail_order_recv (409): Received System Parameters Update PDU, length:9
                                (SPI_SET_SCREEN_SAVE_SECURE)
DBG_RAIL rail_order_recv (409): Received System Parameters Update PDU, length:9
                                (SPI_SET_SCREEN_SAVE_ACTIVE)
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:18
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:16
DBG_RAIL rail_send_pdu (115): Sending Execute PDU, length:70
DBG_RAIL rail_order_recv (409): Received Execute Result PDU, length:74
DBG_RAIL window_state_update (143): ownerWindowId:0x00000000
DBG_RAIL window_state_update (147): windowId=0x40026 ownerWindowId=0x0
...

And here the XP connection's log:

DBG_RAIL rail_order_recv (409): Received Handshake PDU, length:8
DBG_RAIL rail_send_pdu (115): Sending Handshake PDU, length:8
DBG_RAIL rail_send_pdu (115): Sending Client Status PDU, length:8
DBG_RAIL rail_order_recv (409): Received System Parameters Update PDU, length:9
                                (SPI_SET_SCREEN_SAVE_ACTIVE)
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:18
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:9
DBG_RAIL rail_send_pdu (115): Sending System Parameters Update PDU, length:16
DBG_RAIL rail_send_pdu (115): Sending Execute PDU, length:70

The only noticeable difference is that Windows Vista/7 sends two System Parameters Update PDUs but that is ok because according to MS-RDPERP SPI_SETSCREENSAVEACTIVE is not supported on XP.

Hope this helps a little bit to track down the issue.

[jacob019]

Is this really fixed? I would like to test it.

[nfedera]

No. This is definitely not fixed. @otavio please untag fixed-waiting-test ;)

[erenoglu]

So does this mean we can't use xfreerdp when the host is WinXP SP3 with the necessary KB and remoteapp entry creations? do we definitely need vista or Win7?

I'm having the same issue, xfreerdp launching and connecting to the XPSP3 virtual machine, the disk lights show some action but no window comes up.

user@host:~$ xfreerdp /u:myuser /p:mypass /v:xpsp3-virt /app:"||calc"
loading channel rail
connected to emre-nb-virt:3389

then nothing...

[hardening]

Just pinging this bug, has something changes on that side ?
It's not clear if you can connect with RAILs with mstsc on a WinXP host ? If not I'd tend to close the issue...

[tristan-k]

I can confirm the issue. Unable to connect to Win XP SP3 with Debian and This is FreeRDP version 2.0.0-dev (git n/a).

$ /opt/freerdp-nightly/bin/xfreerdp /u:Username /p:Password /v:192.168.0.201 /app:"||Notepad"[01:02:06:281] [21095:21096] [INFO][com.freerdp.client.common.cmdline] - loading channel rail

And then nothing happens.

[akallabeth]

Closing as Windows XP is EOL and it is still not clear if this was not a configuration issue.